systemd-sysv install, sysvinit-core remove??

[whiizy]

Hallo,

bei einem simulierten dist-upgrade von Debian jessie heute fällt mir auf, daß sysvinit-core entfernt würde und dafür systemd-sysv installiert werden soll. Das klingt nach einer tiefgreifenden Umstellung, die ich nicht so leichtfertig ausprobieren möchte.

Hat das vielleicht heute schon einer gemacht? Und ist anschließend noch in der Lage, an jenem PC eine Antwort ins Forum zu schreiben, um meine Bedenken zu zerstreuen?

Gruß

[smutbert]

Ja, das stellt das init-System auf systemd um. (Habe ich schon bei wheezy gemacht und hatte seitdem kein ernstes Problem)

Du kannst aber leicht ausprobieren, ob du Probleme haben würdest: systemd-sysv ersetzt hauptsächlich /sbin/init durch einen Symlink auf /lib/systemd/systemd. Wenn du also systemd, libpam-systemd bereits installiert hast, kannst du testweise einfach dem Kernel ein init=/lib/systemd/systemd als Parameter mitgeben und so mit systemd als init-System starten.
Wenn danach noch alles funktioniert, kannst du beruhigt das Update machen, wenn nicht, ist der Spuk nach einem Neustart ohne diesen Kernelparameter wieder vorbei.

[whiizy]

Vielen Dank smutbert,

mein system läuft noch , alles gut gegangen!

Gruß

[AopicieR]

Hallo,

ich habe dieses Update auch gerade installiert und nach einem anschließenden Reboot hat die Namensauflösung für das Internet nicht mehr funktioniert. Anscheinend liegt dies an Bug 749405. Der dort in Message 19 genannte Workaround funktioniert für mich:

Code: Alles auswählen

# systemctl start resolvconf
# systemctl restart networking

[Patsche]

Hatte das selbe Problem, wie mein Vorredner. Verbindung zum Router kein Problem, aber ins Netz ging nichts. Hoffentlich fliegt einem durch diese systemd Umstellung nicht Alles um die Ohren

[habakug]

Hallo!

Der offizielle "Workaround" ist z.Zt. das Ändern des Targets:

Code: Alles auswählen

> [Install]
> -WantedBy=network.target
> +WantedBy=sysinit.target

Da muss aber debianspezifisch noch aufgeräumt werden [1],
Der Bugreport ist wirklich lesenswert.

Sorry, I only tested this unit on
NM enabled systems.

Gruss, habakug

[1] https://bugs.debian.org/cgi-bin/bugrepo ... =749405#74

[Blackbox]

Migration seit einer Woche durch, bei mir gibt es bisher auf dem Dell-Rechner mit xfce keine Probleme.
Liegt sicher am Minimalsystem !?

Nur auf meinem Notebook funktioniert seit ca. 1,5 Monaten kein grafisches »Herunterfahren« und »Neustarten«, aber dies war bereits, bevor Systemd installiert war.
Meine Vermutung ist, dass LXDE mittlerweile zu veraltet ist und die Schnittstellen nicht mehr passen.
Da LXDE über kurz oder lang auch in Debian durch LXQt ausgestauscht wird, suche ich mir ein neues DE, also für mich kein gravierender Fehler.

[Patsche]

Nur auf meinem Notebook funktioniert seit ca. 1,5 Monaten kein grafisches »Herunterfahren« und »Neustarten«, aber dies war bereits, bevor Systemd installiert war.
Meine Vermutung ist, dass LXDE mittlerweile zu veraltet ist und die Schnittstellen nicht mehr passen.

Ist das der Bug, von dem Dieser User spricht?
-> viewtopic.php?f=2&t=150202#p996605
Eine Lösung scheint noch nicht in Sicht.

[Blackbox]

Nur auf meinem Notebook funktioniert seit ca. 1,5 Monaten kein grafisches »Herunterfahren« und »Neustarten«, aber dies war bereits, bevor Systemd installiert war.
Meine Vermutung ist, dass LXDE mittlerweile zu veraltet ist und die Schnittstellen nicht mehr passen.

Ist das der Bug, von dem Dieser User spricht?
-> viewtopic.php?f=2&t=150202#p996605
Eine Lösung scheint noch nicht in Sicht.

Ich weiß nicht genau, ob ich ebenfalls von dem Bug betroffen bin, da ich keinen lightdm benutze und der Fehler bereits vor dem Rollout von systemd-sysv auftrat.
Mein bevorzugter Displaymanager ist slim.

[whiizy]

Hi

es ist übrigens auch kein Bug im Display-Manager lightdm, sondern im Paket lxsession (0.4.9.2-1 amd64), wenn das darin enthaltene Binary lxsession-logout aufgerufen wird. Finde ich auch nicht dramatisch, nur hinterlässt sowas verständlicherweise immer einen besonders schlechten Eindruck, wenn grundlegende Funktionen klemmen. Aber ist halt "Testing", da darf das.

Gruß

[michaa7]

Aus gegebenem anlaß ( systemd-sysv install, sysvinit-core remove):
Kann man als sid user davon ausgehen noch längere zeit auf systemd *verzichten* zu können oder ist die Debian strategie dass sysvinit nun bald *sterben* (nicht mehr zwingend unterstützt) wird und ich alsbald auf systemd umstellen *muss*?

[cosmac]

Kann man als sid user davon ausgehen noch längere zeit auf systemd *verzichten* zu können oder ist die Debian strategie dass sysvinit nun bald *sterben* (nicht mehr zwingend unterstützt) wird und ich alsbald auf systemd umstellen *muss*?

Das würde mich auch interessieren, bis jetzt hab' ich nichts bzw. widersprüchliches zu der Frage gefunden:
https://lists.debian.org/debian-project ... reads.html
https://packages.debian.org/jessie/sysvinit
http://www.preining.info/blog/2014/04/d ... ing-abyss/
http://www.riedquat.de/blog/2011-07-31-01

[Blackbox]

Kann man als sid user davon ausgehen noch längere zeit auf systemd *verzichten* zu können oder ist die Debian strategie dass sysvinit nun bald *sterben* (nicht mehr zwingend unterstützt) wird und ich alsbald auf systemd umstellen *muss*?

Das würde mich auch interessieren, bis jetzt hab' ich nichts bzw. widersprüchliches zu der Frage gefunden:
https://lists.debian.org/debian-project ... reads.html
https://packages.debian.org/jessie/sysvinit
http://www.preining.info/blog/2014/04/d ... ing-abyss/
http://www.riedquat.de/blog/2011-07-31-01

Also systemd wird auf jeden Fall in Debian das Standard Init System von Jessie werden, inwieweit sysvinit weiter für X86 gepflegt wird, bleibt abzuwarten.
Was mich aber gerade wundert ist, wie könnt ihr euch als Unstable Benutzer gegen systemd wehren, wenn es bereits in testing angekommen ist ?

[smutbert]

Indem man es einfach nicht installiert (zumindest nicht systemd-sysv — einige der anderen systemd-Pakete wird man wegen der Abhängigkeiten wohl meist installieren müssen)?

Ich glaube sysvinit(-core) wird es auch weiterhin geben, auch wenn es vielleicht nicht mehr so gut gepflegt wird und darüber hinaus gibt's ja neben upstart auch openrc als Alternative. systemd hat es auch schon in Debian gegeben schon lange bevor klar war, dass Debian überhaupt auf ein anderes init-System als Standard umsteigen wird.

Was man den Debianentwicklern eigentlich gar nicht hoch genug anrechnen kann, ist dass sie systemd in einzelne Bestandteile zerlegen und diese einzeln paketieren, denn sonst würde man sich allein mit der Installation eines Displaymanagers schon das kompletten systemd einhandeln. Ich meine systemd funktioniert bei mir zwar soweit problemlos, aber ich finde es schön, dass Debian Alternativen bietet.

[Blackbox]

Indem man es einfach nicht installiert (zumindest nicht systemd-sysv — einige der anderen systemd-Pakete wird man wegen der Abhängigkeiten wohl meist installieren müssen)?

Ich glaube sysvinit(-core) wird es auch weiterhin geben, auch wenn es vielleicht nicht mehr so gut gepflegt wird und darüber hinaus gibt's ja neben upstart auch openrc als Alternative. systemd hat es auch schon in Debian gegeben schon lange bevor klar war, dass Debian überhaupt auf ein anderes init-System als Standard umsteigen wird.

Wie kannst du dich gegen ein Update wehren, dass bei einem dist-upgrade mitkommt, da der Maintaner es nun vorschreibt, zu installieren ?
Bevor systemd Pflicht war, haben wahrscheinlich die meisten Unstable und Testing Benutzer davon abgesehen es freiwillig zu installieren, aber seit ca. 3 Wochen ersetzt systemd-sysv eben sysvinit-core zumindest in Debian Testing.
genau aus diesem Grund, gibt es auch diesen Thread.
Was nutzen dir Alternativen, wenn diese nur unzureichend (openrc) gepflegt/unterstützt, in absehbarer Zeit eingestellt (Upstart) werden, weil ein Initsystem die meisten Distributionen dominiert ?
Hast du openrc wirklich schon einmal produktiv in Debian im Einsatz gehabt ?

Was man den Debianentwicklern eigentlich gar nicht hoch genug anrechnen kann, ist dass sie systemd in einzelne Bestandteile zerlegen und diese einzeln paketieren, denn sonst würde man sich allein mit der Installation eines Displaymanagers schon das kompletten systemd einhandeln. Ich meine systemd funktioniert bei mir zwar soweit problemlos, aber ich finde es schön, dass Debian Alternativen bietet.

Ja, meist funktioniert systemd auch geräuschlos, aber ich habe auch kein Testing (mal abgesehen von meinem Rechner) in der Firma laufen, der schon Systemd verwendet, sollten dann in Stable-Jessie solche Probleme wie im Moment auftreten, rennen mir die Benutzer die Bude ein und darauf kann ich aus sicher nachvollziehbaren Gründen, gern verzichten.
Aber bisher waren die Freezes ja immer so gelaufen, dass so gravierende Fehler behoben waren, mit diesem Wissen im Hinterkopf, vertrau ich auch beim Wechsel von Wheezy zu Jessie dass das Debian Projekt auch diesen Release in gewohnter Qualität abliefert.

[whiizy]

Was mich aber gerade wundert ist, wie könnt ihr euch als Unstable Benutzer gegen systemd wehren, wenn es bereits in testing angekommen ist ?

Automatisch "angekommen" ist systemd-sysv anscheinend auch noch gar nicht. Auf meinem LXDE-Desktop war es anscheinend durch irgendeine Abhängigkeit "hereingekommen". Auf einem anderen Laptop mit XFCE hinegegen ist es bei einem dist-upgrade letzte Woche noch nicht reingerutscht (wohl weil es auf diesem System noch keine Abhängigkeit gab).

[Blackbox]

Also, ich habe ein Testing Minimalsystem mit xfce und eines mit LXDE-core, beide haben am selben Tag per täglichen dist-upgrade systemd-sysv bekommen, welches wiederum sysvinit-core ersetzt, wie bereits erwähnt.
Ich habe wie mittlerweile klar sein sollte, systemd-sysv nicht extra angefordert.

EDIT: Mein dist-upgrade stellt heute früh um 5:50 Uhr diese Pakete bereit:

Code: Alles auswählen

libgudev-1.0-0 liblwp-protocol-https-perl libopenal-data libopenal1 libpam-systemd libsystemd-daemon0 libsystemd-id128-0 libsystemd-journal0 libsystemd-login0 libudev1 systemd systemd-sysv udev youtube-dl

Genauso kam Systemd auf mein System.

[whiizy]

Zumindest bis letzte Woche hing es bei mir noch vom installierten System ab, ob systemd-sysv einlief. Mein letztes jessie dist-upgrade war laut history.log vom 17.07.14 und gemäß jenem Stand war systemd-sysv da noch nicht bei mir eingeflossen:

Code: Alles auswählen

Start-Date: 2014-07-17  12:06:41
Commandline: apt-get dist-upgrade
[...]
End-Date: 2014-07-17  12:06:51

# dpkg -l system*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version      Architecture Description
+++-==============-============-============-==================================
ii  system-config- 1.4.3-4      all          graphical interface to configure t
ii  system-config- 1.4.3-4      amd64        Utilities to detect and configure 
un  system-log-dae <none>       <none>       (no description available)
ii  systemd        204-14       amd64        system and service manager
un  systemd-servic <none>       <none>       (no description available)
ii  systemd-shim   6-3          amd64        shim for systemd
un  systemd-sysv   <none>       <none>       (no description available)
un  systemd-ui     <none>       <none>       (no description available)
root@ativ:/var/log/apt# date
Mon Jul 21 09:12:46 CEST 2014

Wenn ich heute allerdings ein dist-upgrade machen würde, dann kommt es *jetzt* auch:

Code: Alles auswählen

# apt-get -s dist-upgrade | grep systemd-sysv
  systemd-sysv
Inst systemd-sysv (208-6 Debian:testing [amd64]) [libpam-systemd:amd64 ]
Conf systemd-sysv (208-6 Debian:testing [amd64]) [libpam-systemd:amd64 ]

Ob das mit Stand heute allerdings auf *allen* jessie-Installationen so der Fall sein muß, weiß ich nicht.

Gruß

[michaa7]

...
Was mich aber gerade wundert ist, wie könnt ihr euch als Unstable Benutzer gegen systemd wehren, wenn es bereits in testing angekommen ist ?

"Wehren" ist nicht das was ich mache, schon allein weil ich es ja gar nicht verhindern kann dass möglicherweise systemd eines tages ohne wirklich mit allen notwendigen paketen funktionierende alternative dasteht (gnome3 nehme ich da gerne aus, aber damit geht es natürlich schon los).
In deiner diktion "wehren" sich Debian systemd entwickler offenbar gegen openrc, upstart und sysvinit was meiner ansicht nicht *nicht* der fall ist.

Ich wehre mich auch nicht gegen gnome3, nichteinmal gegen QT4.5/5, KDE4.x. Aber ich nutze eben in unstable seit jahren fluxbox. Ich will das neueste inkscape/libreoffice/und-noch-ein-paar-andere-neueste-pakete, aber ich weiche featuritis aus wo immer ich nur kann. Ich bin eben ein extrem konservativer unstable user. Ja, das geht sehr gut, so widersprüchlich es dir auch erscheint.

Mit systemd findet ja ein paradigmenwechsel statt. Meine hoffung ist dabei dass dieser eine alternative darstellt, und nicht eine abkehr. Allerdings überwiegt eine gewisse skepsis, denn ob letztendlich die DD manpower dazu ausreicht ist mehr als fraglich. Aber bis zum vielleicht eines tages anstehenden zwangsumstieg möchte ich mir, obwohl ich *seit jahren* von sid einiges gewohnt bin, dennoch sämtliche immer wieder mal auftauchenden systemd unzulänglichkeiten vom hals halten.

[paulderfinne]

Entschuldigt, wenn ich mich hier in deisem Thread einmische. Ihr diskutiert hier auf einem sehr hohen Niveau (oder sollte ich sagen sehr tiefen - tief im System sozusagen). Ich bin eben nur ein User und möchte Standardsoftware laufen lassen. Normalerweise installiere ich nur stable, aber diesmal war es unumgänglich aus Gründen, die jetzt hier nicht hergehören (Wer neugierig ist, bitteschön: viewtopic.php?f=33&t=149899 ).Und als ich xfce installieren wollte, hat der Installer auch bei mir sysvinit-core entfernt. Das fand ich eben auch merkwürdig und bin nun hier gelandet und habe wie immer dazu gelernt. Also bis jetzt funktionieret wohl alles. normal, nur der grafische Login nicht. Beim installieren von xfce wird der eigene wm normalerweise installiert (xfwm4 oder so). Der war auch installiert, laut dpkg. Habe trotzedem versuch den lwm zu installieren, dachte vielleicht gelingt es mit dem. Aber nein.

Wie ist das nun? Seitdem der systemd da ist, bootet das Sysytem viel schneller, die übliche Abarbeitung der /etc/rcx.d/ Dateien scheint er nicht mehr zu machen. Geht er deshalb ncht in den grafischen Login? Ist ja eigentlih kein Problem sich auf der Konsole einzuloggen und dann startx einzugeben, aber dennoch. Die heutigen User wollen doch alles bunt und klick...

[smutbert]

Der Windowmanager (zB xfwm4) hat nichts mit dem grafischen Login zu tun, dafür ist der Displaymanager zuständig, also zB slim, lightdm/lightdm-gtk-greeter, gdm3, kdm,… — dass der nicht startet kann viele Ursachen haben. Was steht denn in /etc/X11/default-display-manager? Es könnte auch bereits helfen den Displaymanager neu zu installieren (zB apt-get --reinstall install lightdm lightdm-gtk-greeter) damit sichergestellt ist, dass der Displaymanager überhaupt aktiviert ist und gestartet wird.

lightdm ließe sich zB auch mit

Code: Alles auswählen

systemctl start lightdm.service

manuell starten und mit

Code: Alles auswählen

systemctl enable lightdm.service

für jeden Systemstart aktivieren (falls das das Problem ist)

___

Unter rc?.d sind ja nur symbolische Links auf die Skripte unter /etc/init.d/ und die verwendet systemd tatsächlich normalerweise nicht. Stattdessen hat systemd eigene „units“ (service, socket, target,…). Welche Dateien dafür zuständig sind, kann man sich leicht an der Dateiliste eines Systemdienstes ansehen, hier ein Ausschnitt aus

Code: Alles auswählen

$ dpkg -L openssh-server
[…]
/etc/init.d
/etc/init.d/ssh
[…]
/lib/systemd/system/ssh.socket
/lib/systemd/system/ssh@.service
/lib/systemd/system/ssh.service
[…]

Viele Dienste enthalten sowohl die klassischen Startskripte wie hier /etc/init.d/ssh und zusätzlich die entsprechenden Dateien für systemd, auch der Loginmanager lightdm

Code: Alles auswählen

$ dpkg -L lightdm | grep systemd
/lib/systemd
/lib/systemd/system
/lib/systemd/system/lightdm.service

Nur wenn das nicht der Fall ist, greift systemd auf die klassischen Startskripte zurück.

[paulderfinne]

Danke für deine Ausführungen, smutbert.

Der systemd scheint ja eine ziemliche Revolution zu sein. Da muss man richtig umdenken. Habe nun den lightdm installiert und der kommt tatsächlich. Allerdings erst nach einiger Zeit. Will heißen, zuerst kommt der normale Konsolen-Login und mittendrin als ich mich anmelden wollte, startete der Lightdm. Die von /etc/rc?.d vorgenommene Reihenfolge scheint nicht mehr eingehalten zu werden.

[smutbert]

Ja, systemd kennt die Abhängigkeiten der einzelnen Dienste und anderen Units untereinander und startet sie nach Möglichkeit parallel - eine feste Reihenfolge gibt es meines Wissens gar nicht.

[paulderfinne]

Ja, der Startvorgang wird beschleunigt. Hoffentlich gibts sonst keine negativen Überrschungen.

[catdog2]

Ja, systemd kennt die Abhängigkeiten der einzelnen Dienste und anderen Units untereinander und startet sie nach Möglichkeit parallel - eine feste Reihenfolge gibt es meines Wissens gar nicht.

Das ist aber nicht wirklich neu, das hat sysvinit in debian auch schon so in der Art gemacht. Systemd macht es nur nochmal besser.