Hier schreibe ich vorläufig — und erstmal auch nur ins Unreine — auf, was ich bisher zum Thema systemd (heraus-)gefunden habe.

Das Ganze scheint ein hochgradiges Problem der vorliegenden systemd-Version zu sein. Was ich hier beschreibe, funktioniert unter SuSE 13.1 mit systemd-208-23.3.x86_64. Unter SuSE12.3 mit systemd-195-13.45.1.x86_64 funktioniert offenbar nur ein Teil.

Nützliche Informationen in Form von Dateien sind mir bisher in

	/etc/systemd
	/lib/systemd
	/usr/lib/systemd

Eines der ersten Dinge, die ich mit systemd bewerkstelligen mußte, war nach dem Hochfahren des Rechners ein paar zusätzliche Skripte ablaufen zu lassen. Das hatten wir bis dato (also vor SuSE12.1) einfach in die Datei

	/etc/init.d/after.local

Während meiner Suche, wie ich das mit dem systemd wieder ans Spielen kriegen kann, bin ich über etwas gestolpert, was ich mir als

	#
	## http://forums.opensuse.org/blogs/jdmcdaniel3/systemd-using-after-local-script-opensuse-12-1-71/
	## "systemd and using the after.local script in openSUSE 12.1"
	## by jdmcdaniel3 
	## 
	## new URL:
	## https://forums.opensuse.org/content.php/120-systemd-and-using-the-after-local-script-in-openSUSE-12-1
	## (01/2015)
	##
	## !!!
	## do not forget to enable this service:
	##	systemctl enable /lib/systemd/system/after.local.service
	## !!!
	##
	#  This file is part of systemd.
	#
	#  systemd is free software; you can redistribute it and/or modify it
	#  under the terms of the GNU General Public License as published by
	#  the Free Software Foundation; either version 2 of the License, or
	#  (at your option) any later version.

	[Unit]
	Description=/etc/init.d/after.local Compatibility
	After=network.target
	ConditionFileIsExecutable=/etc/init.d/after.local

	[Service]
	Type=oneshot
	ExecStart=/etc/init.d/after.local
	TimeoutSec=0
	StandardOutput=tty
	RemainAfterExit=yes
	SysVStartPriority=99

	[Install]
	WantedBy=multi-user.target

Und in der

	/etc/init.d/after.local

	# Seit SuSE12.1 wird angefangen 'init' & Co. durch 'systemd' zu ersetzen.
	# Dafuer muss ausser dieser Datei auch
	#	/lib/systemd/system/after.local.service
	# angelegt und mit
	#	systemctl enable after.local.service
	# aktiviert werden.
	#

Bei RedHat Scientific Linux 7.3 war ich erstmals mit dem Problem konfrontiert, dass im Paket für den ftp-Server keine Datei für /etc/xinetd.d mehr mitgeliefert wurde, wohl aber für den systemd.

Nach etwas Suchen bin ich dann über

	systemctl enable vsftpd.target
	systemctl start vsftpd.target

Wenn ich jetzt noch gleich an die Firewall gedacht hätte … ich hätte mich glatt für gut gehalten.

Bei SuSE kann man sich nach einem Update einzelner oder mehrerer Pakete mit zypper ps anzeigen lassen welche Prozess unter ausgetauschten oder gelöschten Dateien “leiden”. In einer der Spalten wird auch (manchmal) angegeben, welcher Service neu gestartet werden muss damit der betreffende Prozess aus der Liste verschwindet. Oft genug steht in der mit Service überschriebenen Spalte nichts und der Name des Services weicht vom Prozessnamen ab.

Deshalb habe ich hier (an für mich zentraler Stelle) eine Sammlung von Zuordnungen hinterlegt.
Diese Liste erhebt keinerlei Anspruch auf Vollständigkeit; das ist einfach nur, was mir bisher so untergekommen ist …
(Vielleicht werde ich mal noch die Einträge, bei denen Prozess- und Service-Name übereinstimmen in eine separate Tabelle auslagern; ob das der Übersichtlichkeit wirklich dienlich sein wird???)

Prozess	Service
acpid	acpid
agetty	getty@tty1 getty@tty2
auditd	auditd
bluetoothd	bluetooth
cleanup	cleanup
console-kit-daemon	console-kit-daemon
cron	cron
cupsd	cups
dbus	dbus
dbus-daemon	dbus
dmevent	dm-event
gdbus	dbus
gmain	udisks
gpm	gpm
haveged	haveged
irqbalance	irqbalance
kdm	display-manager
lvmetad	lvm2-lvmetad
mcelog	mcelog
mdadm	mdmonitor
ntpd	ntpd
polkitd	polkit
rpc.statd	rpc-statd
rpcbind	rpcbind
snmpd	snmpd
sshd	sshd
syslog-ng	syslog
systemd-journald	systemd-journald
systemd-logind	systemd-logind
systemd-udevd	systemd-udevd
wickedd*	wickedd
wpa_supplicant	wpa_supplicant
xe-daemon	xe-linux-distribution
xinetd	xinetd

Mit

	systemctl --all --full

	host:[~]# systemctl --all --full | grep ntp
	ntpd.service                           loaded    active   running   NTP Server Daemon
	host:[~]# systemctl status ntpd
	ntpd.service - NTP Server Daemon
	   Loaded: loaded (/usr/lib/systemd/system/ntpd.service; enabled)
	   Active: active (running) since Mon 2015-03-23 07:53:19 CET; 3 days ago
	     Docs: man:ntpd(1)
	 Main PID: 1611 (ntpd)
	   CGroup: /system.slice/ntpd.service
		   ââ1611 /usr/sbin/ntpd -p /var/run/ntp/ntpd.pid -g -u ntp:ntp -c /etc/ntp.conf

	Mar 23 07:53:19 host start-ntpd[1592]: Starting network time protocol daemon (NTPD)
	host:[~]#

Auf dem neu einzurichtenden Mailing-Listen-Server (CentOS Stream 9) war das auto-update angestellt. Ist ja wohl ziemlich nützlich: Es wird geschaut und mitgeteilt. ob es Updates gibt. In der entsprechenden Konfigurationsdatei konnte man früher bei yum dann noch einstellen, ob die Update heruntergeladen werden sollten und mit apply_updates = false verhindern, dass sie automatisch installiert wurden.
Ob es am Übergang von yum zu dnf liegt? Die Vokabel apply_updates gibt es immer noch und man kann sie auch auf false setzen; wirkt nur leider nicht: die Updates werden trotzdem eingespielt! (Vorsichtshalber gibt es auch keine Mitteilung, wenn z. B. nach einem Kernel-Update der Rechner neu gebootet werden sollte; Da muss man sich mit dnf needs-restarting -r selbst drum kümmern!)
Relativ schnell stößt man noch auf: … dnf-automatic.timer. notifyonly.timer. download.timer and install.timer override this setting. Nur, wo man diese Timer findet, steht da nicht.
Man braucht nur auf systemctl list-timers zu kommen und darauf, dass sich hinter einer Abkürzung wie dnf-automatic-ins so etwas wie dnf-automatic-install.timer versteckt.
Ich werde diesen Timer jetzt mal abstellen und dann sehe ich ja, ob die Updates dann nicht mehr automatisch installiert werden. Ich bin gespannt …
Yup! Funktioniert so, wie ich mir das vorgestellt hatte.

Was hier steht, stand früher mal weiter oben. Inzwischen tut es jedoch nicht mehr oder nicht mehr so wie beschrieben. Zum Wegwerfen war's mir doch zu schade; also habe ich es hier geparkt:

Etwas spezieller wird es bei den Netzwerk-Interfaces; mit systemctl restart network.service werden alle Interfaces herunter- und wieder hochgefahren. Das ist aber nicht immer gewünscht. Mit

	systemctl enable network@vlan1008.service
	systemctl start network@vlan1008.service

Ebenso andere Services wie arpwatch, die ich mit

	systemctl enable arpwatch@vlan1008.service
	systemctl start arpwatch@vlan1008.service

Die auf diesen Seiten zum Ausdruck gebrachten Meinungen sind die meinigen, nicht notwendigerweise die der Universität Osnabrück. (Es sei denn, sie würden zufällig übereinstimmen oder wären entsprechend gekennzeichnet.)

Zum Thema "Links":

Bei "Links" handelt es sich stets um "lebende" (dynamische) Verweisungen. Gernot Skalla hat bei der erstmaligen Verknüpfung zwar den fremden Inhalt daraufhin überprüft, ob durch ihn eine mögliche zivilrechtliche oder strafrechtliche Verantwortlichkeit ausgelöst wird. Er überprüft aber die Inhalte, auf die er in seinem Angebot verweist, nicht ständig auf Veränderungen, die eine Verantwortlichkeit neu begründen könnten. Wenn er feststellt oder von anderen darauf hingewiesen wird, daß ein konkretes Angebot, zu dem er einen Link bereitgestellt hat, eine zivil- oder strafrechtliche Verantwortlichkeit auslöst, wird er den Verweis auf dieses Angebot aufheben.