Note that error wasn't actually working in vcl_deliver, and this just puts VCC in line with the rest of Varnish. Syntax errors are better than assert errors. Re #1027 I'll leave it for later discussion to see if we close #1027, which is technically a feature request now, though a request for a feature we used to have (not sure how well it worked).
As per documentation, the ban lurker sleeps ban_lurker_sleep when it is successful, but on failure it should only sleep 1.0s. No point hammering the ban list every 0.01s if bans aren't even used. Fixes #1030 Conflicts: bin/varnishd/cache_ban.c
The http_PutProtocol() and http_PutResponse() would in the case of workspace overflow leave the headers as NULL and log a SLT_LostHeader. This would make Varnish assert correctly later when writing to the wire, as these are mandated by HTTP. This commit changes them to set the fields to static strings instead ("HTTP/1.1" and "Lost Response") when failing to write them to the workspace. This leaves enough information to complete the protocol in the case of overflow. The patch also increases the synthetic object's workspace from static 1024 to param->http_resp_size. This leaves more (and configurable) room for manipulating the headers of the synthetic object in vcl_error. This whole thing has been a collaboration between Martin and myself. I'll leave it a mystery who wrote what line of code, which part of the comment and contributed what to the test-case. In all fairness, it's not a prefect solution, but a far step closer to one. So it sort of, kinda, more or less, for now, until we get a better solution: Fixes: #1031 Conflicts: bin/varnishd/cache_http.c
patch received from Nils Goroll <email@example.com> - [e0ee2a2] adds the file_read privilege needed for onnv_140 and newer (see #912), but we also need the file_write privilege for stevedore access. - If available, keep sys_resource in the permitted/limited set to allow cache_waiter_ports to raise the process.max-port-events resource control (feature to be added later). - When starting varnish with euid 0 on Solaris, privilege seperation prohibited preserving additional privileges (in excess of the basic set) in the child, because, for a non privilege aware process, setuid() resets the effective, inheritable and permitted sets to the basic set. To achieve interoperability between solaris privileges and setuid()/setgid(), we now make the varnish child privilege aware before calling setuid() by trying to add all privileges we will need plus proc_setid. - On solaris, check for proc_setid rather than checking the euid as a prerequisite for changing the uid/gid and only change the uid/gid if we need to (for a privilege aware process, [ers]uid 0 loose their magic powers). Note that setuid() will always set SNOCD on Solaris, which will prevent core dumps from being written, unless setuid core dumps are explicitly enabled using coreadm(1M). To avoid setuid() (and the SNOCD flag, consequently), start varnish as the user you intend to run the child as, but with additional privileges, e.g. using ppriv -e -s A=basic,net_privaddr,sys_resource varnishd ... - setppriv(PRIV_SET, ...) failed when the privileges to be applied were not available in the permitted set. We change the logic to only clear the privileges which are not needed by inverting the sets and removing all unneeded privileges using setppriv(PRIV_OFF, ...). So the child might end up with less privileges than given initially,
Allow %r format to log incomplete records too. Update docs to reflect new defaults Fixes #1028
Tighten it up with use of semaphores and collapse s1/s2/s3 using "accept" keyword.