[Pkg-systemd-maintainers] Proposed Release Goal: Add native systemd support to every packaging shipping a sysvinit script

[Michael Stapelberg]

Hi Bastian,

Bastian Blank <waldi at 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