Development/Tasks/Packaging/Policies/systemd
From Mandriva Community Wiki
If you want to contribute, simply click on the edit tab. View the other pages to improve and maintain.
Contents |
Systemctl usage
To manage systemd units, you should use systemctl.
systemctl
systemctl is a program used to start and stop systemd units, remove and add symlinks in order to start or stop a unit when specific target is started. You should use it to add your unit to the system unless it supports on-demand activation. Usually unit specifies, which targets should activate. Macros are provided to wrap the call to systemctl. Usage is simple, just use
systemctl <action> <name of unit> ...
There are many actions supported by systemctl; most relevant for packaging tasks are enable, disable, is-enabled, start, stop, restart and try-restart (same as restart unit is started otherwise noop).
RPM macros
In order to integrate your systemd units in a package, you should use the following macros. Exact usage depends on whether you package installs only systemd units, system units and classical SysV initscripts. Additionally there are macros to migrate from package with initscripts to package with systemd units.
Dependencies
To use any of macros below, you should ensure that rpm-helper and systemd-units are available. You should add the following requirements:
BuildRequires: systemd-units BuildRequires: rpm-helper > 0.24 Requires(pre): rpm-helper > 0.24 Requires(post): rpm-helper > 0.24 Requires(preun): rpm-helper > 0.24 Requires(postun): rpm-helper > 0.24
No other special Requires are needed; rpm-helper will pull in systemd-units for /bin/systemctl and /etc/systemd/system directory.
Your package includes only systemd units, no SysV scripts
You have to use following macros:
%preun %_preun_unit unit ... %post %_post_unit unit ... %postun %_postun_unit unit ...
each macro takes a list of units (full name including type suffix).
%_post_unit will enable respective units during package installation if they have [Install] section and allowed by msec (see about caveats below).
%_preun_unit will disable and stop units during package removal.
%_postun_unit will reload systemd and try to restart units that are active during upgrade
Example:
%preun
%_preun_unit %{name}.service
%post
%_post_unit %{name}.service
%postun
%_postun_unit %{name}.service
Your package includes both SysV script and systemd units
You have to use the following macros:
%preun %_preun_service srv unit ... %post %_post_service srv unit ... %postun %_postun_unit unit ...
%_post_service - if passed more than one argument - will interpret first as SysV script name and the rest as unit names. Further processing is exactly as for %_post_unit, except it will also enable SysV script and restart it if systemd is not running, just like it did it before.
%_preun_service will disable both SysV script and systemd unit and stop whichever is appropriate depending on whether systemd is active or not.
ATTN You must always pass both SysV script and systemd unit even if system unit is named srv.service for SysV script srv. There is no heuristic.
ATTN You must pass in all units that replace SysV script functionality. E.g. if SysV script starts two daemons and you provide two units - one for each - pass in both. Both will be enabled and/or restarted together.
ATTN For the same reasons, do not pass in units that are not related to SysV script replacement. Use additional _post_unit and/or _preun_unit for them.
In general, only units that specify [Install] section need to appear in
these macros. But I guess it is good policy to specify full list just
to be sure.
%_postun_unit - same as in previous case.
You can collect all units from multiple macro invocations in single _postun_unit call.
Example:
%preun
%_preun_service %{name} %{?_with_systemd:%{name}.service}
%post
%_post_service %{name} %{?_with_systemd:%{name}.service}
%if %{?_with_systemd:1}
%postun
%_postun_unit %{name}.service
%endif
Migration from pure SysV to systemd (+ sysv)
You have to create two triggers:
%triggerun -- %{name} < Version-Release
%_systemd_migrate_service_pre srv unit ...
%triggerpostun -- %{name} < Version-Release
%_systemd_migrate_service_post %{name} srv unit ...
%_systemd_migrate_service_pre will enable systemd units if corresponding SysV script was active, save is running state and stop SysV script.
%_systemd_migrate_service_post will start units if SysV script was running during pre phase. Of course, only if systemd is active during update
Same rules as for post/preun_service above apply.
You need those macros only for units that replace SysV scripts to ensure proper units are started after update.
If your package completely removes SysV support, add standard %triggerin containing "/sbin/chkconfig --del srv".
Example:
%triggerin -- %{name} < 1-3
%_systemd_migrate_service_in %{name} %{name}.service
%triggerpostun -- %{name} < 1-3
%_systemd_migrate_service_postun %{name} %{name}.service
Caveats
- no netprofile integration
- msec is rather ad-hoc. If you pass in both SysV service and systemd units and SysV passes msec check, systemd units are enabled. Otherwise if unit is service (foo.service) and foo passes msec check, unit is enabled. Otherwise unit is enabled.
- no provision for adding or removing units later.
