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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
