Bug#652442: lighttpd: please include systemd service file
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 tags 652442 +pending +patch thanks Hello Michael, I just committed both of your systemd files in commit 568 [1]. However, I moved the tmpfiles.d file from your proposal to /usr/lib/tmpfiles.d/ as this is, where other tmpfiles.d are installed in Debian (and I renamed it, but that's a dh_install limitation). Also, I found it quite inconsistent to install the service file to /lib but the tmpfiles.d file to /etc. Albeit Stefan said the contrary, he accidentally forgot to release the systemd service file with the release tarball of 1.4.30. :) Hence I added it to the Debian specific part for now. I guess he will do so for 1.4.31. But, one more thing: On 17.12.2011 13:57, Michael Stapelberg wrote: We should also change /etc/logrotate.d/lighttpd like this: postrotate if [ -x /bin/systemctl ]; then \ /bin/systemctl kill --signal=SIGHUP lighttpd.service /dev/null 21; \ elif [ -x /usr/sbin/invoke-rc.d ]; then \ invoke-rc.d lighttpd reopen-logs /dev/null 21; \ else \ /etc/init.d/lighttpd reopen-logs /dev/null 21; \ fi; \ endscript I didn't apply this patch. That's messy and does not scale. What comes next if people ask me to support runit, upstart and god knows what else? I will support systemd as soon as there is a more generic interface through which systemd can be invoked. Indeed I think systemd maintainers want to integrate it to invoke-rc.d and that's the right approach. I invite you to raise that discussion on debian-devel to discuss, and possibly assist to implement a more generic wrapper for that sort of problems. [1] http://anonscm.debian.org/viewvc/pkg-lighttpd?view=revisionrevision=568 - -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJO7+jZAAoJEMcrUe6dgPNt72cP/072Qfi7NWkTQ2qfC/mR0CrC rS9RHQVjt7t+5On7ZgsezFI+gdGglIjG1juKG5/tH2SqdGXfb4F9kfwPTl4cnW09 bmPIhvlMhPmu13rGrDH70q9GXjMjxPURHVxbnvbglS7YOJr0K6eooBAlWfHANr73 O1f5ylRlLxzR27HUjLeLXGLE1Ba6qnoGFvICOLyM1ZGwkxXcIfqLRiDwB9ctdN55 zC8yFOOSwI3WdGqnmvTJqbYskAu7DuJVU/rzA3BrtyyUHyDP2ogfRoz6OVIXZTA4 7mxGtAJo+qSXehUUWWK9ahjWrklee/PdpgDizxfDJetmSJPo6zAXvmdlxRhd4VO2 sLfzCEjDKzf484b6DH0cc304ne9lmgpsDa4kqbkyPv2OQiBMC6Ui1P/svSNWEBtU BLalVP5tPUq0pEQ0alfWIoU/SqgPnFkzutldsio07AQn2J9s7BUAX2u3G3oafXmt H4UsH6y8VgDeVEhXaZLXCldjdiBRjSJt7TYvUnBOsnWpGdNtXwm3t1wNrX0jowOk HTYkIENObk2jOGlXIzqtLs4UYtH1pcB0LillAevkkksUQ9vLmrHDsdI3jiBiAHB2 vDITD07vyy2fUdKK1L5SZL2IifaV+wLTjs5vfjWLQAldPhOlUpAZhxkDJldOUleh D/SNCYbWJVkMdSnf4gjL =5qBK -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652442: lighttpd: please include systemd service file
Hi, i committed the systemd/lighttpd.service file in r2818. I won't add the tmpfiles config upstream, as i think this should be handled by the distributions. Regards, Stefan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652442: lighttpd: please include systemd service file
Hi Stefan, Excerpts from Stefan Bühler's message of 2011-12-18 15:19:14 +: i committed the systemd/lighttpd.service file in r2818. Thanks! I won't add the tmpfiles config upstream, as i think this should be handled by the distributions. So, every distribution now has to ship an identical tmpfiles.d/lighttpd.conf and be aware that it is missing? I don’t get the rationale behind this decision. Every distribution which picks up the lighttpd.service *needs* a file like this, since systemd expects /run on tmpfs. 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
Bug#652442: lighttpd: please include systemd service file
Hi Michael, On 12/18/2011 04:29 PM, Michael Stapelberg wrote: Excerpts from Stefan Bühler's message of 2011-12-18 15:19:14 +: I won't add the tmpfiles config upstream, as i think this should be handled by the distributions. So, every distribution now has to ship an identical tmpfiles.d/lighttpd.conf and be aware that it is missing? I don’t get the rationale behind this decision. Every distribution which picks up the lighttpd.service *needs* a file like this, since systemd expects /run on tmpfs. There is no need for a (/var)/run/lighttpd/ directory - the pid file is placed directly in (/var)/run, and the sockets are placed wherever the user wants them to be. The upstream config examples don't contain any reference to (/var)/run/lighttpd/, so i see no reason to add a tmpfile here (neither are our init script examples creating that directory). As soon as there is a sane tmpfiles.d approach, we can discuss actually using it in our config examples. (afaik the debian configs contain a /var/run/lighttpd/ reference only in mod_webdav.conf, which could be modified to use /var/run easily) regards, Stefan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652442: lighttpd: please include systemd service file
Hi Stefan, Excerpts from Stefan Bühler's message of 2011-12-18 15:37:25 +: The upstream config examples don't contain any reference to (/var)/run/lighttpd/, so i see no reason to add a tmpfile here (neither are our init script examples creating that directory). I see. (afaik the debian configs contain a /var/run/lighttpd/ reference only in mod_webdav.conf, which could be modified to use /var/run easily) Hah, I actually use WebDAV, so that’s why I needed that directory :). Thanks for the explanation. If you need any help modifying the packaging for lighttpd in Debian to properly handle the new lighttpd.service file, let me know. As I mentioned in my original email, there is an example where I’ve done the smartmontools systemd-related changes. 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
Bug#652442: lighttpd: please include systemd service file
Package: lighttpd Severity: wishlist Tags: patch Hello, I created a systemd service file for lighttpd. systemd is a sysvinit replacement (see [1] for more information). Please include the following attached files in your next upload: • lighttpd.service as /lib/systemd/system/lighttpd.service • lighttpd.conf as /etc/tmpfiles.d/lighttpd.conf You can find an example packaging which I’ve done for smartmontools at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639631#10 If you have any questions, please do not hesitate to contact me. Thanks! Best regards, Michael [1] http://en.wikipedia.org/wiki/Systemd For debian specific documentation, see also http://wiki.debian.org/systemd lighttpd.service Description: Binary data lighttpd.conf Description: Binary data
Bug#652442: lighttpd: please include systemd service file
Hi Michael, i have a small question: is systemd still needed for /etc/tmpfiles.d/lighttpd.conf ? If yes i think it should *not* be used, as it only works if you are using systemd, which is a wrong dependency here - it must work with all init systems (see #636339). The /lib/systemd/system/lighttpd.service looks simple enough that i might include it upstream (if you don't see any problem with that). Regards, Stefan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652442: lighttpd: please include systemd service file
Hi Stefan, Thanks for your quick reply. Excerpts from Stefan Bühler's message of 2011-12-17 11:18:14 +: is systemd still needed for /etc/tmpfiles.d/lighttpd.conf ? If yes i think it should *not* be used, as it only works if you are using systemd, which is a wrong dependency here - it must work with all init systems (see #636339). 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? The /lib/systemd/system/lighttpd.service looks simple enough that i might include it upstream (if you don't see any problem with that). Cool, feel free to do that. I didn’t send an email with an upstream inclusion request since it seems like lighttpd doesn’t ship an init-file either, but providing that file is definitely a good thing for other distributions. 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
Bug#652442: lighttpd: please include systemd service file
Hi Stefan, Excerpts from Stefan Bühler's message of 2011-12-17 11:59:13 +: 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
Bug#652442: lighttpd: please include systemd service file
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 +: 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
Bug#652442: lighttpd: please include systemd service file
Hi Stefan, Excerpts from Stefan Bühler's message of 2011-12-17 12:32:11 +: 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/) I see. (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). I agree. 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. Me too. But this is a separate issue, and for now just providing the same functionality that the init-script provides will bring us forward in systemd integration. Waiting for a perfect solution to cover this and other problems won’t :). 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). Well, I’ve been bitten multiple times by changing my config and lighttpd not coming up properly afterwards, so indeed the check does not seem to help a lot. However, having a check which catches some errors is better than not having checks at all. And maybe upstream can make the check more useful in the future? If upstream thinks the check is not worth it, what about making the check a no-op and removing it from the distribution init-scripts/systemd files? I guess ExecStartPre is always called before starting the service, right? Correct. Actually, the init script was changed, and reload does a restart now. reopen-logs is used for sending HUP. I see. So then scripts need to be changed anyways. As systemctl provides a reload-or-restart action, we can drop the ExecReload line. We should also change /etc/logrotate.d/lighttpd like this: postrotate if [ -x /bin/systemctl ]; then \ /bin/systemctl kill --signal=SIGHUP lighttpd.service /dev/null 21; \ elif [ -x /usr/sbin/invoke-rc.d ]; then \ invoke-rc.d lighttpd reopen-logs /dev/null 21; \ else \ /etc/init.d/lighttpd reopen-logs /dev/null 21; \ fi; \ endscript I have attached the modified debian/lighttpd.logrotate and lighttpd.service. Best regards, Michael lighttpd.service Description: Binary data lighttpd.logrotate Description: Binary data
Bug#652442: [pkg-lighttpd] Bug#652442: lighttpd: please include systemd service file
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On 17.12.2011 13:32, Stefan Bühler wrote: hm, right. the debian init script creates that directory (and overwrites permissions, very bad style). Actually not only bad style but also a bug. I will fix that for the next upload to make sure it respects any possible stat-override the administrator may have created. Regarding the systemd discussion I see you are both discussing nicely, so I will lazy as I am wait for the outcome of your discussion and see how things are then. : Right now I do not see any problem to include necessary files, although we need a bit more than just including these files to make sure we can cleanly use systemd and not sysvinit if desired. - -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJO7JP/AAoJEMcrUe6dgPNtHVAP/Rq/sLHptatDgqLk9fZA1IiM 0VMrI2NPYeKhf5SLmNa+dqvuLTP/CEtc4d1x4Pq6uYyjLv+h3p9DLRmVwdkuHBuQ iTunK0X/ZRjSftSn8eGm/FNfmNbrNkHB5ao+oGcU92o+sA11AZewRJNta1VeuhSJ bANT9IyPc1Qhb4ygYU6/mlYt5JfjkkPaAOyA5GyL8yupDqBwioI59YlCaCcB+UmP PUSYIXz94a2olv9MOZUTJAxmoFRVbReuOeLnAaSGhlmTJHzekkyywXpuBJnLZpxa YCff7Rx1tEJ65zVIqgAq6qG2oqKRIML9vyTxd85Fk1ruCbhTCoe6Y+hzYwFh+Wrq 4ESKie5vak7OJ2YrZEaAvPey9Y3xI5USTsyWLmPHoXy8BnGCkGGZ+9Eowcpb8P+T 3m6G5Y8iLvYfLNvwSwHniE+HdKg1wultIIpFIrOZ00hCnzC3XAZxRCOI2oDDg4rG Nm/SSUQy1e5wCRy2Er4oqOGzVqf+xV5AQwDIeM/WmZm3i2AD3e74u9Jx9Q2W3aqn 3T3p/U9JRpHP/ac4JSfySrXTq4AnXIM4IUV70pFEwAXRaHBpWNySPsmXW5jbIayl wCu4pXBdvCZQjbEW61WAAA3CNBkqjPUPIYGxhY64iZjpxgkTEHrNwZR1jMcapYMM IoyZgv8+WNM5HhiRjVEf =TLVZ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652442: lighttpd: please include systemd service file
Hi Michael, On 12/17/2011 12:27 PM, Michael Stapelberg wrote: Hi Stefan, Thanks for your quick reply. Excerpts from Stefan Bühler's message of 2011-12-17 11:18:14 +: is systemd still needed for /etc/tmpfiles.d/lighttpd.conf ? If yes i think it should *not* be used, as it only works if you are using systemd, which is a wrong dependency here - it must work with all init systems (see #636339). 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. And as php-fpm wouldn't default to that path, but a user might want to use that path for additional security (so users can't list all sockets), the distribution provided files won't have a dependency, and the user probably won't get it right. 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). The /lib/systemd/system/lighttpd.service looks simple enough that i might include it upstream (if you don't see any problem with that). Cool, feel free to do that. I didn’t send an email with an upstream inclusion request since it seems like lighttpd doesn’t ship an init-file either, but providing that file is definitely a good thing for other distributions. I think we actually ship some init scripts, but they depend on the distribution you are using. The systemd service looks simple enough that it should work on all dists. 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. b) SIGHUP only reopens the log files, it does not reload the config. Is this the right thing for ExecReload? Regards, Stefan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
