If the server has changed its uid or is running in a chroot
it may be unable to remove the pid file when it exits.
However, if it holds on to an open handle to the pid file
that has write permission, it will be able to truncate the
pid file to 0 bytes in length.
Most monitoring software recognizes a 0-length pid file
as indicating there is no process running.
Therefore always attempt to truncate the pid file before
trying to remove it so that it's not left containing the
pid of a process that is no longer running.
Signed-off-by: Kyle J. McKay <mackyle@gmail.com>
git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@3112 152afb58-edef-0310-8abb-c4023f1b3aa9
Release op1 memory on failure; fixes some theoretical memory leaks (a
failure results in early exit anyway).
From: Stefan Bühler <stbuehler@web.de>
git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@3101 152afb58-edef-0310-8abb-c4023f1b3aa9
- raise array size limit from INT_MAX to SSIZE_MAX. INT_MAX already
is way to high to be hit in any sane scenario, but SSIZE_MAX can
*obviously* not be hit due to memory constraints.
- use size_t for array indices instead of int
- use binary search instead of next_power_of_2 hack; document invariants
and check them in debug mode (asserts).
- return the actual insert position instead of something near
From: Stefan Bühler <stbuehler@web.de>
git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@3100 152afb58-edef-0310-8abb-c4023f1b3aa9
- refactor insert into array_find_or_insert; if the element already
exists the caller must resolve the conflict manually:
- array_replace frees the old element
- array_insert_unique calls "insert_dup"
both have no return value anymore
- fix usages of array_replace; they now don't need to delete the old
entry anymore; usage in configparser was probably broken, as it
possibly deleted the old element before calling array_replace
This should fix a lot of the issues reported in "Fortify Open Review
Project - lighttpd 1.4.39" (usually hitting the array limit):
when the array size limit was hit "new" entries leaked instead of
getting added.
On 32-bit INT_MAX entries cannot actually be reached (each entry
requires at least 48 bytes, leading to a total of 96GB memory).
On 64-bit INT_MAX entries would require 224GB memory, so it would be
theoretically possible. But it would need 2^27 reallocations of two
C-arrays of up to 16GB size.
From: Stefan Bühler <stbuehler@web.de>
git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@3098 152afb58-edef-0310-8abb-c4023f1b3aa9
Impact is probably low on most platforms, as it will probably overwrite
one byte of "HASH HA1" which isn't used afterwards anymore.
Reference: Fortify Open Review Project - lighttpd 1.4.39
ID 22708159 - Buffer Overflow: Off-by-One
From: Stefan Bühler <stbuehler@web.de>
git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@3096 152afb58-edef-0310-8abb-c4023f1b3aa9
Reference: Fortify Open Review Project - lighttpd 1.4.39
ID 22708125 - Type Mismatch: Signed to Unsigned
From: Stefan Bühler <stbuehler@web.de>
git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@3095 152afb58-edef-0310-8abb-c4023f1b3aa9
wait for CGI to close stdout, so we read EOF on pipe to end CGI response
remove extra call to waitpid() which will occur after process exits
if it has not already been explicitly closed by CGI (and has not been
inherited by CGI forked children) (If CGI forks, then it should close
its stdout response pipe when response is done, especially if it intends
to perform lengthy post-processing in the background.)
From: Glenn Strauss <gstrauss@gluelogic.com>
git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@3091 152afb58-edef-0310-8abb-c4023f1b3aa9
(Thx, anomie, who identified and explained problem in above ticket)
From: Glenn Strauss <gstrauss@gluelogic.com>
git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@3089 152afb58-edef-0310-8abb-c4023f1b3aa9
instead of looping over all config blocks for each conditional var that
gets enabled, enable them all and run over them once.
Right now it seems we actually set all variables at once in normal
config handling (SNI only sets a subset); future modifications
might introduce new variables which are activated at a later stage
(physical path related for example).
From: Stefan Bühler <stbuehler@web.de>
git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@3083 152afb58-edef-0310-8abb-c4023f1b3aa9
- add new "skip" result to mark conditions that didn't actually get
evaluated to false but just skipped because the preconditions failed.
- add "local_result" for each cache entry to remember whether the
condition itself matched (not including the preconditions).
this can be reused after a cache reset if the condition itself was not
reset, but the preconditions were
- clear result of subtree (children and else-branches) when clearing a
condition cache
From: Stefan Bühler <stbuehler@web.de>
git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@3082 152afb58-edef-0310-8abb-c4023f1b3aa9
The first condition which evaluates true in any if-else... condition
chain short-circuits the chain, and any remaining conditions in the
chain are marked false.
Previous conditions in if-else condition chaining must be evaluatable
(to true or false) -- must not remain in unset (not yet evaluatable)
state -- prior to evaluating later conditions. Since any true
condition short-circuits remaining conditions, all prev conditions
must be false prior to evaluating later conditions.
From: Glenn Strauss <gstrauss@gluelogic.com>
git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@3081 152afb58-edef-0310-8abb-c4023f1b3aa9
only use values in reduce actions when the config is still valid
(ctx->ok).
From: Stefan Bühler <stbuehler@web.de>
git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@3080 152afb58-edef-0310-8abb-c4023f1b3aa9
do not propagate sighup if 0 == server.max-workers; reduce impact of
sighup on child processes, such as piped loggers, by not forwarding
sighup signal unless server.max-workers configured
For those configuring server.max-workers, it is recommended that
piped loggers be used to avoid log corruption, and then admins can
avoid sending lighttpd SIGHUP as there is currently no benefit to
doing so with the standard modules (beyond that of log rotation of
non-piped access and error logs).
From: Glenn Strauss <gstrauss@gluelogic.com>
git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@3076 152afb58-edef-0310-8abb-c4023f1b3aa9
Flash filesystem JFFS2 does not support mmap PROT_READ MAP_SHARED,
though it does support mmap PROT_READ MAP_PRIVATE
Although MAP_SHARED is preferred, CGI input body is fully collected
prior to handler invoking the CGI, so the temporary file is never
modified after being mapped. Since the request input body is specific
to request and is temporary file, mmap PROT_READ MAP_PRIVATE works fine.
From: Glenn Strauss <gstrauss@gluelogic.com>
git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@3075 152afb58-edef-0310-8abb-c4023f1b3aa9
Try ssi_vars if ssi_cgi_env does not have a matching var name.
Allow var names to also include digits after the initial letter or underscore.
From: fbrosson <fbrosson@users.noreply.github.com>
git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@3069 152afb58-edef-0310-8abb-c4023f1b3aa9
Andrey Mnatsakanov
