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/service are in sysvinit ≥ 2.88dsf-41+jessie1 (see http://anonscm.debian.org/gitweb/?p=collab-maint/sysvinit;a=shortlog;h=refs/heads/jessie-pending for the corresponding git repository)
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
patch pending: http://t.zekjur.net/systemd-enable.pl.txt
- blocked by concerns by rleigh, not thoroughly discussed yet
- make systemctl enable/disable call update-rc.d
patch pending: http://t.zekjur.net/systemctl-update-rc.d.patch
- Add is-enabled action to update-rc.d
patch pending: http://t.zekjur.net/update-rc.d-is-enabled.patch
- blocked by uncertainty about what enabled/disabled in sysvrc really means.
TODO (biebl@) Add option to dh_installinit to install a service as disabled
Edit conflict - other version:
TODO (stapelberg@) dh_installinit: what we need to add is a way of explicitly installing an upstream-shipped unit file on package installation
TODO (stapelberg@) dh_installinit: also a way to not enable the file, but stop on remove or restart on upgrade iff running
TODO (stapelberg@) dh_installinit: furthermore, the package needs to depend on systemd-support
Edit conflict - other version:
Edit conflict - your version:
End of edit conflict
TODO (stapelberg@) dh_installinit: what we need to add is a way of explicitly installing an upstream-shipped unit file on package installation
TODO (stapelberg@) dh_installinit: also a way to handle on-demand services (D-Bus or socket activated). In some cases we don't want to start them manually in postinst, but make sure they are stopped on remove or restarted on upgrade iff running. New dh_installinit option: --no-start-after-install
TODO (stapelberg@) dh_installinit: furthermore, the package needs to depend on systemd-support
Edit conflict - other version:
Edit conflict - your version:
End of edit conflict
Edit conflict - your version:
End of edit conflict
General status: user-tagged bugs
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?
dh_installinit
- systemd units are usually shipped upstream, so installing those via debian/$foo.{socket,service} is the *un*common case
- dh_installinit needs to generate code for installed files:
- search for files in /lib/systemd, /usr/lib/tmpfiles.d etc and add the files automatically?
- require to specify the names explicitly via dh_installinit parameters?
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?