Bug #2502
closedfastcgi process became a orphan process
Description
When lighttpd is starting, mod_fastcgi spawns every fastcgi process.
If users stop the lighttpd when fastcgi is spawning..the spawned fastcgi processes became orphan processes..
Because the lighttpd haven't registered signal handler function before spawning fastcgi process. Once the lighttpd received SIGINT or SIGTERM, the lighttpd process will exit immediately without notifying fastcgi processes
Files
Updated by stbuehler over 10 years ago
- Status changed from New to Need Feedback
show us a strace of lighttpd that proves your statement.
Updated by silence over 10 years ago
- File lighttpd_SIGTERM.strace lighttpd_SIGTERM.strace added
- File lighttpd_notmal.strace lighttpd_notmal.strace added
I uploaded 2 strace files:
1) lighttpd_SIGTERM.strace
send SIGTERM to stop lighttpd when spawning fastcgi process
2) lighttpd_normal.strace
send SIGTERM to stop lighttpd when lighttpd is already started
--------------------------------------------------------------------------------
The signal_handler function is not registered when spawning fastcgi process:
[server.c]
line 937 plugins_call_set_defaults()
-> mod_fastcgi spawns fastcgi process
line 993 register signal by sigaction() till this line.
Updated by stbuehler over 10 years ago
Ok, thx. I'll have a closer look :)
Just two things for your setup (unrelated to the bug):
- don't put sockets in /tmp - another user could create sockets in /tmp with the same names, and lighttpd would connect to them. use a directory that is only writable by lighttpd, if you spawn with lighttpd
- your max-procs settings look very high. In such large setups it is probably worth the effort to use spawn-fcgi, perhaps combined with multiwatch
Updated by stbuehler over 10 years ago
- Status changed from Need Feedback to Assigned
Updated by stbuehler over 10 years ago
- Status changed from Assigned to Fixed
- % Done changed from 0 to 100
Applied in changeset r2901.
Also available in: Atom