[DE] systemd - hat funzt - noch hakelig

[ralul]

Als ich mein altes Debian sid heute mal wieder angeschmissen habe, habe ich gesehen, dass die Pakete

udev-175
systemd-37

vorhanden sind. Also fix installiert. Dann alles auf volle Kanne Risiko:

systemd-sysv
installiert. Dies erzwingt die Deinstallation von
sysvinit-2.88dsf

Aber sysv-rc-2.88dsf und initscripts-2.88dsf bleiben als Abhängigkeiten erhalten. Ich denke, dass systemd sich da noch bedienen will an den /etc/init.d/scripten!?

Und dann hatte ich ja noch openSUSE-12.1 installiert auf einer parallel Partition vorhanden. Also vergleich:
Ziemlich alles gleich wie SUSE, also alles ziemlich original wie upstream - denke ich. Aber eins war mir aufgefallen nach langem MidnightCommander Verzeichnisse und Dateien vergleichen, das Debian /lib/udev/udevd war nicht vorhanden, also:
ln -s /sbin/udevd /lib/udev/udevd

Dann habe ich gesehen, dass nur ein Getty konfiguriert ist:
/etc/systemd/system/getty.target.wants/getty@tty1.service

Also habe ich mit der Nummer tty2 einen zweiten verlinkt, weil ich im Notfall, wenn kein Kde4 geht wenigstens zwei Terminals haben wollte: Was soll ich sagen, es gibt bei mir jetzt neben Kde4 auf tty7 wie gewohnt, aber:
tty1
2 ist schwarz
tty3
...
Systemd scheint sich die Konsolen selber nach bedarf zu starten, man braucht kein extra getty.target konfigurieren.

Mehr hatte ich nicht gemacht und nicht mehr an den Systemd Configs laboriert. Alles läuft (kde4,net-wireless,dbus), aber es erscheint ein wenig hakelig in der Bedienungslatenz (machmal, aber kaum zu merken). Jetzt werde ich nochmal den oben beschriebenen Link /lib/udev/udevd zeitweilig löschen, nochmal udev drüber (erneut) installieren, nochmal initramfs neu machen,
und dann weiter schauen, wie die ursprüngliche Performance wieder herzustellen ist, aber mittels SYSTEMD ...

[ralul]

Installationsversuch von udev ohne Softlink /lib/udev/udevd

Code: [Select]

udev (175-2) wird eingerichtet ...
Reloading systemd
Restarting udev (via systemctl): udev.serviceJob failed. See system logs and 'systemctl status' for details.
 failed!
invoke-rc.d: initscript udev, action "restart" failed.

mit Softlink /lib/udev/udevd

Code: [Select]

udev (175-2) wird eingerichtet ...
Reloading systemd
Restarting udev (via systemctl): udev.service.
update-initramfs: deferring update (trigger activated)
Trigger für initramfs-tools werden verarbeitet ...
update-initramfs: Generating /boot/initrd.img-3.1.1-1.slh.2.bfs.51
Höö, also ist ein Bug im Debian systemd Paket mit dem /lib/udev/udevd.

Jetzt gleich nochmal restart versuchen mit frisch gebackener initrd

[ralul]

Funzt mit slh Kernel und erneuerter initrd (update-initramfs) performant!

[ralul]

War wieder mal udev Maitainer d'Itri mit dem udevd Fehler:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=649175

Mit meinem Workaround läuft systemd wunderbar jetzt bei mir.

[Lanzi]

Interessant!!!

[bluelupo]

Hi zusammen,
mal ne Frage zu systemd. Warum hinkt Debian mal wieder soweit hinten nach? SuSE und Fedora setzen systemd ohne große Probleme bereits erfolgreich ein. In systemd ist viel Potential zur Beschleunigung des Bootvorgangs drinnen, aber das erscheint bei den Debianer noch nicht angekommen zu sein oder irre ich mich da? ;-)

[agaida]

Genau das gleiche wie immer: Debian hat halt ein paar Architekturen mehr als die von Dir genannten Distributionen. Die springen erst dann so richtig an, wenn viele andere schon in die reichlich rumliegenden offenen Messer gelaufen sind.

Das finde ich in diesem Fall auch verständlich, wenn man das eigentliche Ziel von debian, eine stabile Distribution, die umfassend Architekturen bedient, im Auge behält. Der ganze Apparat ist, in diesem Fall zum Glück, zu mächtig und zu träge, um schnell aufzuspringen, wenn wieder einmal eine neue Sau durchs Dorf getrieben wird.

[ralul]

@bluelupo, gerade in dem Fall systemd hinkt Debian nicht nach, bis auf den einen Bug! Was mich echt sehr wundert:

Denn es stimmt, was agaida sagt. Und mit systemd gibt es richtige No-Goes mit anderen Archs : Systemd wird nicht auf FreBSD Kerneln laufen können (keine cgroups). Insofern wundert es mich, dass ich systemd auf Debian überhaupt laufen lassen kann. Und dass zu einer recht frühen Zeit (openSUSE hat es auch jetzt erst gerade mit 12.1 eingeführt).

@agaida, ja LPoettering hat schon Pulseaudio als Sau durchs Dorf ziehen lassen. Und wir haben alle die Erfahrungen:

- Erst hal (BSD baut hal eilig nach), jetzt nicht mehr hal
- Sound: Oss, dann alsa, dann pulseaudio
- Netz: network-manager ...

Aber man muss sagen, letztendlich
- Hal brauchen wir nicht mehr, alles ist im udev Eventsystem vereinheitlicht
- Pulseaudio ist weniger Resourcen fressend im Rechenverbrauch geworden als alle anderen Lösungen (weil es mehr cached, mehr Speicher gebraucht?), es reagiert zwar noch eine halbe Sedunde langsamer, wenn ich das Volume anhebe ...
- NM funzt jetzt auch gut, wenn man eine Distro nimmt, die es einrichten kann.

Die Richtung der Entwicklung bei Linux ist auf der Zielgeraden, zwar im Schlangenweg, aber hin zur Vereinfachung, dass alle es gut benutzen können.

Und vielleicht hatte Poettering ja was gelernt beim Pulsaudio Debakel. Und ihm ist Kai Sievers zur Seite gestellt bei systemd. War es nicht Kai Sievers, der das wunderbare parallel Boot insserv, was wir auch für Debian verwenden, erfunden hat als er noch bei SuSE war (Auf heise.de steht, er wäre jetzt bei Redhät)?

[devil]

Er ist bei Redhat jetzt, und ja, er hat insserv verbrochen. und er kennt Poettering sehr gut, wie ein heutiger, ironischer Seitenhieb auf G+ beweist: https://plus.google.com/u/0/115547683951727699051/posts

Ansonsten hatte ich systemd schon vor ziemlich genau nem Jahr erstmals getestet. Damals war allerdings die Implementation weit weniger fortgeschritten: http://siduction.org/index.php?module=news&func=display&sid=20

greetz
devil

[swo]

Moin.
Ich habe seit ein paar Tagen auch systemd und es läuft auch alles wunderbar.
Nur ein kleines Problem ist da halt doch noch mit apt. Das will mir dauernd wieder systemd-sysv runter jagen und wieder gegen sysvinit ersetzen. Ist das bei denjenigen hier die systemd schon einsetzen denn auch so? ralul?

Grüße
swo

[ralul]

@swo, hast Du denn diese Pakete

-------alle installiert:
libpam-systemd
systemd
systemd-sysv
libsystemd-daemon0
libsystemd-login0

--- vorher auch schon (schon immer):
initscripts
sysv-rc
sysvinit-utils

--- aber nicht installiert:
sysvinit
live-config-sysvinit

[swo]

@ralul:
ja habe ich alle installiert bzw. so wie du das aufgelistet hast + systemd-gui.
ich hab jetzt systemd-sysv erst mal auf hold. ist halt sonst ziemlich nervig beim dist-upgrade.

[devil]

swo,

eine lösung findet sich im http://wiki.debian.org/systemd unter Known Issues and Workarounds - Issue #1: sysvinit vs. systemd-sysv

greetz
devil

[ralul]

Tja, das ist halt das 'sichere' apt-get Verfahren, mit aptitude gehts, schaust hier, erst apt-get, dann aptitude:

Code: [Select]

root@maci:/etc# apt-get dist-upgrade
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut      
Statusinformationen werden eingelesen... Fertig
Paketaktualisierung (Upgrade) wird berechnet... Fertig
Die folgenden Pakete werden ENTFERNT:
  gnome-session gnome-shell gnome-shell-extensions gnome-tweak-tool libgnome-desktop-3-0 nautilus
  nautilus-sendto systemd-sysv
Die folgenden NEUEN Pakete werden installiert:
  pkg-config sysvinit
Die folgenden Pakete werden aktualisiert (Upgrade):
  busybox gnome-desktop3-data libgl1-nvidia-alternatives libgl1-nvidia-glx libglib-perl
  libglx-nvidia-alternatives libraptor2-0 librasqal3 nvidia-alternative nvidia-detect nvidia-glx
  nvidia-kernel-dkms nvidia-settings nvidia-vdpau-driver update-inetd xserver-xorg-video-nvidia
16 aktualisiert, 2 neu installiert, 8 zu entfernen und 0 nicht aktualisiert.
Es müssen 27,6 MB an Archiven heruntergeladen werden.
Nach dieser Operation werden 9.332 kB Plattenplatz freigegeben.
Möchten Sie fortfahren [J/n]? n
Abbruch.


root@maci:/etc# aptitude full-upgrade
Die folgenden NEUEN Pakete werden zusätzlich installiert:
  pkg-config{a}
Die folgenden Pakete werden aktualisiert:
  busybox libgl1-nvidia-alternatives libgl1-nvidia-glx libglib-perl libglx-nvidia-alternatives
  libraptor2-0 librasqal3 nvidia-alternative nvidia-detect nvidia-glx nvidia-kernel-dkms
  nvidia-settings nvidia-vdpau-driver update-inetd xserver-xorg-video-nvidia
15 Pakete aktualisiert, 1 zusätzlich installiert, 0 werden entfernt und 1 nicht aktualisiert.
Muss 27,2 MB an Archiven herunterladen. Nach dem Entpacken werden 126 kB zusätzlich belegt sein.
Wollen Sie fortsetzen? [Y/n/?]
Hat anscheinend den Nachteil, dass man bei aptitude nicht davor geschützt ist, sich ESSENTIAL Pakete zu entsorgen.

[Ajen]

Auch wenn der Thread jetzt schon etwas älter ist denke ich mir meine Frage passt hier am besten rein: Was wäre denn für den normalen User der Vorteil von systemd unter sid beim momentanen Stand?

Ich habe heute mal aus Neugierde systemd installiert und könnte für mich keine großartige Verbesserung feststellen. Kein schnellerer Bootvorgang (das sollte ja daran liegen dass immer noch die gleichen Initscripts genutzt werden und keine speziell für systemd optimierten oder?) und das war eigentlich das einzige, was ich mir davon erhofft hatte, da die ganzen anderen Sachen die systemd laut Lennarts Seite kann mich erstmal nicht sooo wirklich interessieren oder sollten sie das?

Hoffe da kann mich jemand erleuchten bis jetzt sieht es für mich nämlich mehr danach aus als ob man halt sagen könnte: "Ja es funktioniert" und mehr nicht.

Ajen