9432
Comment:
|
9493
|
Deletions are marked like this. | Additions are marked like this. |
Line 25: | Line 25: |
* TODO: postrm running deb-systemd-helper unconditionally |
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)
- we need a drop-in for systemctl that runs on machines without systemd:
Currently in NEW (init-system-helpers): http://ftp-master.debian.org/new.html
- make systemctl enable/disable call update-rc.d
patch pending: http://t.zekjur.net/systemctl-update-rc.d.patch
TODO (biebl@) integrate this into systemd-201
- 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.
- dh_installsystemd
latest version at http://sprunge.us/YUDM
- We need to perform more tests.
- TODO: postrm running deb-systemd-helper unconditionally
General status: user-tagged bugs
Test reports
Please add your test report in the appropriate category and add a new category if necessary:
sysv-only
kanla 1.2
everything works as expected (no changes), unsurprisingly
sysv+systemd with exact name match
pyroman 0.5.0~alpha1
- no changes necessary (apart from debhelper build-dep bump)
- Everything works as expected. Note that the default with sysv is to not start pyroman though (it modifies the iptables rules). This is implemented via /etc/default/pyroman. Since dh_installinit calls invoke-rc.d, we cannot do anything about this within dh_installsystemd, though. Using dh_installinit --no-start might be a way to fix this.
all-knowing-dns 1.3
- deleted debian/all-knowing-dns.{postinst,prerm,postrm}, which only dealt with systemctl stuff
- deleted debian/all-knowing-dns.install because dh_installinit installs the .service file
- everything works as expected (service is enabled, running, gets stopped/started on upgrades)
sysv+systemd without exact name match
TODO: network-manager, NetworkManager.service vs /etc/init.d/network-manager, uses an Alias
- I’d imagine that the following should work for n-m:
override_dh_installinit: dh_installsystemd --assume-sysv-present --restart-after-upgrade dh_installinit --restart-after-upgrade
alsa-utils 1.0.27-2
- /etc/init.d/alsa-utils vs alsa-store.service and alsa-restore.service. No Alias, masks alsa-utils
- used dh_installsystemd --no-start
- works as expected (not actually tested a reboot, though)
sysv+systemd with special dh_installinit call
(e.g. --restart-after-upgrade)
rsyslog 5.8.11
- The dh_installsystemd generated code looks fine and worked in my tests.
For properly keeping state with the already-existing symlinks, I committed http://anonscm.debian.org/gitweb/?p=collab-maint/init-system-helpers.git;a=commitdiff;h=244fbdca67461cf62f263fa79afde9395f5a4500
dbus 1.6.8
- the .socket unit does not contain an [Install] section, so everything works as expected.
nginx 1.4.1-1
note that in debian/rules, the dh_installsystemd call must be added _after_ the lines that copy the service file
- I removed the explicit systemctl-calls from debian/{postinst,prerm,postrm}
apt-get remove nginx-common && apt-get install nginx-common works as expected, i.e. systemd picks up the changes after removing the package and it is re-enabled properly after installing.
- Since dh_installinit uses --no-start, there is no invoke-rc.d call, so nginx will not be running with systemd either. I think it is safe to say that this matches the package maintainer’s behavior. Maybe we should do something about clarifying whether services should be auto-started, but that’s out of scope for this page/effort.
systemd-only services
(e.g. dbus-activated ones)
TODO: wpasupplicant
TODO: policykit-1, upower: have custom code in postinst to restart the D-Bus service
TODO: consolekit, should not be restarted on upgrades, as it looses state
- colord currently FTBFS, so we cannot test it.
udisks 1.0.4
somewhat off-topic observation: dh_installinit generates update-rc.d/invoke-rc.d code when a service file is present. We should fix this after we got dh_installsystemd in.
- deb-systemd-helper is called, but since the service file does not have an [Install] section, this is a noop. I think there is no need to prevent that call (which would only blow up dh_installsystemd even more).
- the service is properly stopped/started on package upgrades
- the service is properly stopped when the package is purged.
irker 1.17
- everything works as expected
packages not using dh
systemd itself
systemd uses dh and ships a lot of unit files.
HOWTO rebuild a service
Make the updated debhelper in /var/cache/pbuilder/result available in pbuilder (as root):
echo 'deb file:///var/cache/pbuilder/result ./' >> /etc/pbuilder/apt.config/sources.list echo 'BINDMOUNTS="/var/cache/pbuilder/result"' >> /etc/pbuilderrc cd /var/cache/pbuilder/result wget http://t.zekjur.net/debhelper_9.20130509systemd1_all.deb apt-ftparchive packages debhelper_9.20130509systemd1_all.deb > Packages pbuilder --update --override-config
Afterwards, just bump the debhelper dependency in build-depends to = 9.20130509systemd1, build a source package and use pbuilder on that.
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?