Univention Bugzilla – Bug 43330
UCS-4.2 with systemd
Last modified: 2020-12-01 10:20:42 CET
Debian-Jessie uses systemd by default; UCS-4.2 should, too.
Bug #38438: The legacy init-scripts must be LSB-compliant, as that information is used to start the services in the right dependency order
- systemd needs to ignore UCR-diverted files
- bind9.service clashes with univention-bind*
- runit.service leads to duplicate runsvs.
- SAML/memcache/stunnel4 need to be tangled out: A systemd.unit *MUST* *NOT* start any other unit - this leads do dead-locks!
Bug #42380: /etc/network/if-*.d/ conflicts with systemd, as this might lead to dead-locks
Debian has implemented some logic, but it still shows problems: <https://bugs.debian.org/810656>
- services should detect new interfaces themselves, so restarting them becomes obsolete
Bug #43313: Debian sources /lib/lsb/init-functions.d/40-systemd to redirect most actions to `systemctl`, but some actions are unknown to systemd and thus break it
crestart → systemtl try-restart $xxx.service
Debian provides to wrappers:
- invoke-rc.d: Must be used from Debian-Maintainer-Scripts to co-op with chroot-environments, where services MUST NOT be started; there "invoke-rc.d" calls "policy-rc.d" and does not start the service; this is used by debootstrap (and others)
- service: Used mostly by humans, as it has tab-completion
Both scripts are "systemd"- (and upstart)-aware, but still fall back to the init-scripts in several cases (unknown actions, sometime reload). Debian-Jessie as the policy, that each package MUST still ship a init script, so that dependency is satisfied trivially.
For UCS-4.2 we also must still ship init scripts, as
- they are required by "invoke-rc.d" and "service", otherwise "invoke-rc.d" will do nothing
- we still call "/etc/init.d/$service $action" directly from lots of locations
Our init scripts can be minimal and
- should delegate all actions to "systemctl" if systemd is to be used for that service. This is especially true for services currently using "runsv", as a "traditional" init-script (not using runsv) would loose the process monitoring aspect.
- must still contains the LSB headers as to not break systemd-generator/insserv.
The current idea is to generate the systemd.unit files through UCR:
- we don't want to call an intermediate shell script to get the parameters by calling "ucr", as this hides the actual command, which gets run.
- Care must be taken about conflicting units (univention-bind*.service)!
- Dynamically generating the unit file through UCR has the draw-back, that dh-systemd can't be used: The required calls to "systemctl install/enable" are generated during package-build-time which is too early for UCR.
- We might need a (Python-)library to generate those unit files more easily, especially the (shell-)quoting for exec*
univention-directory-listener and univention-directory-notifier (and probably others) log to STDOUT, which previously was redirected to /var/log/univention/$service.log. systemd.service does not allow native redirection to files by default; instead syslog or journal are recommended.
- journal has the benefit to being searchable/indexed
- syslog has the benefit of setting up a central log server.
(In reply to Philipp Hahn from comment #0)
> The current idea is to generate the systemd.unit files through UCR:
> - we don't want to call an intermediate shell script to get the parameters
> by calling "ucr", as this hides the actual command, which gets run.
> - Care must be taken about conflicting units (univention-bind*.service)!
> - Dynamically generating the unit file through UCR has the draw-back, that
> dh-systemd can't be used: The required calls to "systemctl install/enable"
> are generated during package-build-time which is too early for UCR.
> - We might need a (Python-)library to generate those unit files more easily,
> especially the (shell-)quoting for exec*
Generating a complete $service.service file by UCR seems to have many issues, so generating a "/etc/default/$service.conf" file and including that through EnvironmentFile=/etc/default/$service.conf seems to be a lot easier.
Alternative: write supplement file to /etc/systemd/system/$service.service.d/ucr.conf
See Bug #43450 comment 4 for issues with the current SysV compatibility systemd-generator.
The details are done through the individual sub bugs.
r77214 | Bug #43330: systemd CL
UCS 4.2 has been released:
If this error occurs again, please use "Clone This Bug".