[erledigt] systemd-Frage

[GregorS]

Hallo zusammen!

In einem anderen Thread bin ich mal wieder über ein Besonderheit von Debian gestolpert: Seit Bookworm gibt es wohl in einer minimalen Installation keine /var/log/syslog mehr. Überhaupt scheint es kein Syslog mehr zu geben, das „human readable“ (text-only) ist.

Und weil ich auch im Wikipedia-Artikel zu systemd nur „cons“ ohne „pros“ fand, frage ich hier mal nach dem, was im Wikipedia-Artikel fehlt:

Was ist an systemd so außerordentlich gut bzw. besser, dass es bei Debian als einziges Init-System existiert? Warum stellt Debian es nicht als zusätzliches Init-System zur Auswahl (wo Wahlfreiheit doch als so hohes Gut gilt)?

Ich bitte ausdrücklich darum, hier keinen Flamewar zu veranstalten.

Danke vorweg!

Gregor

[The Hit-Man]

Es gibt doch 'Devuan', ein Debian ohne systemd.
https://www.devuan.org/

[tobo]

Überhaupt scheint es kein Syslog mehr zu geben, das „human readable“ (text-only) ist.

Wie ich dir dort schon geschrieben habe, kann man das nachinstallieren.

Was ist an systemd so außerordentlich gut bzw. besser, dass es bei Debian als einziges Init-System existiert?

Tut es nicht - Systemd ist nur der Default.

Warum stellt Debian es nicht als zusätzliches Init-System zur Auswahl (wo Wahlfreiheit doch als so hohes Gut gilt)?

Genau, und deswegen gibt es weiterhin z.B. SysVinit. Du musst also (bei Bedarf) nicht zu Devuan wechseln...

[The Hit-Man]

Genau, und deswegen gibt es weiterhin z.B. SysVinit. Du musst also nicht zu Devuan wechseln...

Echt? Das wußte ich gar nicht. Man kann also unter einem normalen Debian auch SysVinit nachinstallieren und systemd komplett raus schmeißen?

[tobo]

Na klar und war auch schon immer so. Meine Debiane waren und sind schon immer Systemd-frei...

EDIT:
https://wiki.debian.org/Init

[GregorS]

Was ist an systemd so außerordentlich gut bzw. besser, dass es bei Debian als einziges Init-System existiert?

Tut es nicht.

Doch, wenn man eine 08/15-Installation durchführt, hat man ein Systemd-System vor sich. Ich kann nirgendwo im Installationsprozess wählen, ob ich ein Init-System nach SysV-Art haben will.

Warum stellt Debian es nicht als zusätzliches Init-System zur Auswahl (wo Wahlfreiheit doch als so hohes Gut gilt)?

Genau, und deswegen gibt es weiterhin z.B. SysVinit. Du musst also nicht zu Devuan wechseln...

Zu spät. Bei mir läuft inzwischen alles mit Devuan. Deren Installer fragt einen.

EDIT:
Grund für den Umstieg war, dass mein Mac Mini unter Debian ärgerliche Unzuverlässigkeit zeigte. Der IR-Empfänger funktionierte ab und zu nicht. Da mich das auf Dauer genervt hat, bin ich zunächst nur mit diesem Rechner zu Devuan umgestiegen. Da sich das nicht-deterministische Verhalten danach nicht mehr gezeigt hat, bin ich nach und nach auch mit den anderen Rechnern umgestiegen.

[tobo]

Was ist an systemd so außerordentlich gut bzw. besser, dass es bei Debian als einziges Init-System existiert?

Tut es nicht.

Doch, wenn man eine 08/15-Installation durchführt, hat man ein Systemd-System vor sich. Ich kann nirgendwo im Installationsprozess wählen, ob ich ein Init-System nach SysV-Art haben will.

Ich habe 1. nicht gesagt, dass man das während einer bestimmten Installation auswählen kann, sondern nur, dass eine Alternative existiert und 2. kann man das während der Installtion eben doch einstellen, in dem man vor dem Neustart auf die Konsole wechselt und ensprechend installiert. Nach dem ersten Neustart ist dann `ps -p1' init.

Warum stellt Debian es nicht als zusätzliches Init-System zur Auswahl (wo Wahlfreiheit doch als so hohes Gut gilt)?

Genau, und deswegen gibt es weiterhin z.B. SysVinit. Du musst also nicht zu Devuan wechseln...

Zu spät. Bei mir läuft inzwischen alles mit Devuan. Deren Installer fragt einen.

Ich habe ja auch nicht vorgeschlagen, dass du das tun sollst...

[GregorS]

Tut es nicht.

Doch, wenn man eine 08/15-Installation durchführt, hat man ein Systemd-System vor sich. Ich kann nirgendwo im Installationsprozess wählen, ob ich ein Init-System nach SysV-Art haben will.

Ich habe 1. nicht gesagt, dass man das während einer bestimmten Installation auswählen kann

Habe ich das etwa irgendwo behauptet?

... und 2. kann man das während der Installtion eben doch einstellen, in dem man vor dem Neustart auf die Konsole wechselt und ensprechend installiert. Nach dem ersten Neustart ist dann `ps -p1' init.

„Vor dem Neustart“ ist nach der Installation. Ich rede von der fehlenden Wahlmöglichkeit im Installer.

[niemand]

Ich rede von der fehlenden Wahlmöglichkeit im Installer.

Stell dir mal vor, wie fett der Installer wäre, wenn dort alle Wahlmöglichkeiten, die in bei einer Debianinstallation mit über fünfzigtausend Paketen im Repo existieren, vorhanden wären. Ein paar hundert Optionen wären das sicher …

[GregorS]

Ich rede von der fehlenden Wahlmöglichkeit im Installer.

Stell dir mal vor, wie fett der Installer wäre, wenn dort alle Wahlmöglichkeiten, die in bei einer Debianinstallation mit über fünfzigtausend Paketen im Repo existieren, vorhanden wären. Ein paar hundert Optionen wären das sicher …

Du meine Güte. Drücke ich mich denn wirklich so unverständlich aus?

Ich wüsste gerne, was denn verhindert (hat), dass Debian systemd als zusätzliches init-System zur Wahl (ge-) stellt (hat). Gibt es wichtige Dinge, die nur von systemd gehandhabt werden können – und die man nicht auch mit kleinen, einfachen Programmen hinbekommt?
Auf welche Dinge muss ich verzichten, wenn ich systemd nicht verwenden will?

An systemd störte mich, dass ich den Eindruck hatte, dass jemand versucht, Linux „Windows-ähnlicher“ zu machen. Mir geht's um die Unix-Philosophie der kleinen Tools, die einen eng begrenzten Funktionsumfang haben.

[tijuca]

Ich wüsste gerne, was denn verhindert (hat), dass Debian systemd als zusätzliches init-System zur Wahl (ge-) stellt (hat). Gibt es wichtige Dinge, die nur von systemd gehandhabt werden können – und die man nicht auch mit kleinen, einfachen Programmen hinbekommt?

Die Welt dreht sich weiter und SysV ist eben nicht mehr so flexibel wie man es in komplexeren Serverinstallationen benötigt. Um Deine Frage zu beantworten ...
https://www.debian.org/vote/2019/vote_002

Dort wurde entschiedenen, dass Systemd das zukünftige Standard Init System für Debian ist, und es den Paketmaintainern frei steht auch Support für SysV mit anzubieten. Dies aber stark empfohlen wird. Und wie hier im Thread geschrieben kannst Du schon wählen welches System Du benutzen willst. Du musst Dich aber schon mit dem System auseinandersetzen (so wie bei Windows auch! )

Ich kann auch nicht so ganz nachvollziehen was dieser für mich reine Glaubenskrieg mancher Personen die Systemd nicht mögen soll. Wer komplett ohne auskommen will oder muss kann bei SysV bleiben und kann Deuvan benutzen, oder eine andere Distri. Im privatem Homebereich macht das es eh keinen Unterschied.
Das Herr Poettering nun bei M$ beschäftigt ist hat eher umgekehrt mit Systemd zu tun. Als er Systemd "erfunden" hat war er noch bei Red Hat beschäftigt und M$ hat ihn gerade wegen seiner Erfahrungen durch das Systemd Projekt und den möglichen Synergieeffekten für Microsoft zu sich geholt. Da ist nichts mit Linux wird Windows ähnlicher gemacht!

[fischig]

Mir geht's um die Unix-Philosophie der kleinen Tools, die einen eng begrenzten Funktionsumfang haben.

Vorsicht! Du bist auf dem besten Weg, genau das anzustoßen:

Ich bitte ausdrücklich darum, hier keinen Flamewar zu veranstalten.

Ohne systemd verzichten musst du bei Debian, soweit mir bekannt, nur auf gnome, und auch das nur eingeschränkt, wenn ich tobos Link richtig gelesen habe. Aber ziemlich tricky ist es schon, bei Debian auf systemd verzichten zu wollen, denke ich.

[TRex]

Bitte wiederholt nicht einen der längsten Threads des Forums... viewtopic.php?t=151093

[niemand]

Ich wüsste gerne, was denn verhindert (hat), dass Debian systemd als zusätzliches init-System zur Wahl (ge-) stellt (hat). Gibt es wichtige Dinge, die nur von systemd gehandhabt werden können – und die man nicht auch mit kleinen, einfachen Programmen hinbekommt?

Es gibt tatsächlich nicht viele Dinge, die ohne das nicht irgendwie mehr oder weniger sauber zu handaben wären – aber systemd macht’s halt erheblich einfacher und weniger fehleranfällig für alle Beteiligten – und wenn ein Fehler auftritt, macht’s einfacher, den zu finden und zu beheben. Es war eine pragmatische Entscheidung: Vereinfachung für Viele vs. Berücksichtigung des Wunsches nach Minimalismus von Einigen.

Auf welche Dinge muss ich verzichten, wenn ich systemd nicht verwenden will?

Nix für ungut, aber die Welt dreht sich nicht um dich. Man würde auf alles verzichten, was systemd und daran angeschlossene Sachen halt bieten. Das ist ’ne Menge, aber wenn man’s hier aufwendig hinschreiben würde, wäre deine Antwort vermutlich eh: „Aber ich brauche doch die meisten Sachen gar nicht!“, wie du am Beispiel des Logs gezeigt hast:

Dank journald lassen sich Informationen mit zusätzlichen Daten loggen, und dadurch sehr viel gezielter daraus abfragen, extrahieren, anzeigen und weiterverarbeiten, ohne dass man irgendwelche Einschränkungen hinzunehmen hätte, wenn man die Möglichkeiten nicht nutzen würde – man kann’s sich schließlich weiterhin im Ganzen anzeigen lassen und mit seinen bekannten Werkzeugen drauf hantieren. Dennoch beschwerst du dich wieder und wieder drüber; dein Argument ist, dass es ja nicht „human readable“ wäre, und man Werkzeuge bräuchte.

Aber warum ist das wichtig? Ein Werkzeug brauchst du sowieso, denn cat ist genauso ein Programm, wie journalctl. Wenn du in einer Situation bist, wo du mit journalctl nicht mehr an dein Log kommst, dann kommst du mit cat ebenfalls nicht mehr ran. Und wenn du meinst, man müsse schließlich ohne journalctl auf die Logs zugreifen können, dann frage ich: wozu, um Goethes Willen, beharrt man drauf, das passende Werkzeug nicht nutzen zu wollen?

Das ist, als wenn sich jemand drüber beschwert, dass man Torx-Schrauben nicht mit ’nem Schlitzschraubendreher bedienen könne, während der Torx-Schraubendreher in der Werkzeugtasche direkt daneben liegt.

Sorry, falls es ein wenig säuerlich rüberkommt.

[ralli]

Andere und fremde Meinungen zu akzeptieren zeugt von Respekt und Wertschätzung. Es ist eine Charakterhaltung, die auch Toleranz beinhaltet. Admins und Profis schätzen systemd. Für den Privatanwender können es auch alternative, klassische Init Systeme sein. Devuan ist ein funktionierendes Beispiel. Aufgefallen ist mir, das allle Anwendungen unter Devuan, das ja ansonsten ebenfalls auch debianbasiert ist, flüssiger laufen als wie das Original mit systemd. Entscheiden darf das jeder für sich selber. GregorS braucht es ja nur auszuprobieren und kann dann eine Entscheidung treffen.

Gruß ralli

[thunder11]

In einem anderen Thread bin ich mal wieder über ein Besonderheit von Debian gestolpert: Seit Bookworm gibt es wohl in einer minimalen Installation keine /var/log/syslog mehr. Überhaupt scheint es kein Syslog mehr zu geben, das „human readable“ (text-only) ist.

Die Formulierung ist wohl falsch.

Richtiger wäre:

In einem anderen Thread bin ich mal wieder über eine Besonderheit von Devuan gegenüber dem
bei fast allen großen Distros genutzten Init-System (systemd) gestoßen.
Da ich nicht wissen will, wie das Journal von Systemd geführt wird, und was es für vielfältige
Möglichkeiten bietet, will ich meinen Syslog und die X-anderen Journale bei Debian wieder haben,
weil das schon immer so war.

[GregorS]

Danke für Eure Antworten!

Letztlich ist es das Logging, das meine ablehnende Haltung stützt. Ich mag nicht, dass ich nicht auf „traditionelle“ Weise (cat, grep, tail ...) auf das zugreifen kann, was eine Kernkomponente des Systems an Infos zu geben hat.

Naja ... das Schöne an Meinungen ist, dass man sie ändern kann. Ich wollt' halt mal wieder wissen, ob es einen wirklich guten Grund für die Änderung meiner Meinung gibt.

Schönes Wochenende allerseits!

EDIT:
Das Vergleich mit den Torx-Dingern passt übrigens nicht. Torx bietet allen anderen Antrieben gegenüber einen entscheidenden Vorteil: Es ist vom Profil her zylindrisch, nicht kegelförmig. D.h. bei Torx-Schrauben muss man kaum noch Druck ausüben. Die Arbeit beschränkt sich bei einer Schraube mit Torx-Antrieb darauf, den Schrauber zu halten und zu gucken, dass er nicht aus der Schraube rutscht.

[Chameleon]

EDIT:
Torx bietet allen anderen Antrieben gegenüber einen entscheidenden Vorteil:

Naja, also das halte ich für ein Gerücht.

[GregorS]

EDIT:
Torx bietet allen anderen Antrieben gegenüber einen entscheidenden Vorteil:

Naja, also das halte ich für ein Gerücht.

Ups, ja, stimmt, den Titel „Heimwerker-King“ hab' ich mir nicht verdient. Aber Innensechskant ist bei Spanplattenschrauben nach wie vor sehr unüblich. Die mit Torx-Antrieb scheinen häufiger zu werden.

[Chameleon]

Die mit Torx-Antrieb scheinen häufiger zu werden.

Die Schraube der Profis ist die Assy von Würth.

[GregorS]

Die mit Torx-Antrieb scheinen häufiger zu werden.

Die Schraube der Profis ist die Assy von Würth.

Die gibt's hoffentlich auch mit allen Antrieben ... siehe https://de.wikipedia.org/wiki/Liste_der ... pfantriebe

[niemand]

Das Vergleich mit den Torx-Dingern passt übrigens nicht. Torx bietet allen anderen Antrieben gegenüber einen entscheidenden Vorteil: Es ist vom Profil her zylindrisch, nicht kegelförmig. D.h. bei Torx-Schrauben muss man kaum noch Druck ausüben.

Ich fand und finde den erstaunlich gut passend: So wie Torx Vorteile gegenüber Schlitz bietet (Zentrierung, Kraftübertragung, einfaches Ansetzen fast unabhängig von der Schraubenstellung, etc. [konisch ist Schlitz jedoch auch nicht]) und die Arbeit einfacher macht, gibt es beim Journal Vorteile gegenüber klassischen Plaintext-Logs (Durchsuchbarkeit und fein steuerbare Auswahl der anzuzeigenden Informationen, Zuordnung, Formatierung, Highlighting, …), was die Arbeit einfacher macht. Und so, wie man Torx-Schrauben notfalls durchaus auch recht gut mit einem Schlitzschraubendreher mit passend breiter Klinge gedreht bekommt, kann man das Journal mit den Plaintext-Werkzeugen anschauen.

Anders als bei Torx-Schrauben wird beim Journal aber das passende Werkzeug frei Haus mitgeliefert, sodass nicht einmal die Investition für das Werkzeug als Argument herhalten kann.

[GregorS]

Ich fand und finde den [Vergleich mit Torx] erstaunlich gut passend:

Du hast recht, er passt wirklich gut. Aber er hinkt halt an einer Stelle. Und das mit dem mitgelieferten Werkzeug ist auch ein ziemlich schwaches Argument. Meine ersten T-Bits hatte ich schon, als Torx noch absolut exotisch war (Anfang 80er) und cat/grep/rev/etc. dürften auf jeder Linux-Kiste des Universums zu finden sein. Ein Werkzeug mitzuliefern ist vollkommen unnötig, weil es längst standardmäßig vorhanden ist.

Apropos: Das einzige Torx-Werkzeug, das ich mir dann doch noch zulegen musste, war ein „Mac-Opener“ – das Besondere daran war der lange Schaft (IIRC ~20 cm). Der wartet jetzt in meiner Bastelmaterial-Schublade auf eine sinnvolle Endnutzung.

[niemand]

Aber er hinkt halt an einer Stelle. Und das mit dem mitgelieferten Werkzeug ist auch ein ziemlich schwaches Argument. Meine ersten T-Bits hatte ich schon, als Torx noch absolut exotisch war (Anfang 80er) und cat/grep/rev/etc. dürften auf jeder Linux-Kiste des Universums zu finden sein. Ein Werkzeug mitzuliefern ist vollkommen unnötig, weil es längst standardmäßig vorhanden ist.

Wenn du nicht gerade von einem Devuan-, Gentoo- oder ähnlichem System aus auf den Patienten zugreifst, sondern von etwa einem der üblichen Livesysteme aus, ist das Werkzeug für den Zugriff auf das Journal eben auch längst standardmäßig vorhanden – mitgeliefert, wie auch cat, grep, …

Das ist’s ja, worauf ich mit diesem Werkzeugvergleich hinweisen wollte: ich kann mir kein Szenario vorstellen, in dem jemand ein systemd-System reparieren müsste, aber dafür nur ein nicht-systemd-System ohne journalctl zur Verfügung hätte. Und selbst, wenn so ein Fall aus irgendeinem sehr seltsamen Grund eintreten würde, könnte man chrooten und das journalctl des Patienten nutzen.

Und wenn eine kosmische Anomalie einen dazu zwingt, es mit den Bordmitteln eines Systems aus einer Zeit vor systemd zu machen, kann man eben immer noch mit strings, grep und awk ein nahezu original nach (r)syslogd aussehendes Textfile aus dem Journal extrahieren.

[GregorS]

...Das ist’s ja, worauf ich mit diesem Werkzeugvergleich hinweisen wollte: ... chroot ...

Hm, ja, das mit chroot hatte ich überhaupt nicht auf dem Schirm. Ich hab's mal auf den „zu erledigen“-Stapel gelegt. Die Manpage dazu ist schon mal erfreulich kurz.