Lighttpd

My guess is that older versions of Linux fail for specific signals included in sigfillset().

Are you able to test with this patch?

--- a/src/fdevent.c
+++ b/src/fdevent.c
@@ -516,7 +516,7 @@ pid_t fdevent_fork_execve(const char *name, char *argv[], char *envp[], int fdin
        #endif
         && 0 == (rc = sigemptyset(&sigs))
         && 0 == (rc = posix_spawnattr_setsigmask(&attr, &sigs))
-      #ifdef __linux__
+      #if 0
         /* linux appears to walk all signals and to query and preserve some
          * sigaction flags even if setting to SIG_DFL, though if specified
          * in posix_spawnattr_setsigdefault(), resets to SIG_DFL without query.

gstrauss wrote in #note-1:

My guess is that older versions of Linux fail for specific signals included in sigfillset().

Are you able to test with this patch?
[...]

yes, with this patch (which is effectively reverting the mentioned commit right?) the include_shell works

Thanks for testing.

The whole section using posix_spawn is new, though it is code that I wrote back in 2016 and did not release (due to CGI chdir() requirement). The special code for Linux (now commented out in the patch above) is marginally more efficient on linux (but I may consider choosing to use the other block for compatibility). For some reason, Linux or glibc appears to reset all the signals (all 64), whereas on at least some other platforms which I looked at, only the signals I listed in the subsequent block are reset.

At the moment, I am not planing an immediate release of lighttpd 1.4.71, unless other issue arise. Is this something that can be patched for CentOS? (How old is CentOS 7?) A quick internet search turned up that CentOS 8 was EOL Dec 31, 2021, and I presume CentOS 7 is also EOL.

no worries. let me know if i can do/test something else.

Centos7 & RHEL7 still has maintenance support till June 2024 and i think is still quite widespread (rhel in general is popular for their 10+ years support).

Centos 8 was a special case for which they changed their release cycles.
https://endoflife.date/centos

However most people i know just switched to other open downstream builds of RHEL. Either Alma Linux or Rocky Linux which still support v8 for many years to come:
https://endoflife.date/rocky-linux

I'll probably add a more proper fallback (and slightly larger patch), and will post a link here, but for the moment, lighttpd 1.4.71 is not imminent.

gstrauss wrote in #note-5:

I'll probably add a more proper fallback (and slightly larger patch), and will post a link here, but for the moment, lighttpd 1.4.71 is not imminent.

sounds good. thanks for your help!

--- a/src/fdevent.c
+++ b/src/fdevent.c
@@ -516,14 +516,6 @@ pid_t fdevent_fork_execve(const char *name, char *argv[], char *envp[], int fdin
        #endif
         && 0 == (rc = sigemptyset(&sigs))
         && 0 == (rc = posix_spawnattr_setsigmask(&attr, &sigs))
-      #ifdef __linux__
-        /* linux appears to walk all signals and to query and preserve some
-         * sigaction flags even if setting to SIG_DFL, though if specified
-         * in posix_spawnattr_setsigdefault(), resets to SIG_DFL without query.
-         * Therefore, resetting all signals results in about 1/2 the syscalls.
-         * (FreeBSD appears more efficient.  Unverified on other platforms.) */
-        && 0 == (rc = sigfillset(&sigs))
-      #else
         /*(force reset signals to SIG_DFL if server.c set to SIG_IGN)*/
        #ifdef SIGTTOU
         && 0 == (rc = sigaddset(&sigs, SIGTTOU))
@@ -536,7 +528,6 @@ pid_t fdevent_fork_execve(const char *name, char *argv[], char *envp[], int fdin
        #endif
         && 0 == (rc = sigaddset(&sigs, SIGPIPE))
         && 0 == (rc = sigaddset(&sigs, SIGUSR1))
-      #endif
         && 0 == (rc = posix_spawnattr_setsigdefault(&attr, &sigs))) {

           #if defined(HAVE_POSIX_SPAWN_FILE_ACTIONS_ADDCLOSEFROM_NP) \

The recent 1.4.70 release seems to break "include_shell" configs for CentOS 7. I could not replicate the issue on Rocky 8 though and have no idea what the actual underlying problem is or why it affects one and not the other.

@fstelzer out of curiousity, what are the versions of glibc (or other libc, such as musl) on the systems where it works and where it does not work?

From a very cursory read through of glibc git source history, the behavior I observed looks like it may have been introduced in glibc-2.24, which included commit from 19 Jan 2016 9ff72da471a509a8c19791efe469f47fa6977410 "posix: New Linux posix_spawn{p} implementation".

This seems to work for me.

--- a/src/fdevent.c
+++ b/src/fdevent.c
@@ -516,12 +516,12 @@ pid_t fdevent_fork_execve(const char *name, char *argv[], char *envp[], int fdin
        #endif
         && 0 == (rc = sigemptyset(&sigs))
         && 0 == (rc = posix_spawnattr_setsigmask(&attr, &sigs))
-      #ifdef __linux__
-        /* linux appears to walk all signals and to query and preserve some
+      #if defined(__GLIBC__) \
+       && (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 24 && __GLIBC_MINOR__ <= 37)
+        /* glibc appears to walk all signals and to query and preserve some
          * sigaction flags even if setting to SIG_DFL, though if specified
          * in posix_spawnattr_setsigdefault(), resets to SIG_DFL without query.
-         * Therefore, resetting all signals results in about 1/2 the syscalls.
-         * (FreeBSD appears more efficient.  Unverified on other platforms.) */
+         * Therefore, resetting all signals results in about 1/2 the syscalls.*/
         && 0 == (rc = sigfillset(&sigs))
       #else
         /*(force reset signals to SIG_DFL if server.c set to SIG_IGN)*/

gstrauss wrote in #note-11:

This seems to work for me.
[...]

Works for me as well.
RHEL 7 has glibc-2.17. Probably tons of redhat patches on top though.
Thanks for your help. I'll roll out a patched version to our test env.