Differences between revisions 1 and 2
⇤ ← Revision 1 as of 2013-09-21 16:42:15 →
Size: 1720
Editor: ?MichaelStapelberg
Comment:
← Revision 2 as of 2013-09-21 22:03:50 → ⇥
Size: 2015
Editor: ?MichaelStapelberg
Comment:
Deletions are marked like this. Additions are marked like this.
Line 4: Line 4:
systemd is a modern init system which has been present in Debian since wheezy and works well in the current state. systemd can deal with 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). systemd is a modern init system which has been present in Debian since wheezy and works well in the current state. systemd can deal with 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 fully utilize drop-in snippets to tweak service behavior (e.g. resource limits)¹.
Line 7: Line 7:

① When using drop-in snippets with a unit that is automatically generated from a sysvinit script, you cannot reasonably overwrite directives such as ExecStart. Furthermore, limits that you set with systemd might be overwritten in the init script itself, rendering them useless.

Add native systemd support to every packaging shipping a sysvinit script

Goal description

systemd is a modern init system which has been present in Debian since wheezy and works well in the current state. systemd can deal with 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 fully utilize drop-in snippets to tweak service behavior (e.g. resource limits)¹.

The release goal is to add a systemd service file to all packages that currently ship a sysvinit script. It is NOT a goal for the service file to have 100% of the same functionality in the same way, meaning that some features might be achieved differently with systemd.

① When using drop-in snippets with a unit that is automatically generated from a sysvinit script, you cannot reasonably overwrite directives such as ?ExecStart. Furthermore, limits that you set with systemd might be overwritten in the init script itself, rendering them useless.

Current status

  • Over 35 packages already ship a systemd service file and use dh-systemd.

How to help

See http://people.debian.org/~stapelberg/2013/07/14/systemd-how-to-help.html

Relevant packages

Advocates

Volunteers