Wie verhalten sich die Skripte in /etc/init.d/ eigentlich zum systemd?
Sind diese Skripte Teil von systemd oder noch von dem alten init System, d.h. sind die eigentlich obsolet?
Gruß Malte
Hallo Malte, hallo Leute,
Am Sonntag, 16. Juni 2013 schrieb Malte Gell:
Wie verhalten sich die Skripte in /etc/init.d/ eigentlich zum systemd?
Sind diese Skripte Teil von systemd oder noch von dem alten init System, d.h. sind die eigentlich obsolet?
Jein ;-)
Die Scripte in /etc/init.d/ stammen aus Zeiten von sysvinit, allerdings kann systemd auch diese Scripte verwenden.
Obsolet sind sie nur, wenn ein Dienst auch ein $dienst.service mitbringt - ansonsten benutzt systemd das "alte" Initscript.
Gruß
Christian Boltz
Am 16.06.2013 18:15, schrieb Christian Boltz:
Hallo Malte, hallo Leute,
Am Sonntag, 16. Juni 2013 schrieb Malte Gell:
Wie verhalten sich die Skripte in /etc/init.d/ eigentlich zum systemd?
Sind diese Skripte Teil von systemd oder noch von dem alten init System, d.h. sind die eigentlich obsolet?
Jein ;-)
Die Scripte in /etc/init.d/ stammen aus Zeiten von sysvinit, allerdings kann systemd auch diese Scripte verwenden.
Obsolet sind sie nur, wenn ein Dienst auch ein $dienst.service mitbringt - ansonsten benutzt systemd das "alte" Initscript.
Verstehe. Ich nehme an, mit der Zeit werden die Skripte wohl auf systemd umgestellt? Wie sehe ich denn, welche systemd Skripte zu welchem Runlevel gehören? Bei SysV habe ich eine Ordnerstruktur in /etc/init.d/ wo man sauber sieht, in welchem Runlevel welches Skript in welcher Reihenfolge gestartet wird. Bei systemd sehe ich nur einen "wilden Haufen" in /usr/lib/systemd, wo sehe ich denn, welches systemd Skript zu welchem Runlevel gehört?
Gruß Malte
Am 16.06.2013 21:35, schrieb Malte Gell:
Wie sehe ich denn, welche systemd Skripte zu welchem Runlevel gehören?
Es gibt in systemd keine Runlevel. Es gibt nur Targets und deren Abhängigkeiten. So entspricht Graphical.target in etwa dem alten Runlevel 5.
Philipp
On Sun, 16 Jun 2013 21:35:25 +0200 Malte Gell malte.gell@gmx.de wrote:
Am 16.06.2013 18:15, schrieb Christian Boltz:
Hallo Malte, hallo Leute,
Am Sonntag, 16. Juni 2013 schrieb Malte Gell:
Wie verhalten sich die Skripte in /etc/init.d/ eigentlich zum systemd?
Sind diese Skripte Teil von systemd oder noch von dem alten init System, d.h. sind die eigentlich obsolet?
Jein ;-)
Die Scripte in /etc/init.d/ stammen aus Zeiten von sysvinit, allerdings kann systemd auch diese Scripte verwenden.
Obsolet sind sie nur, wenn ein Dienst auch ein $dienst.service mitbringt - ansonsten benutzt systemd das "alte" Initscript.
Verstehe. Ich nehme an, mit der Zeit werden die Skripte wohl auf systemd umgestellt? Wie sehe ich denn, welche systemd Skripte zu welchem Runlevel gehören? Bei SysV habe ich eine Ordnerstruktur in /etc/init.d/ wo man sauber sieht, in welchem Runlevel welches Skript in welcher Reihenfolge gestartet wird. Bei systemd sehe ich nur einen "wilden Haufen" in /usr/lib/systemd, wo sehe ich denn, welches systemd Skript zu welchem Runlevel gehört?
Gruß Malte
Wie Du es schon sagst:
SysV : aufgeraeumt, klar und einfach strukturiert, alles funktioniert und kann einfach nachvollzogen werden
systemd: undurchsichtiges Strickwerk von Links, keine vernuenftige sequentielle Abfolge und Ausgabe in Logfiles, Abkoppelung des Users vom Geschehen auf seinem System.
Es gibt keinen einzigen plausiblen Grund fuer systemd im Vergleich zu SysV.
sytemd ist nur eines: der perfekte Angriffspunkt fuer einen Trojaner.
Am 17.06.2013 22:45, schrieb Stephan von Krawczynski:
Wie Du es schon sagst:
SysV : aufgeraeumt, klar und einfach strukturiert, alles funktioniert und kann einfach nachvollzogen werden
systemd: undurchsichtiges Strickwerk von Links, keine vernuenftige sequentielle Abfolge und Ausgabe in Logfiles, Abkoppelung des Users vom Geschehen auf seinem System.
Es gibt keinen einzigen plausiblen Grund fuer systemd im Vergleich zu SysV.
sytemd ist nur eines: der perfekte Angriffspunkt fuer einen Trojaner.
Irgendeinen Grund müssen die Distributionen doch haben, alle auf systemd zu setzen?
Gruß Malte
Am 18.06.2013 04:43, schrieb Malte Gell:
Am 17.06.2013 22:45, schrieb Stephan von Krawczynski:
Wie Du es schon sagst:
SysV : aufgeraeumt, klar und einfach strukturiert, alles funktioniert und kann einfach nachvollzogen werden
systemd: undurchsichtiges Strickwerk von Links, keine vernuenftige sequentielle Abfolge und Ausgabe in Logfiles, Abkoppelung des Users vom Geschehen auf seinem System.
Es gibt keinen einzigen plausiblen Grund fuer systemd im Vergleich zu SysV.
sytemd ist nur eines: der perfekte Angriffspunkt fuer einen Trojaner.
Irgendeinen Grund müssen die Distributionen doch haben, alle auf systemd zu setzen?
Gruß Malte
Hi,
daran sind IMHO vor allem die Idioten schuld, die die Leistung eines Computers anhand der Bootzeit einschätzen...
cu jth
Am Dienstag, den 18.06.2013, 04:43 +0200 schrieb Malte Gell:
Irgendeinen Grund müssen die Distributionen doch haben, alle auf systemd zu setzen?
Angeblich soll es schneller sein. Das mit den Abhängigkeiten wurde ja bereits erwähnt.
Aber zumindest den ersten Punkt kann ich persönlich nicht wirklich nachvollziehen. Mein Arbeitsrechner ist mit SysV-Init gefühlt schneller oben, als mit systemd. Obwohl es ja eigentlich genau andersherum sein sollte.
Am 17. Juni 2013 22:45 schrieb Stephan von Krawczynski skraw@ithnet.com:
Es gibt keinen einzigen plausiblen Grund fuer systemd im Vergleich zu SysV.
Wie regelt SysV denn Abhängigkeiten?
Am 18.06.2013 10:23, schrieb Martin Schröder:
Am 17. Juni 2013 22:45 schrieb Stephan von Krawczynski skraw@ithnet.com:
Es gibt keinen einzigen plausiblen Grund fuer systemd im Vergleich zu SysV.
Wie regelt SysV denn Abhängigkeiten?
Also wenn ich mir z.B. /etc/init.d/xdm anschaue, dann gibt es da so Felder wie Required-Start: $remote_fs dbus das regelt die Abhängigkeiten der Skripte. Oder meintest du was anderes?
Gruß Malte
Am 18. Juni 2013 10:26 schrieb Malte Gell malte.gell@gmx.de:
Am 18.06.2013 10:23, schrieb Martin Schröder:
Am 17. Juni 2013 22:45 schrieb Stephan von Krawczynski skraw@ithnet.com:
Es gibt keinen einzigen plausiblen Grund fuer systemd im Vergleich zu SysV.
Wie regelt SysV denn Abhängigkeiten?
Also wenn ich mir z.B. /etc/init.d/xdm anschaue, dann gibt es da so Felder wie Required-Start: $remote_fs dbus das regelt die Abhängigkeiten der Skripte. Oder meintest du was anderes?
Nein. Und wenn Du /etc/init.d/xdm restart machst, wird davon irgendwas ausgewertet? Oder wird bei /etc/init.d/dbus stop irgendwie /etc/init.d/xdm stop gemacht?
Gruß Martin
Martin Schröder [18.06.2013 10:29]:
Am 18. Juni 2013 10:26 schrieb Malte Gell malte.gell@gmx.de:
Am 18.06.2013 10:23, schrieb Martin Schröder:
Am 17. Juni 2013 22:45 schrieb Stephan von Krawczynski skraw@ithnet.com:
Es gibt keinen einzigen plausiblen Grund fuer systemd im Vergleich zu SysV.
Wie regelt SysV denn Abhängigkeiten?
Also wenn ich mir z.B. /etc/init.d/xdm anschaue, dann gibt es da so Felder wie Required-Start: $remote_fs dbus das regelt die Abhängigkeiten der Skripte. Oder meintest du was anderes?
Nein. Und wenn Du /etc/init.d/xdm restart machst, wird davon irgendwas ausgewertet?
Im Falle von icinga, das ido2db voraussetzt, wird ido2db vorher gestartet - oder icinga wird nicht gestartet, wenn ido2db nicht läuft. Eine Gesetzmäßigkeit habe ich dabei noch nicht entdeckt, aber das mag an den Scherereien liegen, die ich derzeit mit ido2db auf der Maschine habe.
Oder wird bei /etc/init.d/dbus stop irgendwie /etc/init.d/xdm stop gemacht?
Warum sollte ein Programm unter Linux verhindern, dass ich mir den Ast absäge, auf dem ich sitze?
Die Abhängigkeiten sind hauptsächlich dazu dar, dass "insserv $SOFT" oder "chkconfig $SOFT on" die Abhängigkeiten richtig erkennen und die Nummerierung entsprechend setzen.
Gruß Werner
Am 18. Juni 2013 10:47 schrieb Werner Flamme werner.flamme@ufz.de:
Martin Schröder [18.06.2013 10:29]:
Oder wird bei /etc/init.d/dbus stop irgendwie /etc/init.d/xdm stop gemacht?
Warum sollte ein Programm unter Linux verhindern, dass ich mir den Ast absäge, auf dem ich sitze?
Weil man das möchte: Service A ist umgefallen. Welche anderen Services hängen davon ab und müssen neu gestartet werden?
Gruß Martin
Martin Schröder [18.06.2013 10:58]:
Am 18. Juni 2013 10:47 schrieb Werner Flamme werner.flamme@ufz.de:
Martin Schröder [18.06.2013 10:29]:
Oder wird bei /etc/init.d/dbus stop irgendwie /etc/init.d/xdm stop gemacht?
Warum sollte ein Programm unter Linux verhindern, dass ich mir den Ast absäge, auf dem ich sitze?
Weil man das möchte: Service A ist umgefallen. Welche anderen Services hängen davon ab und müssen neu gestartet werden?
Ähm, wieso müssen andere Services neu gestartet werden? Dass ich Service A ggf. neu starte, sehe ich ja ein. Die anderen müssen doch erstmal selbst herunterfallen, ehe ich sie neu starten muss. Sonst setzen doch Selbstheilungskräfte ein :-) - Dienst B arbeitet halt ohne A weiter, so gut er kann, und wenn A wieder da ist, freut sich B und schießt die Daten nachträglich rüber. Oder verbucht die Daten der Zwischenzeit als verloren, je nachdem.
Gruß Werner
-
Christian Boltz -
Joerg Thuemmler -
Malte Gell -
Malte Gell -
Martin Schröder -
Philipp Thomas -
Richard Kraut -
Stephan von Krawczynski -
Werner Flamme