Community Packages

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. 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
Task Type Bug Report
Category Packages
Status Closed
Assigned To Lukas Fleischer (lfleischer)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 5
Private No



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/".
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 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
Comment by Lukas Fleischer (lfleischer) - Saturday, 03 November 2012, 21:23 GMT
1.0.3-4 was built from Git and includes proper systemd support (including socket activation). Does that fix everything you mentioned in the bug report?
Comment by Paul Gideon Dann (giddie) - Monday, 05 November 2012, 12:48 GMT
There are a few problems with this:

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...
Comment by Dave Reisner (falconindy) - Monday, 05 November 2012, 13:33 GMT
1) You can use SocketMode= to change the permissions. I'll propose a patch for systemd to support changing ownership of the socket.
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.
Comment by Paul Gideon Dann (giddie) - Monday, 05 November 2012, 13:43 GMT
The problem is that fcgiwrap is not clever enough to respawn children. Usually, multiwatch is used to do that. Given that multiwatch's functionality is already present in systemd, it seems silly not to use it. It's not feasible to run fcgiwrap in a serious environment without something handling the respawning of dead children.

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.
Comment by Paul Gideon Dann (giddie) - Wednesday, 19 December 2012, 16:14 GMT
Can we also consider using /etc/conf.d/fcgiwrap for at least configuring the number of children spawned? The "correct" way to deal with configuration should be to poke upstream to read a configuration file from /etc, but using /etc/conf.d seems preferable to cloning the unit for configuration as basic as this.
Comment by Daniel Wallace (gtmanfred) - Wednesday, 17 April 2013, 01:16 GMT
This bug should be closed, any customizations to the service unit should be made by creating a version in etc. The current version in the repos works.