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 Bug #42406: - 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> <https://bugs.debian.org/754218> - 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 graceful-restart (slapd) graceful-stop (slapd) 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
OK
UCS 4.2 has been released: https://docs.software-univention.de/release-notes-4.2-0-en.html https://docs.software-univention.de/release-notes-4.2-0-de.html If this error occurs again, please use "Clone This Bug".