systemd

[_ash]

Gibt es eine ernsthafte, funktionierende Alternative zu systemd unter Debian? Wie sieht es zB mit OpenRC aus?

[Radfahrer]

Nein.

[smutbert]

Probiert habe ich es in letzter Zeit nicht, aber wieso sollten beispielsweise sysvinit-core oder openrc nicht funktionieren. init-Skripte bringen die meisten Pakete ja nach wie vor mit und dank systemd-shim sollte dann auch noch Software funktionieren, die eigentlich auf systemd als init-System angewiesen ist.

Allerdings stellt systemd wie man sieht nicht nur das init-System sondern auch weitere Pakete, die man nicht so einfach weglassen oder ersetzen kann. Sieh die vielleicht einmal devuan an.

[Colttt]

Ohne jetzt hier wieder was einreisen zu lassen, aber woran ist OpwnRC gescheitert

[smutbert]

keine Lobby

[guennid]

Ich kriege jessie noch ohne systemd und ohne systemd.shim ans Laufen. Ob sich das zukunftsfähig betreiben lassen wird? K.A. Devuan versucht's.

Grüße, Günther

[_ash]

Devuan klingt in der Tat interessant, systemd in der Art zu erzwingen halte ich nicht für nicht clever.

Anyway, wie könnte ich systemd durch OpenRC (oder upstart) ersetzen? OpenRC installieren, systemd.shim, neustarten und danach systemd löschen?

[TomL]

Gibt es eine ernsthafte, funktionierende Alternative zu systemd unter Debian?

Verräts du uns, was genau nicht funktioniert? Mich interessiert das, falls ich mal auf das gleiche Problem stoßen sollte und dann vielleicht auf deine Lösung zurückgreifen kann.

[Radfahrer]

... systemd in der Art zu erzwingen halte ich nicht für nicht clever.

Was genau stört dich denn an systemd? Schon mal damit befasst?

[guennid]

Für mich ist dieser Satz von ash mehrdeutig.

Grüße, Günther

[Radfahrer]

Stimmt.

[wanne]

Ohne jetzt hier wieder was einreisen zu lassen, aber woran ist OpwnRC gescheitert

OpenRC funktioniert unter Gentoo noch immer besser als Systemd auf jeder beliebigen anderen Distro. Nur Debian hat den Support halt defakto fallen gelassen.

[Radfahrer]

Noch mal die Frage:
Was funktioniert denn unter jeder beliebigen Distribution nicht an systemd?

[catdog2]

OpenRC funktioniert unter Gentoo noch immer besser als Systemd auf jeder beliebigen anderen Distro.

Mag sein, Gentoo hat auch offensichtlich andere Prioritäten. Zum einen scheint da die Systemd Hater Szene ja recht aktiv zu sein und zum anderen dürfte die Fallhöhe bei OpenRC zu systemd deutlich geringer sein als bei dem was Debian benutzt hat(te).

Nur Debian hat den Support halt defakto fallen gelassen.

Kann ich nicht beurteilen, ich glaube nicht, dass es je signifikanten Support abseits vom default init/rc gab und ich kann mir auch kaum vorstellen, dass das weniger geworden ist. Oder sind da Leute abgesprungen?

Was funktioniert denn unter jeder beliebigen Distribution nicht an systemd?

Das einzige wirkliche Problem welches mir bekannt ist sind einige Debian spezifische Erweiterungen zu cryptsetup, die systemd nicht unterstützt und wo eine Lösung nicht ganz trivial ist. Weiss aber nicht wie da der Stand ist.

[smutbert]

[…]
Anyway, wie könnte ich systemd durch OpenRC (oder upstart) ersetzen? OpenRC installieren, systemd.shim, neustarten und danach systemd löschen?

Im wesentlich kannst du einfach das andere init-System installieren, zB openrc und entweder es ersetzt das bereits installierte init-System eh und du merkst beim nächsten Neustart was alles noch funktioniert und was nicht oder du kannst es danach über den Kernelparameter »init=/…« statt systemd verwenden.

Es gibt bei Debian sogar einen kleinen Wikiartikel über openrc:
https://wiki.debian.org/OpenRC#Try_It_Out

[wanne]

Kann ich nicht beurteilen, ich glaube nicht, dass es je signifikanten Support abseits vom default init/rc gab

Um upstart zu supporten brauchst du halt support von default init/rc und das upstart Paket. Kaputt ging das als man den support für default init/rc fallen gelassen hat. Sowas nennt man Kompatibilität.

Was funktioniert denn unter jeder beliebigen Distribution nicht an systemd?

Hatten wir zu genüge.

• mount über die fstab
• logging geht regelmäßig kaputt (ist besser geworden)
• cryptsetup über die crypttab
• Und als dickester Punkt: Keine Stabilen APIs. Guck dir mal das an: https://www.google.de/?gfe_rd=cr&ei=AWK ... emd+breaks
• Die dbus abhängigkeit verhindert ein einfaches Sicherheitsmanagement.
• ...

Und ich will jetzt keine Alternativen hören. Das mag für Desktop Nutzer kein Problem sein das dann halt anders zu machen. Aber wenn du in ein System mal im 6Stelligen Bereich Mannstunden reingesteckt hast, dann willst du dir das nicht alle 2 Wochen durch irgend welche API changes riskieren, dass das erstmal unbenutzbar wird. Red Hat selber hat das im übrigen eingesehen. Da bekommst du auch noch für Boron support. Nur wenn du dich irgend wie außerhalb des RHEL-Universums bewegst hast du halt ein Problem.

[catdog2]

Um upstart zu supporten brauchst du halt support von default init/rc und das upstart Paket. Kaputt ging das als man den support für default init/rc fallen gelassen hat. Sowas nennt man Kompatibilität.

Upstart ist tot weil es von Canonical/Ubuntu aufgegeben wurde. Ich habe noch nichts davon gehört, dass Debian klassisches sysvinit aufgegeben hätte.

mount über die fstab

äh nein

logging geht regelmäßig kaputt (ist besser geworden)

äh nein

cryptsetup über die crypttab

Wie gesagt, nicht generell, nur gewisse Erweiterungen

Und als dickester Punkt: Keine Stabilen APIs. Guck dir mal das an: https://www.google.de/?gfe_rd=cr&ei=AWK ... emd+breaks

Du kannst Begriffe in Google werfen. Ich bin Stolz auf dich. Aber was soll uns das jetzt sagen?

Die dbus abhängigkeit verhindert ein einfaches Sicherheitsmanagement.

Was für ein Quatsch.

Aber wenn du in ein System mal im 6Stelligen Bereich Mannstunden reingesteckt hast, dann willst du dir das nicht alle 2 Wochen durch irgend welche API changes riskieren, dass das erstmal unbenutzbar wird.

Deswegen benutzt man da gerne Debian Stable oder eine lange Supportete Enterprise Distribution gegen Geld (was vmtl gegen die Mannstunden vernachlässigbar ist). Und egal ob man alle 2 Wochen oder alle 2 Jahre updatet wird man das sicher nicht ungetestet ins Produktivsystem einspielen.

Red Hat selber hat das im übrigen eingesehen. Da bekommst du auch noch für Boron support.

Scheint eher ganz normaler Support Zeitraum zu sein bei denen.

[_ash]

Was genau stört dich denn an systemd? Schon mal damit befasst?

Mich stören im Wesentlich 2 Dinge:

1) systemd verletzt die grundlegende Philosophie "do one thing and do that well". Für meinen Geschmack macht systemd zu viel.

2) Der Code ist zu komplex um genau sagen zu können, was dahinter passiert, und die Herkunft zu grau. Ich bin da eher auf der Verschwörerseite und sag's mal so: wenn ich ein Geheimdienst wäre und mir Zugang zu Linuxsystemen verschaffen wollte, dann würde ich es auf genau diese Weise machen.

[TomL]

1) systemd verletzt die grundlegende Philosophie "do one thing and do that well". Für meinen Geschmack macht systemd zu viel.

Die Transparenz, die ich jetzt habe, wann, welche Dienste/Jobs mit welchem Ergebnis gestartet wurden, hatte ich jedenfalls unter Wheezy nicht. Den Boot-Vorgang nachzuvollziehen war mir zu der Zeit jedenfalls nicht möglich. Jetzt mit systemd kann ichs.

2) Der Code ist zu komplex um genau sagen zu können, was dahinter passiert, und die Herkunft zu grau. Ich bin da eher auf der Verschwörerseite und sag's mal so: wenn ich ein Geheimdienst wäre und mir Zugang zu Linuxsystemen verschaffen wollte, dann würde ich es auf genau diese Weise machen.

Na ja... ich bin ja selber paranoid.... aber das ist mir jetzt zu abgedreht. Als Geheimdienst würde ich mich mit dem Kernel befassen, aber nicht mit nem Programm, was Services startet. Ich hake das dann mal für mich als Lösungsansatz, der nicht mal für imaginäre Probleme geeignet ist, ab..... Aber Alternativen wurden ja vorgeschlagen.... insofern müsstest Du da erfolgreich sein.

[Radfahrer]

@_ash

Ah ja, alles klar. Du hast dich also

1. nicht mit systemd befasst

und plapperst

2. nur Dinge nach, die du am "Systemd-ist-böse-Stammtisch" gehört hast.

Ich bin dann mal raus.

[_ash]

Ich versteh die ganze Polarisierung und hitzige Diskussion hier nicht; ich habe schlicht nach einer Alternative für einen Dienst gefragt. Kann doch jeder selbst entscheiden, warum er welchen Dienst verwenden will. Die Diksussion, ob systemd nun toll ist oder nicht, wurde doch an anderen Stellen schon ausreichend diskutiert.

[smutbert]

Ach die Diskussion ist doch nicht hitzig, jedenfalls nicht für systemd-Diskussionsverhältnisse

Dein zweiter Kritikpunkt geht ein bisschen ins Leere, wenn man sich ansieht welche Softwarekomponenten systemd abgelöst hat. consolekit habe ich zB nur als einziges Chaos und ewigen Quell von Problemen wahrgenommen und auch systemd-journal empfinde ich durchaus als Vereinfachung gegenüber syslog, syslog-ng, rsyslog,…

Zum ersten sage ich nichts, weil ich nichts weiß.


runit, https://wiki.debian.org/runit
wäre auch noch eine Alternative, die aber zweifelsohne mit etwas mehr Arbeit verbunden ist.

[pferdefreund]

Also - ich habe meinen Rechner zu Hause auf Jessie upgedatet und beherzt upt-get install sysvinit sysvinit-core gemacht und alles läuft wie bisher. Gut, da wird wohl nach der Anmeldung auch noch was von systemd gestartet - habe es nicht näher analysiert - aber alles funktioniert so wie es soll. Ich war bisher einfach zu beschäftigt, um mich mit systemd zu befassen und habe viele eigene init-scripte, die halt einfach laufen müssen. Kommt Zeit, kommt Systemd - aber nicht heute oder morgen. Ich verwende allerdings keine besonderen Sachen wie LVM, RAID und was es so noch gibt und auch keinen Gnome oder KDE. Mein liebgewonnener ICEWM seit 1999 tut es für mich perfekt.