Bericht: stretch mit anderem Init-System
Verfasst: 12.03.2018 17:28:42
Hallo,
ich hatte kürzlich mal Lust, ein anderes Init-System auszuprobieren. Gründe spielen jetzt hierfür keine Rolle, ich will hier schließlich nicht die tausendste Diskussion anfangen, ob es systemd braucht oder nicht. Ich möchte nur für Interessierte darstellen, ob/wie man ein anderes Init-System verwenden kann, wenn man das möchte.
Dabei bleibt systemd in meinem jetzigen Entwicklungsstadium für folgende Dinge zuständig (psv ist ein Alias für "ps -eHo pid,pgid,sid,ppid,tty,user,ruser,time,comm"):
Und folgendes ist von systemd installiert:
Gvfs und udisks2 habe ich deinstalliert, da ich das eigentlich nicht brauche - nicht, weil es nicht weiter funktioniert hätte (s. systemd-shim weiter unten).
Für Audio-CDs habe ich vlc, für Daten-CDs fstab:
Für meine Digital-Kamera habe ich zwei - mir ganz neue und sehr gut funktionierende - Programme entdeckt, nämlich gphoto2 und gphotofs. Basieren auf den gleichen gphoto-libraries wie gvfs-backends.
Doch nun zum Init-System. Erst habe ich mir überlegt, ob ich in meiner Experimentierfreude gleich das init der suckless-Leute nehme, also sinit. Wenn man daraus - "the Debian way" - ein schönes deb-Paketchen schnürt, wird das bestimmt nicht übel. Aber das war mir dann doch erstmal zu viel für den Anfang, also habe ich ganz klassisch sysvinit-core installiert, eine der möglichen Abhängigkeiten des "essential"-Paketes init. Reboot - funktioniert.
Rootless Xorg und alles drum und dran funktioniert immer noch, auch udisks2 würde immer noch funktionieren, wenn ich es nicht deinstalliert hätte. Das liegt an systemd-shim, einer Kompartibilitäts-Schicht zwischen systemd und einem beliebigen Init-System.
Insgesamt ist zu sagen: Wenn sich die Debian-Maintainer schon Mühe geben, dass man ein anderes Init-System nutzen kann, warum soll man's dann nicht mal probieren? Ich jedenfalls hatte Lust dazu, weil ich auch zusätzliche Funktionen von systemd nicht brauche (obwohl eine svg-Grafik des Boot-Vorgangs natürlich schon cool ist... ).
Außerdem mag ich "ursprüngliche" und klassische Methoden, obwohl ich sicher wesentlich jünger bin als der Alters-Durchschnitt hier im Forum, wenn ich selbigen mal auf 40 Jahre schätze.
Vielleicht findet es der ein oder andere Leser ja interessant, diesen Beitrag hier zu lesen. Ich werde jetzt mal sehen, ob ich systemd wegen logind und polkit noch behalte oder wie ich das mache.
Systemd-udevd hängt - anders als der Prozessname suggeriert - eh nicht von systemd ab. Zwar sieht es erst so aus:
Aber: Das alles ist im Paket udev, welches nicht vom Paket "systemd" abhängt:
ich hatte kürzlich mal Lust, ein anderes Init-System auszuprobieren. Gründe spielen jetzt hierfür keine Rolle, ich will hier schließlich nicht die tausendste Diskussion anfangen, ob es systemd braucht oder nicht. Ich möchte nur für Interessierte darstellen, ob/wie man ein anderes Init-System verwenden kann, wenn man das möchte.
Dabei bleibt systemd in meinem jetzigen Entwicklungsstadium für folgende Dinge zuständig (psv ist ein Alias für "ps -eHo pid,pgid,sid,ppid,tty,user,ruser,time,comm"):
Code: Alles auswählen
robert@RobertDebian:~$ psv | grep systemd
340 340 340 1 ? root root 00:00:00 systemd-udevd
2229 1876 1876 1 ? root root 00:00:00 systemd-logind
Code: Alles auswählen
ii libpam-systemd:amd64 232-25+deb9u2 amd64 system and service manager - PAM module
ii libsystemd0:amd64 232-25+deb9u2 amd64 systemd utility library
ii systemd 232-25+deb9u2 amd64 system and service manager
ii systemd-shim 10-3 amd64 shim for systemd
Für Audio-CDs habe ich vlc, für Daten-CDs fstab:
Code: Alles auswählen
/dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0
Doch nun zum Init-System. Erst habe ich mir überlegt, ob ich in meiner Experimentierfreude gleich das init der suckless-Leute nehme, also sinit. Wenn man daraus - "the Debian way" - ein schönes deb-Paketchen schnürt, wird das bestimmt nicht übel. Aber das war mir dann doch erstmal zu viel für den Anfang, also habe ich ganz klassisch sysvinit-core installiert, eine der möglichen Abhängigkeiten des "essential"-Paketes init. Reboot - funktioniert.
Rootless Xorg und alles drum und dran funktioniert immer noch, auch udisks2 würde immer noch funktionieren, wenn ich es nicht deinstalliert hätte. Das liegt an systemd-shim, einer Kompartibilitäts-Schicht zwischen systemd und einem beliebigen Init-System.
Insgesamt ist zu sagen: Wenn sich die Debian-Maintainer schon Mühe geben, dass man ein anderes Init-System nutzen kann, warum soll man's dann nicht mal probieren? Ich jedenfalls hatte Lust dazu, weil ich auch zusätzliche Funktionen von systemd nicht brauche (obwohl eine svg-Grafik des Boot-Vorgangs natürlich schon cool ist... ).
Außerdem mag ich "ursprüngliche" und klassische Methoden, obwohl ich sicher wesentlich jünger bin als der Alters-Durchschnitt hier im Forum, wenn ich selbigen mal auf 40 Jahre schätze.
Vielleicht findet es der ein oder andere Leser ja interessant, diesen Beitrag hier zu lesen. Ich werde jetzt mal sehen, ob ich systemd wegen logind und polkit noch behalte oder wie ich das mache.
Systemd-udevd hängt - anders als der Prozessname suggeriert - eh nicht von systemd ab. Zwar sieht es erst so aus:
Code: Alles auswählen
robert@RobertDebian:~$ apt-file search systemd-udev
udev: /lib/systemd/system/sockets.target.wants/systemd-udevd-control.socket
udev: /lib/systemd/system/sockets.target.wants/systemd-udevd-kernel.socket
udev: /lib/systemd/system/sysinit.target.wants/systemd-udev-trigger.service
udev: /lib/systemd/system/sysinit.target.wants/systemd-udevd.service
udev: /lib/systemd/system/systemd-udev-settle.service
udev: /lib/systemd/system/systemd-udev-trigger.service
udev: /lib/systemd/system/systemd-udevd-control.socket
udev: /lib/systemd/system/systemd-udevd-kernel.socket
udev: /lib/systemd/system/systemd-udevd.service
udev: /lib/systemd/systemd-udevd
udev: /usr/share/man/man8/systemd-udevd-control.socket.8.gz
udev: /usr/share/man/man8/systemd-udevd-kernel.socket.8.gz
udev: /usr/share/man/man8/systemd-udevd.8.gz
udev: /usr/share/man/man8/systemd-udevd.service.8.gz
Code: Alles auswählen
robert@RobertDebian:~$ aptitude show udev | grep Depends
Depends: libacl1 (>= 2.2.51-8), libblkid1 (>= 2.19.1), libc6 (>= 2.17), libkmod2 (>= 5~), libselinux1 (>= 2.1.9), adduser, libudev1 (= 232-25+deb9u2), lsb-base (>= 3.0-6), util-linux (>= 2.27.1), procps
PreDepends: dpkg (>= 1.17.14)