This page describes the current status of Debian systemd integration.
Goals
invoke-rc.d(8) should call systemctl instead of /etc/init.d/<service>. invoke-rc.d is called from maintscripts.
- update-rc.d(8) should enable/disable systemd services in addition to creating the sysvinit links. update-rc.d is usually called from maintscripts, but enable/disable is typically used by the system administrator.
service(8) should call systemctl instead of /etc/init.d/<service>. service(8) is called interactively by the system administrator.
- systemctl enable/disable should also call update-rc.d
Status/TODO
invoke-rc.d/update-rc.d are in the jessie-pending branch of sysvinit, see http://anonscm.debian.org/gitweb/?p=collab-maint/sysvinit;a=shortlog;h=refs/heads/jessie-pending
the newest version of the invoke-rc.d patch is not yet applied: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683084#52
TODO (stapelberg@) for update-rc.d in sysvinit, we also need to cover Also=, Alias= and ?RequiredBy=, see http://www.freedesktop.org/software/systemd/man/systemd.unit.html
for service(8), there is 704923
TODO (stapelberg@) make systemctl enable/disable call update-rc.d
installation/maintainer scripts
It's still open for discussion how much logic we move into update-rc.d / invoke-rc.d or if we let dh_installinit generate systemd specific code. Maybe a mix of both is needed. Also, do we want to add all functionality into dh_installinit or should we provide separate helper tools: dh_tmpfiles, dh_systemd or even split the latter for services and sockets?
tmpfiles units
- debian/$package.tmpfiles → /usr/lib/tmpfiles.d/$package.conf
- debian/$package.$name.tmpfiles → /usr/lib/tmpfiles.d/$name.conf
- postinst: systemd-tmpfiles /usr/lib/tmpfiles.d/$package.conf
- Needs to run before daemons are started, move into dh_installinit so we can guarantee ordering?
- Make the tmpfiles mechanism generally available. Needs an implementation for sysvinit.
socket units
- debian/$package.socket → /lib/systemd/system/$package.socket
- debian/$package.$name.socket → /lib/systemd/system/$name.socket
- prerm/remove: Should be stopped before daemon is stopped so it is not auto-spawned
- Daemons with socket files should use restart-after-upgrade, otherwise the behaviour is not really deterministic during upgrades (they can be auto-spawned at any time). Let dh_installinit warn or add a lintian check? Mask the service temporarily?
service units
- debian/$package.service → /lib/systemd/system/$package.service
- debian/$package.$name.service → /lib/systemd/system/$name.service
- Move all functionality into invoke-rc.d/update-rc.d or let dh_installinit generate systemd specific code? We probably need the latter, so we can handle special cases like socket activated services or or if a package uses a single SysV init script but multiple systemd service files.
- Disabled services should not be (re)started during upgrades
- This is also true for socket or D-Bus activated services
Provide a dh_installinit flag which allows services to be installed but disabled (both for sysv and systemd). Currently services use a /etc/default/<service> file with a DISABLED flag, which we want to avoid at all costs.
- Make it possible to install systemd-only services via dh_installinit.
Aliased services. EXAMPLE: /etc/init.d/network-manager vs NetworkManager.service. "systemctl enable network-manager.service" doesn't work.
tools
update-rc.d
invoke-rc.d
- Stop both $foo.service and $foo.socket on stop? EXAMPLE: acpid
service
- Stop both $foo.service and $foo.socket on stop? EXAMPLE: acpid
lsb init-hook
Let lintian warn if a sysv init script has no /lib/lsb/init-functions include. Or do that only if there is also a corresponding .service file? see 704197
- When do we remove the systemctl daemon-reload bits, jessie+1?