For anyone other than Ian watching this bug report, Ian grumbled about systemd in my vicinity at the weekend, and as a professional systemd-wrangler in my day job I offered to help.

I haven't yet got a unit file I'm fully happy with (let alone any working tests), but I have at least got SAUCE running under systemd on my laptop.

I've decided not to have sauce.service wrap sauce.init. Instead, I've used systemd's native facilities to do most of the things that sauce.init and sauce-run do.

sauce-run expects SAUCE_USER to specify what user to run SAUCE as, and I think will default to root if it's not set. But the "stop" action of sauce.init assumes when invoking start-stop-daemon that SAUCE is running as "mail", which suggests that maybe any setting other than "mail" doesn't work properly. systemd doesn't make it easy to extract the user to run the service as from /etc/sauce/sys-config, so for now I've cheated and hard-coded "mail" into systemd.service. The admin can override it using a drop-in, but this would make upgrades a bit messy for people who set SAUCE_USER to something other than "mail".

I have otherwise arranged to run SAUCE through a shell that has sourced /etc/sauce/sys-config so that settings in there will work. It would be more systemd-ish to use EnvironmentFile=, but that doesn't allow for arbitrary shell constructs.

The "sauce-run" script arranges to note the startup and shutdown times of SAUCE, and to record its stdout and stderr, into /var/log/sauce-startup.log. systemd by default records all of these to the journal (and hence syslog on systems with a syslog daemon). I think it's better for sauce.service to do things the usual systemd way and not write to sauce-startup.log. In particular, this means that early startup failures appear in the output of "systemctl status sauce". It's not very hard to have systemd log to a file instead if you think that's better, though.

I've copied the code for waiting for SAUCE to start up from sauce.init into sauce.service. This has not made it any less shonky.

I think I've correctly translated the shutdown procedure into systemd. It will run sauceadmin shutdown, then if SAUCE is still running send SIGTERM, then if SAUCE doesn't stop within 30 seconds send SIGKILL.

I concur that wholesale conversion to "dh" is not necessary. I think you added the call to dh_installsystemd in the wrong place (it should have been before dh_installdeb), which probably didn't help.

Next I want to sort out some kind of tests for this, which will probably be a bit harder.

--
Ben Harris

Reply via email to