Bekomme ich jetzt doch systemd?

[michaa7]

Verstehe ich das richtig:

Wenn ich derzeit noch beim alten init system bleiben möchte reicht es sysvinit-core auf *hold* zu setzen?

Bei mir soll das nämlich eben beim d-u entfernt werden,  systemd-shim kommt, allerdings kommt letzteres auch nachdem ich sysvinit-core auf hold zu gesetzt habe.

[melmarker]

systemd-shim darf auch ruhig - dafür ist es ja auch ein shim-Paket:)

http://de.wikipedia.org/wiki/Shim
http://packages.qa.debian.org/s/systemd-shim.html

Und das macht genau das, was da drin steht, funktionale Erweiterungen für sysvinit

[gypsy56]

Wenn ich derzeit noch beim alten init system bleiben möchte reicht es sysvinit-core auf *hold* zu setzen?

Ja, bei mir reicht es, und ich habe zwar den KDE-Desktop, aber auch ein paar Gnomeanwendungen. Wenn sysvinit-core auf hold ist, dann wird systemd-sysv nicht installiert, und das reicht aus, daß systemd nicht aktiviert wird, auch wenn alle anderen Pakete bereits installiert sind.

[Maik]

Mit systemd-shim (6-3) wird über init (sysv) gestartet also keine Panik  , kein Freund von diesen Mainstream Attitüden alles "Blinkt und Singt".

[melmarker]

Ich hab mich noch mal ausführlich mit dem Paketbetreuern in #debian-systemd gezofft, herausgekommen ist dabei folgendes:
* die drive-by-Umstellung auf Systemd ist so beabsichtigt, das wird so bleiben und ist so gewollt
* wer testing oder sid benutzt, sollte mit so was umgehen können: auch eine klare und verständliche Ansage. Für stable ist es nach meiner Nörgelei vorgesehen, da einen extra Punkt in den Release Notes für einzurichten
* eine ganz eindeutige Aussage aus dem Chan: wer systemd-shim nicht zwingend braucht, Hände weg, eher auf den kompletten Satz systemd ohne wenn und aber verzichten. Nach einigen doch recht ernüchternden Blicken in den Quellcode von Lightdm kann ich dieser Aussage nur beipflichten. Und das ist nicht die einzige Quelle eventueller Probleme

Meine persönliche Meinung zu systemd: Klasse Sache, lieber supporte ich das und lerne komplett um und spar mir den Support von sysvinit in jeglicher Hinsicht (User, Packete, Scripts und Eigenentwicklungen) - diese klare Linie macht vor allem deshalb Sinn, da sie rein zufällig mit der Debian-Strategie fast deckungsgleich ist. Wer also gerne weiter sysvinit benutzen will, kann das im Rahmen dieser Prämisse gerne tun, ist aber bei Problemen dann weitgehend auf sich allein gestellt.

[absolut]

okay, danke für die infos...

weiterhin bleibt die frage, wie man nach solch einer umstellung verfahren soll. insbesondere finde ich problematisch, dass danach weder  "init 3" noch "systemclt isolate multi-user.target"  nicht das gewünschte resultat bringen, nämlich X zu beenden, um dist-upgrade ausführen zu können...

mit der installation der aktuellen iso (mit systemd schon von haus aus dabei), funktioniert multi-user.target, man landet in der tty...

für systeme, die durch ein dist-upgrade auf systemd umgestellt werden, funktioniert das halt nicht.

gibt es dazu konkrete lösungsvorschläge?

[melmarker]

ganz platt gesagt: Nö

weniger platt:
Wer so ein system hat, könnte sich die Arbeit machen und das analysieren. Wenn bei der Analyse was sinnvolles rauskommt, dann lösen und der interessierten Leserschaft diese Lösung präsentieren.

Sorry - ich konnte dieses Verhalten auf meinen Systemen nicht nachvollzieheen, kann daher also auch nicht wriklich viel zur Lösung der Probleme beitragen

[dieres]

ich hab hier 2 durch du umgestellte systeme. Das einzige Problem, das ich nach systemctl isolate multiuser.target hab, ist das ich auf nem schwarzen Bildschirm ohne login lande. Muss halt nochmal Alt-F1 drücken, um mich als root anmelden zu können. Aber es funktioniert, auch das kabelnetz ist up und man kann ganz normal updaten.

[absolut]

hier ein journalctl -b log, von einem "systemctl isolate multi-user.target" um genau 17:15:05
-> zu groß für den anhang, siehe den paste
-> http://paste.siduction.org/20140524152431

verhalten ist wie folgt: netzwerkmanager wird abgedreht, ich bekomme eine meldung, dass die wlan verbundung unterbrochen wurde... nach einigen sekunden ist die wlan verbindung wieder hergestellt.

aufruf von "systemctl isolate multi-user.target" im tty1 bringt dasselbe.

kde session läuft weiter, ohne irgendwelche weitere reaktion.

welche logs wären noch interessant?