systemd

[msrx111]

Ich bin dabei mein System komplett auf systemd umzustellen. (stretch) Netzwerkkkonfiguration und NFS Mounts habe ich schon umgebaut. Jetzt treibt mich die Frage um, ob ich den ganzen SysV Kram nicht loswerden kann. Wenn ich aber

Code: Alles auswählen

apt purge systemd-sysv

im Terminal eingebe erscheint:

Code: Alles auswählen

Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
The following additional packages will be installed:
  cgmanager cron libcgmanager0 libnih-dbus1 libnih1 systemd-shim
Vorgeschlagene Pakete:
  anacron checksecurity
Die folgenden Pakete werden ENTFERNT:
  init* systemd-cron* systemd-sysv*
Die folgenden NEUEN Pakete werden installiert:
  cgmanager cron libcgmanager0 libnih-dbus1 libnih1 systemd-shim
WARNUNG: Die folgenden essentiellen Pakete werden entfernt.
Dies sollte NICHT geschehen, außer Sie wissen genau, was Sie tun!
  init systemd-sysv (wegen init)
0 aktualisiert, 6 neu installiert, 3 zu entfernen und 55 nicht aktualisiert.
Es müssen 463 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 953 kB Plattenplatz zusätzlich benutzt.
Sie sind im Begriff, etwas potentiell Schädliches zu tun.
Zum Fortfahren geben Sie bitte »Ja, tue was ich sage!« ein.
 ?] 

Da bin ich dann doch lieber vorsichtig und frage mal hier nach. Aber irgendwo hatte irgendwer mal geschrieben er habe keine initV scripte mehr. Und ch würde auch gern dahin kommen.....

Edit 1
Und was macht daas Paket systemd-shim bzw warum will er das dann installieren?
Edit 2
Ist wohl so dass ich im falschen Forumsteil geschrieben habe sorry. Vielleicht verschiebt das ein berufener...

[smutbert]

Das hat zumindest scientific geschrieben und das war glaube ich jessie oder sogar noch wheezy - wenn ich mich recht erinnere hat er damals die init-Skripte für die es (noch) keine systemd-Pedants gegeben hat, durch selbst geschriebene systemd-units ersetzt.
Wenn ich mich auf meinem stretch bei den init-Skripten in »/etc/init.d« so umsehe, dann sehe ich kein einziges init-Skript, das noch verwendet wird – zu allen existieren gleichnamige units in »/lib/systemd/system/«

systemd-sysv hat damit übrigens nichts zu tun. Es bietet lediglich die vom alten init-System gewohnten Befehle, wie halt, init, telinit, shutdown, reboot,...

Du redest aber wohl eher von dem Teil von sytemd, der aus den init-Skripten, für die es noch keine systemd-Pendants gibt, automatisch Kompatibilitäts-Systemd-units schreibt, die dann auch unter systemd nichts anderes machen als die Skripte auszuführen. Aus eigener Erfahrung weiß ich, dass das zum Beispiel auf hostapd zutrifft – es ist aber kein Problem selbst eine systemd-unit zu schreiben und damit das init-Skript überflüssig zu machen.
Dieser Teil von systemd lässt sich auch nicht so einfach deinstallieren, es handelt sich vor allem um die Datei »/lib/systemd/system-generators/systemd-sysv-generator« aus dem Paket systemd.

[smutbert]

[…]
Edit 1
Und was macht daas Paket systemd-shim bzw warum will er das dann installieren?
[…]

Du deinstallierst damit - zumindest der Auffassung von apt nach - das init-System systemd (laut Abhängigkeiten ist es genau das Paket systemd-sysv, das einerseits wie gesagt die gewohnten Befehle zu Verfügung stellt, auf die sich immer noch viele Programme und Benutzer verlassen und andererseits von dem eigentlichen systemd-Paket systemd abhängt).

Weil es nun auch schon viele Dienste (zB Displaymanager) gibt, die von Teilen von systemd abhängen, wie zum Beispiel von systemd-logind, sorgen die Abhängigkeiten dafür, dass stattdessen systemd-shim installiert wird, das wiederum grundlegende Schnittstellen von systemd unter anderen init-Systemen zur Verfügung stellt.

Das einzige was dem komplexen System von Abhängigkeiten zu entgehen scheint ist die Tatsache, dass du nach der Aktion nicht nur mehr kein (vollständiges) systemd sondern auch kein anderes init-System hast, aber immerhin warnt es dich davor.


und nur noch zur Ergänzung:
Nach der Aktion würde dein System erst mal nicht mehr booten, weil »/sbin/init« fehlt, aber du kannst in grub den Kernelparameter »init=/lib/systemd/systemd«, dann sollte das System wieder starten. Ob durch das Fehlen der althergebrachten Befehle noch weitere Probleme auftauchen hängt wohl auch von dir und der verwendeten Software ab.

[msrx111]

Also mir geht es eigentlich darum, den Ordner /etc/init.d ujnd die Ordner /etc/rc,x,d und das ganze Kompatibilitätsgedöhne loszuwerden, weil ich mich auf systemd (die Zukunft) und nicht auf sysV (Retro) konzentrieren möchte. Und ich aber augenblicklich nicht überblicke, was ich wie loswerden kann. Und dann verstehe ich auch die Debian Manager nicht so ganz. Warum ist systemd-sysv ein essentielles Paket, wenn da nur "alte" Befehle drin sind, die ich nicht brauche

Also ich formuliere die Frage mal anders:

Mal gesetzt der Fall ist, dass mein System jetzt schon mit systemd korrekt bootet. Was nach meinem Eindrck so ist, denn /sbin/init ist nur ein Link auf systemd

Wie kann ich das sysV Kompatibiltätsgedöhne also doppelte Startscripte, unnötige Links, die ich nur verwirrend finde loswerden?

Vielleicht mit

Code: Alles auswählen

rm -r /etc/init.d

rm -r /etc/rc1.d
rm -r /etc/rc2.d
usw

und dann neu starten und schauen was passiert?

Also nur mal zum Verständnis: Ich hab beispielsweise ifupdown entfernt damit ich das mit systemd mache und dabei ist auch in /etc/systemd die entsprechende Kompatibilitätsdatei für systemd entfernt worden..... So hätte ich das gerne eben auch für en anderen Kram...

Edit: Warum hab ich nach dem purge von systemd-initv kein init? systemd wird nicht deinstalliert und init ist sowieso nur ein link auf systemd
Edit2 Oder muss ich dann evtl den Link von init auf systemd neu setzen?

[smutbert]

[…]Warum ist systemd-sysv ein essentielles Paket, wenn da nur "alte" Befehle drin sind, die ich nicht brauche

Oh, doch die brauchst du. Der erste Prozess, den der Kernel startet ist /sbin/init und der ist im Paket systemd-sysv, auch wenn es nur ein symbolischer Link auf /lib/systemd/systemd ist.

Vielleicht mit

Code: Alles auswählen

rm -r /etc/init.d

rm -r /etc/rc1.d
rm -r /etc/rc2.d
usw

und dann neu starten und schauen was passiert?

Ist (wahrscheinlich) ungefährlich. Ich würde vorher sicherstellen, dass wirklich für jedes Skript in /etc/init.d eine richtige systemd-Unit vorhanden ist (ein Beispiel wo das nicht so ist, habe ich ja bereits genannt).

Also nur mal zum Verständnis: Ich hab beispielsweise ifupdown entfernt damit ich das mit systemd mache und dabei ist auch in /etc/systemd die entsprechende Kompatibilitätsdatei für systemd entfernt worden..... So hätte ich das gerne eben auch für en anderen Kram...

Das ist insofern ein schlechtes Beispiel als ifupdown die Unit /lib/systemd/system/networking.service mitbringt, dank der /etc/init.d/networking ignoriert wird.

Startskripte die nicht verwendet werden tun ja niemanden etwas - sie liegen nur herum für den Fall, dass jemand doch wieder das alte init eventuell mit file-rc, upstart, openrc oder etwas anderes verwenden will...

Edit: Warum hab ich nach dem purge von systemd-initv kein init? systemd wird nicht deinstalliert und init ist sowieso nur ein link auf systemd

Ein sehr wichtiger Link, siehe meine Bemerkung am Anfang dieses Posts.
Wenn du mit dem Kernelparameter dafür sorgst, dass etwas anderes gestartet wird, kannst du auf diesen Link verzichten (oder du setzt wie du schreibst selbst den Link).

Auch danach werden aber Dienste, die ein init-Skript mitbringen (also im Grunde alle Dienste) bei der Installation ihre init-Skripte in /etc/init.d ablegen und das Verzeichnis erstellen, wenn du es gelöscht hast und andere Software wird andere Befehle benötigen, so gibt es zum Beispiel zweifelsohne jede Menge Windowmanager und vielleicht komplette Desktopumgebungen und Displaymanager, die sich zum Herunterfahren auf die Befehle shutdown und reboot verlassen, die ebenfalls Teil des Pakets systemd-sysv sind.

Also es ist potentiell gefährlich, hat möglicherweise Nebenwirkungen bei Updates oder der Installation von manchen Paketen, aber es wird wahrscheinlich funktionieren, wenn du systemd-sysv deinstallierst und/oder die genannten Verzeichnisse löscht.

[KP97]

Ich hatte es schon mehrmals erwähnt, daß ich die Initscripte in /etc/init.d schon lange nicht mehr nutze, vielleicht meint @msrx111 das.
Du brauchst doch erstmal nichts löschen, sondern verschiebe den Ordner init.d an einen anderen Platz und starte dann neu.
Mittlerweile hat Debian für alle Eventualitäten auch die passenden Services in /lib/systemd, daher sollte das System problemlos starten.
Schau anschließend mit journalctl -b -p5 ins Log, ob da Fehlermeldungen auftauchen.
An anderer Stelle hatte ich auch vor kurzem erwähnt, daß der Service networking.service nur noch von dem alten Initscript gebaut wird und auch eine Altlast ist, die zwar nicht stört aber auch nicht notwendig ist.
Das Netzwerk wird gesteuert von systemd-networkd.service, daher kann der "alte" disabled und der "neue" enabled werden, wenn das nicht schon geschehen ist.
Abfragen mit "systemctl status systemd-networkd" und auch mit "networkctl status".

[msrx111]

Also erstmal danke für die ausführlichen Erklärungen. Auf jeden Fall sehe ich jetzt etwas klarer. Ich bin wahrscheinlich einfach mal wieder zu schnell, und die Programmentwickler sind es eben nicht und brauchen noch Zeit um sich auf systemd einzustellen. Die werde ich ihnen dann wohl geben müssen und akzeptieren, dass man bei debian darauf achtet, dass alt und neu eine gewisse Zeit parallel betrieben werden müssen, damit dann auch alles funktioniert. In einem oder zwei Jahren sieht das wahrscheinlich schon ganz anders aus. Da hat man dann nur noch systemd und kein sysv mehr. Ich kann aber nur jedem empfehlen gewisse Dinge schon mit systemd zu konfigurieren. (beispielsweise das Netzwerk) Systemd ist deutlich Auskunftsfreudiger und wirklich auf Sicht besser als das liebgewonnene SystemV. Und meine Rechner booten dank systemd und SSDs in wenigen Sekunden statt wie früher in Minuten.....
@KP97
Ja ich glaube in einem deiner Beiträge hab ich das mit den nicht genutzten initscripten gelesen.
Ja ich habe systemctl enable systemd-resolved.service systemctl enable systemd-networkd.service auf meinem System ausgeführt bzw mich an diese Anleitung:
https://wiki.ubuntuusers.de/systemd/networkd/
gehalten. Da ich auf meinem Laptop Probleme mit dem Networkmanager und WLan hatte hab ich sogar mit einem bisschen lesen mein WLAN mit WPA2 darüber zum laufen bekommen.
Das mit dem Verschieben des init.d Ordners werde ich mal austesten.

Danke an alle ich werde berichten ob und welche Probleme ich hatte....

[msrx111]

Wenn ich das Paket systemd-sysv entferne wäre das System tatsächlich unbootbar, weil er den Link von sbin/init auf /lib/systemd/systemd entfernt. Ob das System booten würde wenn ich den Link händisch erstellen würde hab ich nicht getestet. Wenn ich die rc und den init.d Ordner umbenenne bzw lösche macht das keine Probleme.

[TomL]

In einem oder zwei Jahren sieht das wahrscheinlich schon ganz anders aus. Da hat man dann nur noch systemd und kein sysv mehr.

Es gibt schon seit Jessie kein sysvinit mehr in Debian. Es ist lediglich so, dass nachwievor alte Start-Scripte genutzt werden können, und das wird auch immer so sein, weil man schlichtweg nie gänzlich auf zu startende Scripte wird verzichten können. Es wird für ein Startscript unter Systemd lediglich kein Symlink mehr in den runlevels angelegt (weils die nicht mehr gibt), sondern via autogenerator eine service-unit erstellt, die exakt das gleiche macht... und zwar das Script während der Bootphase starten.

Der einige Nachteil von Runlevel-Scripts ist, dass sie nach Schema-F in den systemd-Boot eingebaut werden, das heisst, man kann sie nicht so präzise in den Zeitablauf platzieren, wie man das mit einer manuell erstellten Unit kann. Das kann bei Abhängigkeiten zu Problemen führen, aber das tuts nicht generell. Der Vorteil von systemd-Units ist, dass sie ein Start-Script, was als reines Start-Script zum Starten eines Binaries konzipiert war, ersetzen könnnen.... sofern das Start-Script nicht vorher besondere Aufgaben erfüllt hat.... denn dann wäre es nicht ersetzbar.

Was man also machen kann... man kann sich init.d-Scripts anschauen, ob die wirklich nur "was" starten... dann kann man sie tatsächlich durch eine Unit ersetzen, ansonsten würde ich da schön die Finger von lassen. Die Frage ist also: Ist es nur ein Startscript oder ist das zu startende Script schon ein/der Job? Systemisch ist beides nicht zu unterscheiden, weil auch das als Job konzipierte Script weitere Prozesse starten wird. Außerdem halte ich das sowieso für Zeitverschwendung, mich heute noch mit sysvinit oder dessen letzten Zuckungen zu befassen, das verschwindet von ganz alleine. Und wirklich vollständig verschwinden wird nur der typische Script-Header für init.d-Scripte.... den Teil übernimmt dann die Service-Unit, in vielen Fällen wird der Rest aber bleiben.

[KP97]

....sofern das Start-Script nicht vorher besondere Aufgaben erfüllt hat.... denn dann wäre es nicht ersetzbar.

Hast Du da mal ein Beispiel? Ich kenne kein einziges Programm, das noch ein solches Script voraussetzt. Die Programme, egal welche, bringen mittlerweile auch alle eine Serviceunit mit, die beim Installieren an den richtigen Platz geschrieben wird. Sollte es sich allerdings um alte Programme handeln, z.B. aus Snapshot, muß ich mir eher Gedanken um veraltete und nicht funktionierende Libs machen als um Startscripte.
Und sollte ich mal auf den Gedanken kommen, ein solches altes Programm installieren zu wollen, ist eh Handarbeit angesagt. Dann spielt das Anlegen einer eigenen Unit auch keine Rolle.
Meines Wissens ist Debian die einzige Distri, die noch zweigleisig fährt. Das rührt wohl daher, daß Debian auch auf vielen Servern im professionellen Umfeld eingesetzt wird. Da gelten andere Bedingungen.
Arch z.B. hat schon seit Jahren keine Startscripte mehr, aber die waren auch die ersten, die das konsequent umgesetzt haben.
Auf einem Desktop mit Stretch sind die Scripte in init.d nicht mehr notwendig.
Bei Wheezy gab es noch kein systemd, und bei Jessie war es noch ziemlich rudimentär und hakelig, da sollte man die Scripte behalten.

@msrx111
Das Paket systemd-sysv ist noch eine Abhängigkeit und sollte nicht entfernt werden.
Das hat @smutbert aber auch ausführlich erklärt.

[TomL]

Hast Du da mal ein Beispiel? Ich kenne kein einziges Programm, das noch ein solches Script voraussetzt.

Nee, so kann man das imho nicht betrachten. Man muss das meiner Meinung nach analog zu allen Tätigkeiten betrachten, die den erfolgreichen Start eines Pogramms erst ermöglichen. Früher hat beispielsweise ein Startscript auch vorbereitende Aufgaben übernommen, die für den Start des eigentlichen Programmes notwendig waren. Zum Beispiel wie ich das an verschiedenen Stellen selber mache, z.B. vor dem Programmstart ein Log-Dir-Verzeichnis vorbereiten oder erstellen und mit Rechten versehen, so dass das eigentliche Programm diesen in seiner Conf stehenden Log-Path auch wirklich verwendbar vorfindet. Daran hat sich von früher zu heute nix geändert.

Heute macht das gleiche immer noch ein Script, nur wird diese Zusatzaufgabe nicht im Startscript erledigt, sondern in einem (ich nenns mal Support-Script) via ExecStartPre vorher gestarteten eigenen Prozess. Und natürlich, oberflächlich betrachtet wird in den Units jetzt das Binary mit ExecStart direkt und ohne init.d-Script gestartet. Aber wenn man das so sieht, muss man ein Init.d-Sript auch allein auf den Start des Binaries beziehen, ohne Supportaufgaben... und dann sind die Unterschiede schon wieder weniger groß. Und was macht systemd heute...?... es legt Symlinks der Units an... so wie früher update.rc auch Symlinks angelegt hat. Also so ein großer Unterschied ist da insgesamt betrachtet wirklich nicht. Zweifelsfrei ist bei Systemd der große Vorteil die Parallelisierung der Startprozesse, das hats bei sysvinit nicht gegeben. Aber auf diese Support-Aufgaben, die vor dem Start des Binaries erfolgen, kann man auch nur dann verzichten, wenn das Binary selber die komplette Funktionalität abbildet. Das halte ich aber nicht für notwendig und auch nicht umfassend für lösbar.... schon mal gar nicht, wenn das Binary unter eingeschränkten Rechten läuft. In dem Fall muss ein anderer Job mit höheren Rechten alle Vorbereitungen treffen... eben via ExecStartPre gestartet.

Und wenn Du beispielsweise einen Paketfilter einrichten willst, egal ob iptables oder nftables, dann kommst Du neben der Unit auch nicht um ein Script rum, welches zum eigentlichen Prozess "Paketfilter" immer auch Supportaufgaben übernimmt, z.B. dynamisch einen IPv6-Prefix in einem Dualstack-System ermitteln, weil die IP noch täglich geändert wird und im Filter für ein saddr-Binding ans LAN gewollt ist. Oder um das Application-Layer-Gateway dynamisch zum Filter zu laden, damit der Conntrack-State von Verbindungen genutzt werden kann, um z.B. nicht vorauseilend anwendungsbezogene willkürlich verwendbare unprivilegierte Ports öffnen zu müssen, die eigentlich nur "related" sind.... was z.B. bei FTP der Fall ist. Da gibt es viele solcher Fälle.....

[nudgegoonies]

Es gibt schon seit Jessie kein sysvinit mehr in Debian. Es ist lediglich so, dass nachwievor alte Start-Scripte genutzt werden können, und das wird auch immer so sein, weil man schlichtweg nie gänzlich auf zu startende Scripte wird verzichten können. Es wird für ein Startscript unter Systemd lediglich kein Symlink mehr in den runlevels angelegt (weils die nicht mehr gibt), sondern via autogenerator eine service-unit erstellt, die exakt das gleiche macht... und zwar das Script während der Bootphase starten.

Sieht mir aber nicht so aus. Ich habe das gerade mal in der Stretch VM mit meiner Mate Desktop Installation ausprobiert. Ein apt-get install sysvinit-core installiert ein paar Abhängigkeiten (cgmanager, initscripts, startpar, systemd-shim, sysvrc, einige libraries) und deinstalliert systemd-sysv. Danach ist /sbin/init das systemv init. Auch die cmdline vom Kernel ist nicht auf ein anderes init umgebogen. Es werden aber aus dem systemd Paket der systemd-logind und systemd-udev als Dienste gestartet. udev war ja mal eigenständig und ist in das systemd Paket gewandert. Und die logind Funktionalität war früher in den Login-Managern wie GDM. Wenn man aber systemd mit dem gleichnamigen Paket endgültig entfernen will, dann will der grafische Desktop nicht mehr. Ich vermute wegen lightdm (Abhängigkeit: logind) und gvfs (Abhängigkeit: systemd).

[TomL]

Es gibt schon seit Jessie kein sysvinit mehr in Debian.

Sieht mir aber nicht so aus. Ich habe das gerade mal in der Stretch VM mit meiner Mate Desktop Installation ausprobiert. Ein apt-get install sysvinit-core installiert

Ich entschuldige mich, Du hast natürlich Recht - ich habe mich völlig unklar ausgedrückt. Natürlich gibts sysvinit noch in Debian, genauer gesagt gibts das noch im Repo... es ist lediglich nicht mehr im Default-Weg der in den vom Installer eingerichteten Standard-Installationen vorhanden. Aber mal ehrlich, wer ist schon so bekloppt und installiert sich freiwillig diese Krücke sysvinit, wenn man ohne Aufwand systemd haben kann und das sogar -ohne was dafür zu tun- einfach so kriegt....

[nudgegoonies]

Jedem das seine. Hat beides Vor- und Nachteile. Ich will die Vorteile von SystemD nicht mehr missen. Für die Nachteile könnte ich die Entwickler aber manchmal verfluchen. Vor allem den Drecks-daemon-reload endlich abzuschaffen wird immer wieder abgebügelt. Aber Devuan verstehe ich jetzt nicht mehr so ganz, wo Debian 9 sogar mit GUI (ok, habe nur Mate getestet) mit sysvinit gut funktioniert. Eine ganze Distro zu pflegen nur weil udev und logind keine eigenen Pakete sind und man krampfhaft das systemd Paket loswerden will? Egal. Offtopic. /etc/inid.d Kompabilität wird kein init-System los. Es gibt genug firmeninterne Dienste, alte Programme und selbstgeschriebens Zeug, was in den letzten 4 Jahren nicht und auch in 4 Jahren noch nicht migriert sein wird. Außerdem wird es immer alternative init-Systeme und andere Unixe geben. Und sysv scripte sind der gleiche Nenner für Zeug, das überall laufen muss

[guennid]

Debian 9 sogar mit GUI (ok, habe nur Mate getestet) mit sysvinit gut funktioniert.

WM openbox tut auch. sane ohne systemd-udev nicht.