Hi Bastian, Bastian Blank <wa...@debian.org> writes: > On Sat, Sep 21, 2013 at 06:45:41PM +0200, Michael Stapelberg wrote: >> sysvinit scripts that many of our current packages provide. However, >> when a package ships a native systemd service file in addition to the >> sysvinit script, users enjoy a couple of advantages: they can now easily >> enable/disable the service in a consistent manner using “systemctl >> enable”, daemon output is stored in the journal by default, the process >> tracking and related error reporting works better and users can use >> drop-in snippets to tweak service behavior (e.g. resource limits). > > Can you please explain what does not work if the sysv compatibility is > used? systemd internally defines a complete service definition for each > enabled sysv init script. I didn’t say that things _dont_ work at all, I am saying that a few details work better when providing a service file:
• systemctl enable/disable does what the user think it does, not only sometimes due to $SERVICE_ENABLED (or _DISABLED) variables in /etc/default/service • process tracking works better because the default behavior for init scripts is that it is okay when a service forks off and exits, whereas service files often specify Type=simple (the default) or provide the PID file path so that systemd can actually reliably find the process and update the status accordingly when it exits. • The drop-in snippets I mentioned above (i.e. files like /etc/systemd/system/apache2.service.d/more-memory.conf) only work with native service files AFAIK, and sometimes outright don’t make sense with a sysvinit script. As an example, you cannot reasonably specify a different ExecStart= line with custom arguments, because the ExecStart= line of a sysvinit unit contains /etc/init.d/service start I hope that answers your question. -- Best regards, Michael -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/x6d2o212u9....@midna.lan
