Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#31696 - [fcgiwrap] Systemd unit file
Attached to Project:
Community Packages
Opened by Paul Gideon Dann (giddie) - Wednesday, 26 September 2012, 10:32 GMT
Last edited by Lukas Fleischer (lfleischer) - Monday, 03 June 2013, 21:27 GMT
Opened by Paul Gideon Dann (giddie) - Wednesday, 26 September 2012, 10:32 GMT
Last edited by Lukas Fleischer (lfleischer) - Monday, 03 June 2013, 21:27 GMT
|
DetailsDescription:
I've noticed a systemd unit file has surfaced for fcgiwrap. Thanks for that. I have a couple of suggestions: 1) The PID file is not currently created. This causes systemd to fail to start the service, because it's expecting it to appear (because of the PIDFile line.) The following should be added to ExecStart: "-P /var/run/fcgiwrap.pid". 2) The ExecStop command seems to return non-zero (although I'm not sure why). I believe a more "systemd-ish" way to achieve shutdown of the service would be to remove the ExecStop line and let systemd kill all processes itself. 3) It would be really cool to move away from this traditional spawning behaviour towards a socket-activated service template. I use fcgiwrap via a domain socket anyway, and use multiwatch to watch the children (see https://wiki.archlinux.org/index.php/Nginx#Multiple_Workers). I think there must be a nice way to control a pool of fcgiwrap workers using service templates instead of multiwatch. Surely worth checking out? Additional info: * Version 1.0.3-3 |
This task depends upon
Closed by Lukas Fleischer (lfleischer)
Monday, 03 June 2013, 21:27 GMT
Reason for closing: Won't fix
Monday, 03 June 2013, 21:27 GMT
Reason for closing: Won't fix
1) The socket is owned by root and is world-writable. It should be owned by http and mode 700. I can't see a good way to change the ownership of a socket, other than ExecStartPost in the socket unit.
2) I can modify the service unit file, adding "-c <num-children>" to increase the number of workers. However, in this configuration, children are not respawned if they die. Do you know of a nice way for systemd to handle this? I was considering a unit template like sshd@.service or getty@.service, but I'm not sure what would be used for the key, or if this would even be the best approach...
2) Just override the service file -- templating is the wrong thing to do. I don't see why "this setup" affects the behavior of respawning of children. The only difference is how the parent process is started.
The good news is that once the last child dies, systemd does respawn the whole unit correctly, which is something initscripts certainly couldn't do :) I've been using Monit for watching & respawning important stuff, but systemd promises to make much of Monit redundant, which should be pretty cool.