Re: Buster ohne systemd
Hi Sven.
Sorry, wenn das etwas wie ein Rant ausfällt, aber da waren einfach zu
viele Stellen in deiner Antwort, wo ich den Eindruck hatte, dass Du
einfach nicht weißt, was im Bereich Sysvinit gerade Phase ist.
Sven Hartge - 06.09.19, 19:57:19 CEST:
> Paul Muster <exp-311219@news.muster.net> wrote:
> > einige meiner Systeme laufen nach wie vor ohne systemd.
> > Sichergestellt wird das durch diese Konfiguration:
> >
> > system:~# cat /etc/apt/preferences.d/no-systemd
> > Package: systemd-sysv
> > Pin: release o=Debian
> > Pin-Priority: -1
> > system:~#
> >
> > Wird das mit Buster weiterhin funktionieren? Oder gehen die
> > Debian-Entwickler mittlerweile davon aus, dass alle Systeme mit
> > systemd laufen?
>
> Offiziell nicht.
>
> Aber du hast natürlich das offensichtliche Problem, das der Code,
> welcher nicht-systemd-Systeme unterstützt mit der Zeit vom Bitrot
> heimgesucht wird, weil er nicht mehr wirklich weiter gepflegt wird.
sysvinit, startpar, insserv und einige weitere erfahren seit einiger
Zeit intensive Pflege in Debian. Ich hab vor einiger Zeit dabei mit
geholfen, dass eine Zusammenarbeit zwischen Debian und Devuan-Entwickler
entstand (Debian Init Diversity). Und ich würde sagen, die war bisher
äußerst produktiv.
sysvinit, startpar, insserv haben seit einiger Zeit auch wieder einen
Upstream-Maintainer, der aktiv Bugreports bei Debian durchforstet und
fixt. In den letzten Monaten haben Upstream-, Devuan- und Debian-
Entwickler ohne Weiteres mehrere Dutzend Bugreports gefixt. Ich hab nicht
genau gezählt, aber es könnten auch locker über 50 sein. Darunter
durchaus auch über 5 Jahre nicht gefixte Bugs.
Schau Dir einfach mal das Changelog von sysvinit-core an… und staune.
Mit allem Respekt, Sven, hier von Bitrot zu sprechen… das trifft so aus
meiner Beobachtung heraus einfach nicht zu.
> Das betrifft sowohl Debian selbst als auch natürlich die paketierten
> Programme selbst, deren Entwickler sich in einer immer mehr auf
> systemd fokussierenden Welt auch eben mehr in diese Richtung
> orientieren.
Zudem gibt es mit elogind auch eine Alternative zu systemd-logind. Das
ist zwar im Grunde der aus Systemd herausgelöste systemd-logind als
Extra-Paket unter eigenen Namen.
Damit, und mit derzeit bei Debian, nicht bei Devuan, noch einem Paket
aus Experimental, das einige Symlinks umbiegt, und so nicht in Debian
reinkommen darf… habe ich hier seit Monaten ein Debian Unstable mit KDE
Plasma laufen. Es laufen Arbeiten, ein default-logind und generisches
logind-Paket einzuführen und die Abhängigkeiten der Pakete, die den
brauchen, entsprechend anzupassen.
Auf meinem Laptop sieht dann so aus:
% dpkg -l | grep systemd
[ keine Ausgabe ]
Interessanterweise lief elogind auch ohne Weiteres zu tun hier gleich
mit CGroup V2, während Systemd vor meinem Umstieg noch CGroup V1
verwendete. (Ich weiß, dass Systemd schon länger CGroup V2 kann.)
> Wenn ein Programm keine Unterstützung für nicht-systemd-Systeme mehr
> mitbringt, gibt es natürlich recht wenig, das ein Debian-Entwickler
> dann noch machen kann (außer natürlich die neue Version nicht
> paketieren).
Ich habe zudem seit Monaten zwei Server-VMs mit Devuan am Laufen und die
ganzen Dienste laufen *alle* noch unter Sysvinit, darunter unter
anderem:
- Postfix
- Dovecot
- rspamd
- Apache 2
- php-fpm
- Quasselcore
- unbound (leider nicht knot-resolver, da ist nur eine Systemd-Service-
Datei drin)
Das ist grundsätzlich auch bei Debian so möglich, da bin ich fast
vollkommen sicher.
Bei allem Respekt Sven, gerade in Bezug auf deine üblicherweise gut
fundierten Beiträge… bitte informiere dich hier erst mal, bevor du Dinge
vom Stapel lässt, die so sachlich einfach nicht zutreffen.
Selbst mein Musik-Laptop läuft mittlerweile ohne Systemd.
Und… es läuft einfach, ohne merkwürdige Effekte, ohne einen extrem frühen
Bedarf an Zufallszahlen für die UUID-Erstellung, für das Erstellen von
SSH-Keys, falls nicht vorhanden, dann natürlich schon, ohne einen Haufen
der CVEs von Systemd, darunter aus meiner Sicht schon einige arge
Knaller, ohne merkwürdiges Verhalten, falls ein Dateisystem nicht mal
nicht mounten lässt, ohne dass ich "nofail" in der /etc/fstab stehen hab
und… ohne eine ganze Reihe an weiteren Merkwürdigen, die mir in der Zeit
mit Systemd aufgefallen sind. Also eben ohne die ganze Policy – so ist
das richtig, und nur so und zwar für alle –, die in Systemd hart rein
kodiert ist. Außerdem bootet es gefühlt genauso schnell und fährt das
Laptop gefühlt auch genauso schnell runter.
Komfortverlust dadurch? Nahezu nicht vorhanden. Nur Pulseaudio starte
ich derzeit manuell bzw. mit Runit, da es Plasma ohne Präsenz von
Systemd nicht automatisch mit startete, was mich ehrlich gesagt etwas
verwunderte, da Plasma als Desktop-Umgebung grundsätzlich ohne feste
Abhängigkeiten zu Systemd oder sogar systemd-logind auskommt und
grundsätzlich sogar noch mit ConsoleKit 2 funktionieren würde. Unter
anderem, da es auch unter FreeBSD läuft.
Ja, ich hab bestimmte Befehle nicht, die an sich ganz nett sind… aber
ganz ehrlich: Bislang habe ich Systemd nicht so richtig vermisst. Und
dem Plasma oder dem Dovecot oder dem Apache ist das schnurz piep egal,
was für ein Prozess als PID 1 läuft.
Und ich hab das hier:
% ls -l /sbin/init
-rwxr-xr-x 1 root root 53176 Aug 24 16:46 /sbin/init
Schöne Übersichtliche ca. 50 KiB für PID 1.
Ganz ehrlich: Ich mag das.
Und wer Systemd mag, kann den auch haben. So stelle ich mir persönlich
ein universelles Betriebssystem vor und ich bin froh, dass ich das auch
mit Debian Unstable so ziemlich ohne Weiteres noch haben kann.
Und ich kann PID 1 auch nicht mit 3-10 SIGILL-Signalen hintereinander
ins Nirvana befördern, wie das zumindest bis vor ca. einem Monat mit
Debian 9 noch ohne Weiteres möglich war. Das haben Teilnehmer in einer
Linux-Schulung herausgefunden. Ich war da selbst ziemlich erstaunt,
konnte das aber ohne Weiteres mehrfach reproduzieren. Aufgrund meiner
Erfahrungen mit Fehlerberichten zu Systemd habe ich mir erspart, dazu
einen Bugreport einzureichen. Es ist mir ehrlich gesagt auch
mittlerweile egal. Aber fühle Dich frei das zu tun, sofern Du das
nachvollziehen kannst.
while true; do kill -ILL 1 ; sleep 1 ; done
sollte recht schnell zu einem Totalabsturz des Systems führen, während
Sysvinit das schnurz piep egal ist. Ich hab nicht getestet, inwiefern
das unter Debian 10 immer noch geht. Warum Systemd da abkachelt, habe
ich nicht untersucht und es interessiert mich auch nicht. Ich bin der
Meinung gerade PID 1 sollte Signale ignorieren, für die es sich nicht
interessiert.
Vielen Dank,
--
Martin
Reply to: