Debians Init-System der Zukunft

[Saxman]

Kann eigentlich mal jemand verkünden wie die Sache jetzt genau aussieht bzw. weitergeht? Was eben durch die Medien ging, ist dass SystemD Standard wird. Punkt.

Nachdem sich das TC für Systemd entschieden hat und mittlerweile selbst Canonical Systemd favorisiert, schaut die Lage für Upstart selbst bei einer GR schlecht aus. OpenRC hatte letztlich auch nur eine Außenseitenrolle. Spricht also alles dafür, dass es bei Systemd bleibt.

Das impliziert aber so viele Folgefragen, z.b. fliegen kFreeBSD und Hurd raus oder machen deren Leute mit SysVInit weiter, was bedeuten würde das doch zwei Initsysteme gepflegt werden bei denen man auch unter Linux wählen könnte, kommt kdbus als nächster "Segen", etc.

Da ist schon die nächste Diskussion im Gange, über das zukünftige Init-System für Nicht-Linux Platformen.

[nudgegoonies]

Da ist schon die nächste Diskussion im Gange, über das zukünftige Init-System für Nicht-Linux Platformen.

Mit etwas Glück bedeutet dass vielleicht, das man auch unter Linux dieses "zukünftige" Init-System statt SystemD wählen kann. Zumindest die Leute, die kein Gnome verwenden.

[catdog2]

Da Problem mit den non Linux Ports hat man sowiso sowohl bei systemd als auch bei upstart. Bei upstart stünde Upstream zwar einer Portierung nicht im Weg aber machen muss das auch erst mal wer. Nur bei openrc wäre es wohl weniger problematisch weil gentoo auch non Linux Ports betreibt.

Da ist schon die nächste Diskussion im Gange, über das zukünftige Init-System für Nicht-Linux Platformen.

Die Diskussion ist auch sicher nötig und es wäre seltsam, wenn sie nicht geführt würde.

Mit etwas Glück bedeutet dass vielleicht, das man auch unter Linux dieses "zukünftige" Init-System statt SystemD wählen kann. Zumindest die Leute, die kein Gnome verwenden.

Eventuell Glück für die systemd hater.

[nudgegoonies]

So langsam wird ein Betriebssystem draus http://www.heise.de/open/meldung/Init-P ... 19141.html

[Milbret]

So langsam wird ein Betriebssystem draus http://www.heise.de/open/meldung/Init-P ... 19141.html

Traurig aber wahr.
Ich mag Systemd nicht besonders, da es schon mehr als nur ein init System ist.
Es überfüllt sich selbst, was mich sehr stört.

Ein Init System soll sich nur um den Bootvorgang kümmern. Punkt.
Alles andere sind nette Features die aber nicht in ein Init System gehören.

Martin

[cosmac]

Da ist schon die nächste Diskussion im Gange, über das zukünftige Init-System für Nicht-Linux Platformen.

Mit etwas Glück bedeutet dass vielleicht, das man auch unter Linux dieses "zukünftige" Init-System statt SystemD wählen kann. Zumindest die Leute, die kein Gnome verwenden.

Die Diskussion ist lesenswert -- keine Schimpfworte und Beleidigungen, man kann jetzt wieder vernünftig über technische Details reden. Ich hab' den Eindruck, die Chancen stehen nicht schlecht für mehr als ein Init-System.
Ein interessanter Link war auch dabei:
http://blogs.gnome.org/mclasen/2014/02/ ... rtability/
demnach war "gnome setzt systemd voraus" ein Gerücht aus dem Wahlkampf...

Ein Init System soll sich nur um den Bootvorgang kümmern. Punkt.

deshalb heißt das Teil ja auch "systemd" und nicht "initd"

[Milbret]

@cosmac
Soweit mir aber bekannt war sollte systemd "nur" ein init Ersatz werden.
Und init hat eben keine weiteren Aufgaben als sich um den Bootvorgang zu kümmern.

Entsprechend habe ich auch eine Ablehende Haltung zu systemd, da es sich zu einem Monster verwandelt, dass sich nicht an gewisse Vorgehensweisen aus der Unix Welt hält.
So ignoriert man dort das KISS Prinzip völlig.
Ebenfalls braucht man ein extra Tool um die systemd Log, die in einem nicht Lesbaren Format gespeichert werden, auslesen zu können.
Hier verlang systemd also, dass man komplette Aufgaben an ein Tool auslagern soll.

Dies ist für mich ein Versuch gewisse Paradigmen zu unterlaufen und dann auch noch eine riesige Abhängigkeit zu schaffen.
Sowas wiederspricht aber dem aktuellen Status Quo.

Nimm es mir nicht übel aber ich kann system nicht leiden, da es die Paradigmen die Unix und eben später auch Linux soweit gebracht haben komplett über Bord wirft.
Und durch die Abhängiokeiten bei den Distributionen festigt hier Red Hat ebenfalls noch Abhängikeiten für die eigenen Geschäfte.
Ich halte deshalb systemd auch als einen Versuch hier ein gewisses Monopol mit Einflussmöglichkeiten zu schaffen.

Klingt zwar nach Verschwörung, könnte sich aber in Zukunft auch als Wahr erweisen )

Martin

[nudgegoonies]

Ein Init System soll sich nur um den Bootvorgang kümmern. Punkt.

deshalb heißt das Teil ja auch "systemd" und nicht "initd"

Der Name ist wirklich unpassend, sie sollten es operatingsystemd nennen

Die Sache bezüglich KISS Prinzip müsste man sich genauer ansehen. Grob draufgeschaut: Aus dem Quellpaket werden 20 Binärpakete gebaut und das wichtigste davon, das systemd Paket, enthält alleine schon 21 ausführbare Dateien. So ganz un-modular scheint es zumindest mir auf den ersten Blick gar nicht zu sein. Ein großer Blob ist es zumindest nicht.

Ich bin mal neugierig, ob sich das wirklich durchsetzen wird. Man denke nur mal an ifconfig und netstat. Solange die noch paketiert werden sehe ich keinen Grund mich auf ip und ss umzugewöhnen. Ich habe keine Vorteile gefunden bzw. nichts vermisst und habe nur den Nachteil, mich umgewöhnen zu müssen. Also mache ich es halt nicht. Und solange systemd init.d scripte unterstützt werde ich mir das systemd Format wahrscheinlich auch nicht mal ansehen. Etwas das man gelernt hat und das funktioniert ist selbst bei den Informatikern, wo es ständig Neuerungen gibt, der größte Hemmschuh sich auf was neues einzulassen. Und sicher auch die Erfahrung, dass viele radikale Neuanfänge so sehr in die Hose gegangen sind.

[cosmac]

@cosmac
Soweit mir aber bekannt war sollte systemd "nur" ein init Ersatz werden.
Und init hat eben keine weiteren Aufgaben als sich um den Bootvorgang zu kümmern.

wobei es sogar nur um den rc-Mechanismus ging, es war absolut überflüssig, an /sbin/init (pid 1) etwas zu ändern.

Ebenfalls braucht man ein extra Tool um die systemd Log, die in einem nicht Lesbaren Format gespeichert werden, auslesen zu können.
Hier verlang systemd also, dass man komplette Aufgaben an ein Tool auslagern soll.

das ist ein Beispiel, wo systemd eine Schwäche des alten Systems ausnutzt um den Usern seinen Müll schmackhaft zu machen. Es war ja ziemlich schwierig, die Meldungen der init-Scripte zu speichern. Dafür, dass das jetzt richtig funktioniert, nimmt man gerne in Kauf, dass man sie nicht mehr lesen kann

Nimm es mir nicht übel aber ich kann system nicht leiden

dann sind wir ja schon zu zweit. Also, wenn ich das Umfrageergebnis hier im Forum anschaue... Wenn eine Firma so entscheidet, meinetwegen, aber hier stimmen doch Leute ab, die dann selber den Stress mit dem Teil haben werden. Ich werde es nie verstehen

Und durch die Abhängiokeiten bei den Distributionen festigt hier Red Hat ebenfalls noch Abhängikeiten für die eigenen Geschäfte.

das würde ich ihnen sogar gönnen, es gibt "bösere" Firmen. Und wenn es zu schlimm kommt, wird es eine Alternative geben (hoffe ich jedenfalls).

Klingt zwar nach Verschwörung, könnte sich aber in Zukunft auch als Wahr erweisen )

eine Verschwörung ist es definitiv

Verschwörung
Eine Verschwörung (Lehnübersetzung von lat. coniuratio; auch: Konspiration) ist ein heimliches Bündnis mehrerer Personen mit dem Zweck, einen Plan auszuführen; dieser kann ein selbstsüchtiges, verwerfliches Ziel haben und den Schaden anderer beinhalten, aber auch die Beseitigung tatsächlicher oder vermeintlicher Missstände umfassen. Eine Verschwörung beruht also nicht notwendigerweise auf moralisch niederen Motiven, sie basiert jedoch stets auf Täuschung.

Die Sache bezüglich KISS Prinzip müsste man sich genauer ansehen. Grob draufgeschaut: Aus dem Quellpaket werden 20 Binärpakete gebaut und das wichtigste davon, das systemd Paket, enthält alleine schon 21 ausführbare Dateien. So ganz un-modular scheint es zumindest mir auf den ersten Blick gar nicht zu sein. Ein großer Blob ist es zumindest nicht.

Was helfen mir 21 einzelne Programme, wenn die alle aufeinander angewiesen sind und über nicht dokumentierte Kanäle kommunizieren? Außerdem ist schon das Grundprinzip das Gegenteil von kiss: es gibt keine einheitliche Schnittstelle zu anderen Paketen, stattdessen werden einzelne (nicht alle!) Funktionen in systemd übernommen.

Ein Beispiel das mir Arbeit machen würde: hwclock funktioniert hier wegen spezieller Hardware ganz anders. Bisher konnte ich das init-Script anpassen (oder abschalten), jetzt muss ich überhaupt erstmal auf die Idee kommen, dass der systemd heimlich die Uhr manipuliert -- das sind Fehlerquellen, die die Welt wirklich nicht braucht. Nachdem ich das zufällig entdeckt hab', bin ich natürlich sehr skeptisch, was den Rest angeht.

Ich bin mal neugierig, ob sich das wirklich durchsetzen wird. Man denke nur mal an ifconfig und netstat. Solange die noch paketiert werden sehe ich keinen Grund mich auf ip und ss umzugewöhnen. Ich habe keine Vorteile gefunden bzw. nichts vermisst

Jetzt wo du es sagst: welche Vorteile habe ich als Benutzer eigentlich von systemd? Selbst das alte Werbeargument "bootet schneller" ist ja wohl vom Tisch und war angeblich nie das Ziel der Entwicklung.

[wanne]

Ein Beispiel das mir Arbeit machen würde: hwclock funktioniert hier wegen spezieller Hardware ganz anders. Bisher konnte ich das init-Script anpassen (oder abschalten), jetzt muss ich überhaupt erstmal auf die Idee kommen, dass der systemd heimlich die Uhr manipuliert -- das sind Fehlerquellen, die die Welt wirklich nicht braucht. Nachdem ich das zufällig entdeckt hab', bin ich natürlich sehr skeptisch, was den Rest angeht.

Genau das ist das was ich meine: Alles funktioniert bei 99% hervorragend aber hier und da findet sich dann doch eine Kleinigkeit und die ist dann praktisch nicht zu beheben.

Aus dem Quellpaket werden 20 Binärpakete gebaut und das wichtigste davon, das systemd Paket, enthält alleine schon 21 ausführbare Dateien.

In C Kann man jede Funktion als eigene Binary bauen. Ob das deswegen modularer ist oder nicht sei mal dahingestellt. Der Vorteil von modularität ist eigentlich dass man teile durch andere (nicht systemd) austauschen/weglassen kann. Das geht bei systemd nur schwer.

Man denke nur mal an ifconfig und netstat. Solange die noch paketiert werden sehe ich keinen Grund mich auf ip und ss umzugewöhnen.

Es gibt schon massenhafs sachen die mit ifconfig/route extreme verbiegungen gebraucht haben. Und die die Leute deswegen für kompliziert gehalten und großteils gemieden haben.
Nur so ein paar: Mehrere IPs pro interface sind einfach ne tolle sache. Gerade, wenn man mal 5 Server betreiben will. Eigentlich will man da nicht auf andere Ports ausweichn. Aber weil das mit ifconfig gefriekel war hat man das halt doch gemach. Oder wenn man mal 2 Netze hat.
Load balancing über mehrere Interfaces oder CPUs. Wurde mir immer als zu kompliziert von abgeraten mit ip ein einzeiler. Selbiges gilt für routing anhand von TOS u.ä.
Für diverse tunnel Mechanismen (OpenVPN o.ä.) wäre es ein segen, wenn sie von den Fähigkeiten von IP gebrauch machen würden statt nochmal alles neu zu erfinden.
Und multicastrouting habe ich zwar noch nicht benutzt aber das war glaube ich mit route auch nicht möglich. Warum das allerdings nicht in die alten tools eingepflegt wurde und man sich weg von der BSD syntax hin zu der von CISCO IOS bewegt hat verstehe ich auch nicht so richtig. Passt aber stark zur entwickluch von Linux weg aus dem GNU/POSIX bereich.

[nudgegoonies]

Entschuldige bitte die späte Antwort. Mit der Modularität hast Du natürlich recht, dass die verschiedenen Binaries noch nichts über dessen Modularität aussagen.

Warum das allerdings nicht in die alten tools eingepflegt wurde und man sich weg von der BSD syntax hin zu der von CISCO IOS bewegt hat verstehe ich auch nicht so richtig. Passt aber stark zur entwickluch von Linux weg aus dem GNU/POSIX bereich.

Mir ist gerade aufgefallen, dass das iproute Paket für die kFreeBSD Debians nicht verfügbar ist. Vielleicht hat iproute zu viele Abhängigkeiten zum Linux-Kernel - so wie systemd. Und dass darum die meisten Paketbetreuer lieber ifconfig verwenden damit sie nichg so viel anpassen müssen. Aber sogar ifconfig wird anscheinend durch verschiedene Pakete bereitgestellt. Bei Linux durch net-tools und bei kFreeBSD durch bsd-utils.

[catdog2]

Mir ist gerade aufgefallen, dass das iproute Paket für die kFreeBSD Debians nicht verfügbar ist.

Klar das greift quasi nur auf Linux spezifische Kernel APIs zu, würde keinen Sinn ergeben und evtl gar nicht bauen. Fängt schon damit an, dass es per netlink [1] mit dem Kernel redet und das gibts so nur unter Linux.

Aber sogar ifconfig wird anscheinend durch verschiedene Pakete bereitgestellt. Bei Linux durch net-tools und bei kFreeBSD durch bsd-utils.

Hier wirds ähnlich sein. Die beiden ifconfigs sind ja auch nur auf einem sehr niedrigem Level kompatibel wenn man sich mal die manpage [2] anschaut. Eine IP mit netzmaske zuweisen geht wohl noch gleich aber dann wars das auch so ziemlich.

Warum das allerdings nicht in die alten tools eingepflegt wurde und man sich weg von der BSD syntax hin zu der von CISCO IOS bewegt hat verstehe ich auch nicht so richtig. Passt aber stark zur entwickluch von Linux weg aus dem GNU/POSIX bereich.

Was ist an dieser Syntax denn gut außer, dass sie historisch gewachsen und über die verschiedenen tools maximal inkonsistent ist?


[1] http://en.wikipedia.org/wiki/Netlink
[2] http://www.freebsd.org/cgi/man.cgi?ifconfig%288%29

[wanne]

Was ist an dieser Syntax denn gut außer, dass sie historisch gewachsen und über die verschiedenen tools maximal inkonsistent ist?

maximal inkonsistent würde ich nicht sagen.
in 99% der Fälle wird nem Interface eine IP mit netzmaske zugewiesenund ein paar routen eingefügt. Vielleicht noch an der mtu geschraubt und das wars. Da sind alle schön einheiltich. Wo's drüber raus geht ist im übrigen auch iproute2 nicht kompatible zu IOS.
Besser oder schlechter ist an der Syntax natürlich gar nichts. Der Vorteil ist eben dass sie historisch da ist. Bis jetzt konnte ich zumindest für einfachere aufgaben seit zig Jahren auf zig verschiedenen betribessystemen route und ifconfig nutzen. Für mich als user bedeutet das einmal lernen, als programmierer einmal programmieren. Ab jetzt heißt es zwei mal lernen und zwei mal programmieren. So einfach ist das.

Selbstverständlich ist es viel einfacher seinen eigenen senf zu programmieren und da rumzuändern wie man lustig ist statt sich auf einheitliche standards zu einigen. Für alle die deine Programme/APIs nutzen ist es eine Zumutung. Und das sind gerade für solche tiefliegenden tools wie Netzwerkkonfiguration oder Diensteverwaltung hundertemale so viele
Und wie gesagt: Dass ifconfig unter BSD und Linux das gleiche Programm ist muss nicht sein. Aber dass es nach außenhin gelich junktioniert ist einfach eine tolle Sache.

Und für beides gilt im übrigen dass sie mit weit mehr brechen als mit nur mit der speziellen sache: Auch viel grundliegendere Konventionen werden nicht beachtet: Z.B dass Optionen mit "-" bzw. lange mit "--" anfangen. Oder dass man in konfigurationsfiles kleinbuchstaben nutzt. Außer für konstanten die sind vollständig groß. Das Abschnitte in geschweiften Klammern sind. Alles Kleinigkeiten über die man sich streiten kann. (Z.B. dürften die [] Überschriften von systemd weit einfacher parsbar sein. Dafür lassen sie sich nicht schachteln...) Aber es ist eben eine Mega hilfe, dass es einheiltich ist. Auch weil es massenhaft tools (wie arg libs) gibt, die auf diese konventionen abgestimmt sind.

[nudgegoonies]

Und wie gesagt: Dass ifconfig unter BSD und Linux das gleiche Programm ist muss nicht sein. Aber dass es nach außenhin gelich junktioniert ist einfach eine tolle Sache.

Das habe ich unter anderem bei der firmeninternen LPI Vorbereitung gelernt, dass alle Mailer einen "sendmail" wrapper mitbringen, der dessen Syntax schluckt. Grundsätzlich macht sowas eine Migration natürlich leichter, aber es widerspricht dem "Fail Fast Prinzip", wenn man wirklich mal alles auf etwas neues umstellen will.

[catdog2]

Dass ifconfig unter BSD und Linux das gleiche Programm ist muss nicht sein. Aber dass es nach außenhin gelich junktioniert ist einfach eine tolle Sache.

Tut es ja nur sehr eingeschränkt und es existiert ja und scheint für dich zu reichen. Es steht dir auch frei ein mächtigers linux ifconfig zu schreiben was sich möglichst stark am BSD Vorbild orientiert aber der Leidensdruck war da wohl bei niemandem groß genug und bis auf ein paar Patches für rudimentäre IPv6 Unterstützung ist glaub ich nicht viel passiert.

Wo's drüber raus geht ist im übrigen auch iproute2 nicht kompatible zu IOS.

Und?

Und für beides gilt im übrigen dass sie mit weit mehr brechen als mit nur mit der speziellen sache: Auch viel grundliegendere Konventionen werden nicht beachtet: Z.B dass Optionen mit "-" bzw. lange mit "--" anfangen. Oder dass man in konfigurationsfiles kleinbuchstaben nutzt. Außer für konstanten die sind vollständig groß. Das Abschnitte in geschweiften Klammern sind. Alles Kleinigkeiten über die man sich streiten kann.

Wer bricht welche Konventionen? Generell: Sowohl bei config files als auch bei Kommandozeilenoptionen gibt es viele "Konventionen" aus denen man wählen kann. Natürlich könnte etwas Vereinheitlichung da nicht schaden aber das ist kein neues Problem und die Frage ist wer gibt die Konvention vor?

Selbstverständlich ist es viel einfacher seinen eigenen senf zu programmieren und da rumzuändern wie man lustig ist statt sich auf einheitliche standards zu einigen.

Standards sind gut aber sie zu erstellen ist aufwendig, langwierig und man muss Kompromisse eingehen, die für beide Seiten auch Nachteile haben.. Gerade wenn die Ansätze und Ziele stark auseinander gehen. Und das nur, damit der Admin sich nicht umgewöhnen muss? Macht halt keiner.

Das habe ich unter anderem bei der firmeninternen LPI Vorbereitung gelernt, dass alle Mailer einen "sendmail" wrapper mitbringen, der dessen Syntax schluckt. Grundsätzlich macht sowas eine Migration natürlich leichter, aber es widerspricht dem "Fail Fast Prinzip", wenn man wirklich mal alles auf etwas neues umstellen will.

Da muss man halt abwägen. So ein sendmail wrapper dürfte relativ simpel sein und der steht halt der neueren Lösung nicht im Weg.

[PeteMaravich]

Ich finde systemd eine hervorragende Lösung, die vieles besser und auch einfacher macht. Was mir an dem neuen Ansatz gefällt: Er ist eine gut durchdachte und systematische Lösung. SysVinit mit seinen Skripten hallte ich eher für Gefrickel.

Ich kann auch nicht sehen, dass systemd den Unix-Ansatz verletzt, also für jede Anwendung ein spezielles Programm. Systemd ist schließlich keine Anwendung, kein Werkzeug, sondern ein Systembestandteil, der mithilfe geeigneter Abstraktionen viele bisherigen Lösungen überflüssig macht. Und wenn man systemd nicht mag, weil er den Unix-Ansatz verletzt sieht, der müsste eigentlich auch gegen den Linux-Kernel sein.

Praktisch sieht es so aus, dass meine Rechner besser laufen als vorher. Mein Netbook mit 1 GB RAM hat nach dem Start von Gnome weniger als 200 MB belegt. Das System läuft besser als je zuvor.

[nudgegoonies]

Mein Netbook mit 1 GB RAM hat nach dem Start von Gnome weniger als 200 MB belegt.

Könnte dies an der "socket/port activation" liegen? So wie ich es verstanden habe, werden daemons ja erst dann gestartet, wenn man auf sie zugreift. Somit würde nach dem Start noch gar nicht so viel verbraucht. Sobald jeder Daemon einmal angefasst wurde, müsste der Speicherverbrauch eigentlich fast identisch sein. Ich habe in einer KVM mal ein nacktes Debian SID auf systemd umgestellt. Die Startmeldungen waren ja wirklich überhaupt nicht mehr zu sehen, so schnell ging das. Das würde zu der "socket/port activation" passen.

[PeteMaravich]

Mein Netbook mit 1 GB RAM hat nach dem Start von Gnome weniger als 200 MB belegt.

Könnte dies an der "socket/port activation" liegen?

Bestimmt liegt es daran. Aber da ich ohnehin meist nur surfe (ist schließlich ein Netzbuch ), brauche ich die meisten Dämonen auch nicht. Im Großen und Ganzen läuft das System nun runder. Meine Workstation mit 4 GB genauso. Zwar braucht die mehr RAM als das Netbook, aber das mag wohl an den Caches liegen. Wenn der Rechner erkennt, dass genug RAM da ist, geizt er umso weniger mit Festplattencache. Und meines Wissens gibt es immer noch Optiminierungspotential. Wenn ich lese,dass consolekit durch systemd überflüssig wird, dann würde ich gerne darauf verzichten. Ausprobiert habe ich schon, Gnome läuft auch ohne consolekit, aber dann kann man den Rechner nicht mehr in Bereitschaft schicken.

[wanne]

RAM"verbrauch" hängt in erster Linie von der messtechnik und den Einstellungen ab. Du kannst dem Kernel auch sagen, dass er nur die ersten 256MiB von deinem RAM nehmen soll. Wird dein System total lahm aber dafür hast du wunderbar RAM gespart.
Und zu nur browsen: Nach Egoshooter-Spielen so ziemllich das Anspruchsvollste was ein rechner so macht.
Wenn man ihm genug RAM zur verfügung stellt nimmt der FF sich erstmal ein knappes GiB ohne dass man überhaupt irgend was aufruft. Und Prinzipiell wäre es toll wenn das GiB schon vor dem start im RAM wäre. Deswegen startet Konqueror hier so wunderbar schnell. 99% hat KDE einfach schon im RAM liegen bevor der startet. Google hat das kapiert. Da wird kein Programm mehr beendet bevor der RAM benötigt wird.

[nudgegoonies]

...zumal der Linux Kernel den Speicher sowieso lazy allokiert http://landley.net/writing/memory-faq.txt

[tHoRax]

Praktisch sieht es so aus, dass meine Rechner besser laufen als vorher. Mein Netbook mit 1 GB RAM hat nach dem Start von Gnome weniger als 200 MB belegt. Das System läuft besser als je zuvor.

Finde diesen Fred seit seiner Erstellung sehr interessant,habe es aber unter frischgebackenenem stable es nicht hinbekommen, sysvinit de-zu-installieren und stattdessen das "schnellere", "debian-zukünftige" init-System zu installieren...
Ich kann nach dem das "frischgebackene" stable mit sysvinit installiert wurde zwar ein apt-get install systemd systemd-init-system installieren,aber sobald ich das alte init-system(sysvinit) von der Platte haben möchte, kommt es dazu:

root@m3c:/home/m2c# apt-get purge sysvinit
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
Die folgenden Pakete werden ENTFERNT:
sysvinit*
WARNUNG: Die folgenden essentiellen Pakete werden entfernt.
Dies sollte NICHT geschehen, außer Sie wissen genau, was Sie tun!
sysvinit
0 aktualisiert, 0 neu installiert, 1 zu entfernen und 0 nicht aktualisiert.
Nach dieser Operation werden 283 kB Plattenplatz freigegeben.
Sie sind im Begriff, etwas potentiell Schädliches zu tun.
Zum Fortfahren geben Sie bitte »Ja, tue was ich sage!« ein.
?]

Habe ich in dieser Hinsicht was falsch verstanden oder gar interpretiert?
Wie macht ihr denn das?
Würde ich zum Fortfahren "ja" wählen, würde es vieles von der Platte hauen und das System würde dann nicht mehr laufen.Oder habt ihr das so hinbekommen, dass ihr das neue init-system parallel zu sysvinit installiert, ist es so zu verstehen?
Ich würde mal systemd gerne ausprobieren auf meinem asus eepc-1201pn,aber wie schon oben beschrieben, klappt es nicht...

[JTH]

Oder habt ihr das so hinbekommen, dass ihr das neue init-system parallel zu sysvinit installiert, ist es so zu verstehen?

Genau, du kannst beides parallel installiert haben. Um dann mit systemd zu starten, gibst du dem Kernel noch einen init-Parameter mit. Für Grub änderst du zum Beispiel in /etc/default/grub die entsprechende Zeile, dass sie so oder ähnlich aussieht:

Code: Alles auswählen

GRUB_CMDLINE_LINUX_DEFAULT="quiet init=/lib/systemd/systemd"

update-grub danach nicht vergessen. Falls es dabei Probleme gibt, kannst du den init-Teil beim Booten im Grub-Menü auch jederzeit wieder entfernen (nicht dauerhaft, nur für den Start).

[MrGerardCruiz]

Heieiei wenn man schon am Init System rumspielt, sollte man doch wohl Wiki Artikel lesen können. Das ist doch hier lang und breit erklärt:
https://wiki.debian.org/systemd

[photor]

Moin Forum,

ich habe den Schritt jetzt auch mal getan: systemd aktiviert. Das Teil bootet jetzt ja, wie die Feuerwehr

Allerdings habe ich noch ein Problem, dass der sshd nicht startet:

Code: Alles auswählen

root@picard:~# systemctl list-units
UNIT                                      LOAD   ACTIVE SUB       DESCRIPTION
[...]
speech-dispatcher.service                 loaded active exited    LSB: Speech Dispatcher
ssh.service                               loaded failed failed    OpenBSD Secure Shell server
sysfsutils.service                        loaded active exited    LSB: Set sysfs variables from /etc/sysfs.c
systemd-hostnamed.service                 loaded active running   Hostname Service
systemd-journald.service                  loaded active running   Journal Service
systemd-logind.service                    loaded active running   Login Service
[...]

... und ich kann ihn auch nicht nachstarten:

Code: Alles auswählen

root@picard:/etc/systemd# systemctl enable sshd
Failed to issue method call: No such file or directory

Aber eigentlich wollte ich gar nicht nach einer Lösung dafür fragen, sondern eher, wo wird systemd im Zusammenhang mir Debian diskutiert - auf User-Level? Ich wollte micht nicht zu tief in die Eingeweide begeben.

Ciao,

Photor

[JTH]

Code: Alles auswählen

root@picard:/etc/systemd# systemctl enable sshd
Failed to issue method call: No such file or directory

Aber eigentlich wollte ich gar nicht nach einer Lösung dafür fragen […]

Trotzdem: Der Service heißt in dem Fall ssh, ohne d. Und sofort starten tust du mit systemctl start, systemctl enable sorgt nur für automatisches Starten beim Booten