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

Stefan Bühler stbuehler at lighttpd.net
Sat Dec 17 12:32:11 UTC 2011


Hi Michael,

On 12/17/2011 01:12 PM, Michael Stapelberg wrote:
> 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? :)

If i (as user) configure php-fpm to use that directory (by setting the 
socket paths), i need an easy way to make sure it exists.
same problem if i'd be using /var/run/php-fpm/..., but it makes sense to 
put all sockets that are going to be used by lighttpd in 
/var/run/lighttpd/, and seeing that /var/run/lighttpd/ already exists, 
why would I ever think using that directory might be a problem?

And there is no need to run lighttpd - perhaps sometimes you only want 
to run the backend (parallel start for example), so a runtime dependency 
is wrong too.

And there should be only one place that creates the directory, and it 
should be easily configurable (+1 for /etc/tmpfiles.d/)

(Imho the core system should manage this automatically for all 
directories that are installed from packages in /var/run/ to ensure old 
packages keep working; configuring it with dpkg-statoverride as always).

>> 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.

hm, right. the debian init script creates that directory (and overwrites 
permissions, very bad style).
It still is just an ugly workaround, and i'd like to see a proper fix 
for it, not more workarounds.

>> 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

Hm. I think is isn't worth it to check for the syntax. You don't gain 
much from it, but you might end up paying too much for it (running all 
the include_shell things and so on).
I guess ExecStartPre is always called before starting the service, right?

>> 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.)

Actually, the init script was changed, and "reload" does a restart now.
"reopen-logs" is used for sending HUP.

regards,
Stefan






More information about the pkg-lighttpd-maintainers mailing list