Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 787548 - www-servers/lighttpd-1.4.58 FastCGI fails
Summary: www-servers/lighttpd-1.4.58 FastCGI fails
Status: RESOLVED OBSOLETE
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Herb Miller Jr.
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-05-01 21:44 UTC by Anthony Lieuallen
Modified: 2021-11-17 14:41 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Anthony Lieuallen 2021-05-01 21:44:08 UTC
I'd love to provide more detail, but this is what I've got.  Yesterday I updated @world.  After that, some of my websites failed to load.  I narrowed it down to the ones using FastCGI.  I dug and dug and couldn't find anything wrong.  I downgraded to 1.4.55-r100 (I had -r1 before the change to .58) and everything worked again.

at .58 whenever a FastCGI-served page is fetched, lighttpd logs:

 lighttpd-angel.c.156: child (pid=19261) exited unexpectedly with signal 11, restarting

And nothing else.  I don't know how to get more detail out of lighttpd; this is already with "fastcgi.debug = 1" in its config file.

Reproducible: Always

Steps to Reproduce:
1. Load any page served by FastCGI

Actual Results:  
lighttpd crashes

Expected Results:  
page loads
Comment 1 Herb Miller Jr. 2021-05-20 21:53:47 UTC
I ran a quick test across 1.4.55-r100, 1.4.58, and 1.4.59 (wip) running phpinfo() via fcgi and wasn't able to reproduce the issue. I've been running wordpress and nextcloud via 1.4.58 for awhile now without issue, so I'd like to understand more about your environment.

Which USE flags do you have enabled for lighttpd?
Are you using www-servers/spawn-fcgi?
Are you using systemd or openrc?
Can you tell me what you're running via fcgi? Is it php?

Are you comfortable running a backtrace? If so, it might be advantageous to run lighttpd in the foreground through gdb and grab a backtrace.

Something like:
gdb --ex=run --args /usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf

Then, when it crashes:
thread apply all bt

And attach the output.
Comment 2 Anthony Lieuallen 2021-07-02 16:22:27 UTC
My lighttpd installation is:

[ebuild   R    ] www-servers/lighttpd-1.4.55-r100::gentoo  USE="bzip2 fam ipv6 pcre php ssl xattr zlib -dbi -doc -gdbm -geoip -kerberos -ldap -libev -lua -memcached -minimal -mmap -mysql -postgres -rrdtool -sasl (-selinux) -sqlite -test -webdav" LUA_SINGLE_TARGET="lua5-1 -lua5-2 -lua5-3" 0 KiB

And:

$ equery l spawn-fcgi
!!! No installed packages matching 'spawn-fcgi'
 * Searching for spawn-fcgi ...
  
So no I don't think I'm using that.  My system uses OpenRC, but I use Daemontools (sys-process/daemontools) to launch everything I can, including lighttpd.  (Which just means running `exec envuidgid lighttpd /usr/sbin/lighttpd-angel -D -f /etc/lighttpd/lighttpd.conf`.)

I'm running one instance of MediaWiki (PHP) and three small Python fastcgi sites.

I'll work on getting a backtrace, trying to reproduce in a non-prod environment.
Comment 3 Anthony Lieuallen 2021-07-24 21:50:15 UTC
When I `emerge -v`  .58 it says this, FWIW

[ebuild     U  ] www-servers/lighttpd-1.4.58-r1::gentoo [1.4.55-r101::gentoo] USE="bzip2 ipv6 pcre php ssl xattr zlib -brotli% -dbi -doc -gdbm -gnutls% -kerberos -ldap -libev -lua -maxminddb% -mbedtls% -memcached -minimal -mmap -mysql -nss% -postgres -rrdtool -sasl (-selinux) -sqlite -test -webdav (-fam%*) (-geoip%)" LUA_SINGLE_TARGET="lua5-1 (-lua5-2) -lua5-3 -lua5-4%" 0 KiB

I've installed GDB and followed your instructions.  The trace is just:

Program received signal SIGSEGV, Segmentation fault.
0x000055555556f029 in ?? ()
(gdb) thread apply all bt

Thread 1 (Thread 0x7ffff7adc4c0 (LWP 29609) "lighttpd"):
#0  0x000055555556f029 in ?? ()
#1  0x0000555555589fd8 in gw_check_extension ()
#2  0x00007ffff7a00047 in ?? () from /usr/lib64/lighttpd/mod_fastcgi.so
#3  0x0000555555574ba8 in ?? ()
#4  0x0000555555575da7 in http_response_handler ()
#5  0x0000555555578436 in ?? ()
#6  0x0000555555577e0f in connection_state_machine ()
#7  0x0000555555574a6c in ?? ()
#8  0x0000555555562ec9 in main ()
(gdb)

I tried (unsuccessfully?) to build with debugging symbols and got:

Program received signal SIGSEGV, Segmentation fault.
0x0000555555595568 in ?? ()
(gdb) thread apply all bt

Thread 1 (Thread 0x7ffff7adc4c0 (LWP 5319) "lighttpd"):
#0  0x0000555555595568 in ?? ()
#1  0x00005555555994ac in gw_check_extension ()
#2  0x00007ffff79f990f in ?? () from /usr/lib64/lighttpd/mod_fastcgi.so
#3  0x00007ffff79f9a34 in ?? () from /usr/lib64/lighttpd/mod_fastcgi.so
#4  0x000055555559d910 in ?? ()
#5  0x000055555559db60 in plugins_call_handle_subrequest_start ()
#6  0x0000555555567a95 in ?? ()
#7  0x00005555555688b1 in http_response_handler ()
#8  0x000055555556b2fd in ?? ()
#9  0x000055555556bdcc in ?? ()
#10 0x000055555556be78 in connection_state_machine ()
#11 0x0000555555565e02 in ?? ()
#12 0x0000555555565f92 in ?? ()
#13 0x0000555555566074 in main ()
(gdb) 

Also: no PHP, I was mistaken about MediaWiki running here.  There's just three Python fastcgi sites under lighttpd.
Comment 4 Herb Miller Jr. 2021-08-18 17:47:28 UTC
Can you tell me more about your Python fcgi setup? I'm having trouble finding an implementation I can test. I looked into flup, but that's not in the portage tree anymore. uWSGI seems to be its own thing that runs through mod_scgi instead of mod_fcgi.

Can you give me a standalone example of the type of python site you're running?
Comment 5 Anthony Lieuallen 2021-08-25 15:46:15 UTC
I'm using flup, via pip.  I've got a reduced test case:

1) Make a directory somewhere and:
   $ python3 -m venv env
   $ ./env/bin/pip install flup
2) Save the example at https://python.readthedocs.io/fr/hack-in-language/howto/webservers.html#setting-up-fastcgi as "test.fcgi" here (with execute permission).
3) Edit the shebang line to test.fcgi e.g. "#!/path/goes/here/env/bin/python3"
2) Add to lighttpd.conf:

$HTTP["scheme"] == "http" {
  server.document-root = "/path/goes/here/"
  fastcgi.server = (
    ".fcgi" => (
      "readability-api" => (
        "socket" => "/var/run/lighttpd/lighttpd-test.socket",
        "bin-path" => "/path/goes/here/test.fcgi",
      )
    )
  )

  url.rewrite-once = (
    "^/.*" => "/test.fcgi$0",
  )
}

Fetch from lighttpd (.58) and it crashes.  Emerge =lighttpd-1.4.55-r101 and fetch again and it's fine.  Emerge =lighttpd-1.4.58-r1 and retry and it crashes.
Comment 6 Herb Miller Jr. 2021-11-16 18:42:54 UTC
I attempted to replicate this using your test case and lighttpd did not crash, _but_ to me this looks very similar to a bug for lighttpd 1.4.58 (https://redmine.lighttpd.net/issues/3094 and https://redmine.lighttpd.net/issues/3052). The backtrace ends on the same function in the same frame: gw_check_extension().

This has been fixed in 1.4.59. Can you try this again on your system with 1.4.59 or above and see if the problem is gone now?
Comment 7 Anthony Lieuallen 2021-11-17 14:41:21 UTC
Went to the machine where I did the above repro.  It still has .58 installed and still crashes.  Emerge .59, restart lighttpd, repeat and it works.