[pkg-lighttpd] Bug#652442: lighttpd: please include systemd service file

[Michael Stapelberg]

Hi Stefan,

Excerpts from Stefan Bühler's message of 2011-12-17 11:59:13 +0000:
> > I’m not sure why providing this file would add a dependency on systemd:
> >
> >   • If the user uses sysvinit, the init-script will create the folder.
> >   • If the user uses systemd, its tmpfiles.d-mechanism will create the folder.
> >
> > So, this seems like a completely different problem to me. Could you elaborate?
> 
> And if a different sysvinit script, that uses the same directory for 
> temporary sockets for example like php-fpm, runs before the lighttpd 
> one, the directory is missing, and it will fail.
> Of course you could add more dependencies and so on, but this is just 
> the wrong way to ensure a directory exists.
IMO, if a script / program relies on some directory being there, it has to
create it. Or, if it should be created by some other program earlier in the
boot sequence, the script / program clearly should have a dependency on the
other program. Why do you think this is the wrong way? :)

> Don't get me wrong: I actually like the tmpfiles.d thing. I just think 
> it needs a more generic handling than systemd, iow all init systems must 
> create those directories before doing anything else (well, after 
> mounting /run ofc).
Right, I basically agree, but I don’t see why that prevents you from adding the
file *without* touching the existing init structure? I mean, the existing
init-script is either working or broken, but adding the
tmpfiles.d/lighttpd.conf will not change that. However, when adding
lighttpd.service, we must also add tmpfiles.d/lighttpd.conf, otherwise we
introduced a regression.

> Now i have two questions for the systemd service itself :)
> a) ExecStartPre - is that useful? lighttpd -t only checks the basic 
> syntax, not whether the config options actually exist or whether they 
> have the right structure (strings, ints, bools, lists of ...) and so on.
IMO, more checks are always useful. The systemd service file only reflects the
current behavior of the init script, which does not check for the existence of
/etc/lighttpd/lighttpd.conf either. If you want to check that, use the
following line in the [Unit] section:

ConditionPathExists=/etc/lighttpd/lighttpd.conf

> b) SIGHUP only reopens the log files, it does not reload the config. Is 
> this the right thing for ExecReload?
Hm, to quote systemctl(1):

    Asks all units listed on the command line to reload their configuration.
    Note that this will reload the service-specific configuration, not the unit
    configuration file of systemd. If you want systemd to reload the
    configuration file of a unit use the daemon-reload command. In other words:
    for the example case of Apache, this will reload Apache's httpd.conf in the
    web server, not the apache.service systemd unit file.  

So, providing SIGHUP as reload-action is a misnomer, since it doesn’t actually
reload the service-specific configuration. However (!), since the command
'/etc/init.d/lighttpd reload' will effectively invoke 'systemctl reload
lighttpd.service' when using systemd, we should probably keep it to stay
backwards-compatible. I could imagine scripts using /etc/init.d/lighttpd reload
after rotating the logfiles…?

(The cleaner way would be to use systemctl kill --signal=SIGHUP
lighttpd.service in those scripts, but I think staying backwards-compatible is
more important right now.)

Best regards,
Michael