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