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 ...
Installationsversuch von udev ohne Softlink /lib/udev/udevd
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
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 :)
Funzt mit slh Kernel und erneuerter initrd (update-initramfs) performant!
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.
Interessant!!!
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? ;-)
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.
@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)?
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
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
@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
@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.
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
Tja, das ist halt das 'sichere' apt-get Verfahren, mit aptitude gehts, schaust hier, erst apt-get, dann aptitude:
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.
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
Vorteile von systemd für Desktop-User jetzt:
keine
Ich bin auch zurück nach sysv-insserv, weil es einfach nervig ist durch den Wust durchzusteigen, wenn systemd noch zusätzlich altbackene sysv-scripte einsetzt.
Vorteile von systemd für Distributoren:
Es sollten sich perfekt und einfach und optimal optimiert zusätzliche Features realisieren lassen, zukünftig mit systemd!
Allgemein:
- Wenn Linux eine allgemein anerkannte Serviceverwaltung bekommt (Achtung Ubuntu bleibt bei upstart), wäre das für Linux Administratoren eine erwünschte Vereinheitlichung
- Dadurch wäre Linux allgemein sicherer und flexibler zu verwalten
- Das jetzt gerade upstream implementierte Feature eines System-logs per systemd wird unverfälschbar sein, was in Firmen die Verantwortlichkeiten klarer macht. Dies ist wahrscheinlich der Hauptpunkt den die Entwickler bei Redhat ihren Großkunden anbieten möchten.
Okay super danke so ähnlich habe ich das auch gesehen/verstanden, bin auch inzwischen wieder zurück zu SysV.
Ajen
Edit: Unter Fedora 16, das ich seit gestern auch zum testen mal installiert habe sieht die Sache natürlich anders aus.
Hi Ajen,
wenn alle Initscripte auf systemd umgestellt worden sind ergibt sich mit Sicherheit eine Verkürzung der Bootzeit, da die Scripte eventgesteuert und nicht von einander abhängig sind (zumindest ein Großteil davon) und parallel ausgeführt werden können.
Ich habe u.a. auch eine aktuelle Fedora Version installiert die gerade noch fünf konventionelle Initscripte nach einer Defaultinstallation hat.
Das Handling von systemctl ist am Anfang gewöhnungsbedürftig aber zugleich auch sehr mächtig. Nach ein paar Tagen hat man die wichtigsten Kommandos im Gedächtnis.
Hier Links zum Thema:
http://crashmag.net/useful-systemd-commands
http://mikuerschner.org/node/26
https://wiki.ubuntu.com/systemd
Hast Du schön geschrieben, ralul. Ich sehe schon gewisse Vorteile in einem funktionierenden und verständlichen Startsystem - sei es bsd-style, sysv, upstart oder halt systemd. Im Endeffekt hat man die Dinger nicht zu bemerken und gut ists gewesen.
Ohne jetzt in wildes Bashing abgleiten zu wollen: Ich habe es mit meiner jetzigen Rechnerkonfiguration geschafft, einen Systemstart bis in den fertigen Desktop innerhalb von 9-12 sec hinzulegen. Da ich dass mit manuellem Login gemacht habe, waren die Werte schwankend. ;)
Diese Werte habe ich mit bsd-style init und upstart erreicht. Momentan brauche ich für einen fertigen Desktop ca. 30s. Unabhängig vom Init-System. Des Rätsels Lösung, die ca. 10s waren Gnome2, die ca. 30-40s KDE. Nur um weiter mit Zahlen um mich zu werfen: Der Login in KDE kommt nach ca 11s. Alles in allem Zeiten, an denen ich nicht mehr rumschrauben möchte. Eine drastische Beschleunigung wird das wahrscheinlich erfahren, wenn ich endlich neue Hardware habe. Namentlich mal eine SSD mit mehr als 280M/s Durchsatz könnte noch was bringen.
Und ob dann diese Ergebnisse einem Herrn P. gefallen oder sich Ubunteros angepisst fühlen, ist mir in diesem Fall erst einmal recht egal. Was Klasse wäre - für die wenigen Fälle, wo man das wirklich braucht, wäre ein funktionierendes eventgesteuertes Starten und Beenden von Diensten ganz nett. Das hätte ich mit systemd und upstart. Die Frage nach dem Sinn bleibt weiterhin bestehen. Ein ordentliches Netzwerkmanagement, was zuverlässig funkt, wäre mir für mein Notebook sehr wichtig. Dafür könnte ich mich begeistern. Das hat aber nur sehr mittelbar was mit systemd oder upstart zu tun.
Im mobilen Netzwerkbereich sehe ich also gewiss einige Verwendung für so was. Stationär ist mir das vollkommen schnurtz - die Startzeit meines Servers oder meines Desktops interessieren mich nicht wirklich. Diese Zeiten machen an der täglichen Verwendung meiner Rechner nicht mal den Bruchteil eines Prozentes aus. ;)
Vielleicht bin ich da zu konservativ, aber funktionierende, plattformübergreifende Browser, ein flinkes DE, komfortable WMs - als Krönung vielleicht noch abgerundet durch einen leistungsstarken, komfortablen, plattformunabhängigen Mailclient mit funktionierendem Adressbuch und Terminverwaltung: Das hätte was. Da würde ich gern auf ein oder zwei Sekunden Startzeit verzichten. Aber man muss ja Prioritäten setzen. Der Herr Poettering seine - und ich meine.
Hi,
ja so hatte ich das auch verstanden, bei ähnlichen zu startenden Diensten habe ich unter Fedora im Gegensatz zu sid eine kürzere Bootzeit. Habe mir dein Fedorareview auch mal angeguckt und muss sagen, dass ich zu einem ähnlichen Schluss komme.
Da ich es aber parallel installiert lassen werde, werde ich mich eh mit systemd bzw. systemctl ein wenig auseinandersetzen und wohl aus Gründen der Vereinheitlichung unter sid wieder systemd installieren. Nach kurzem überfliegen deiner Links klingt das ganze ja soweit sinnvoll.
Ajen
Edit: @agaida: Du hast natürlich recht, wo die Prioritäten liegen ist immer so eine Sache.
QuoteCHANGES WITH 41:
* The systemd binary is installed /usr/lib/systemd/systemd now;
An existing /sbin/init symlink needs to be adapted with the
package update.
* The code that loads kernel modules has been ported to invoke
libkmod directly, instead of modprobe. This means we do not
support systems with module-init-tools anymore.
Debian hat systemd-37. Mit systemd-41 braucht man statt dem bisherigen Kernel-Modul Aktivierungsprogramm "modprobe" das neuere "kmod". Dies ist in Debian-experimental zwar vorhanden, aber es is inkompatibel mit den alten "module-init-tools" (ein leeres Transitionspaket für module-init-tools in experimental ist vorhanden).
Ich weiss nicht, ob bis zum Wheezy Release eine Ablösung des alten "modprobe" Tools geplant ist. Wenn nicht, dann wird es kaum auf sichere Art und Weise möglich sein neuere systemd Versionen unter Debian auszuprobieren, denn es hängt viel am alten "module-init-tools" Paket und die Transition zum neuen "kmod" Helferlein ist sicher mitnichten in allen ihren Auswirkungen getestet.
Außerdem verlangt L.Poettering eine spezielle initrd-Api zu respektieren, die bisher nur dracut als initrd-Bauwerkzeug verwirklicht hat...
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%23654157
Marco D'Itri meint, kmod sei Standard mit Wheezy.
greetz
devil
ich weiss wie immer nicht, was kmod anders als bisher macht. Ich weiss nur, dass es irgendwie funktioniert und ich den wechsel auf kmod nur mitbekommen habe, weil ich in Arch irgend eine Zeile ändern musste. Ungefähr so: http://www.archlinux.org/news/kmod-replaces-module-init-tools/
Es war schlichtweg so unbedeutend, dass ich das bis jetzt verdrängt hatte ;) Aber irgend einen Bezug und sittlichen Närwert wird es ja wohl haben.
@agaida, du hast Recht. Das kmod hat alle modprobe, rmmod, lsmod user tools wie gehabt. Langsam kommen immer mehr richtig neue Features nach systemd, wohl hauptsächlich für Server interessant:
QuoteCHANGES WITH 42:
* ...
* Watchdog support for supervising services is now usable. In
a future release support for hardware watchdogs
(i.e. /dev/watchdog) will be added building on this.
* Service start rate limiting is now configurable and can be
turned off per service. When a start rate limit is hit a
reboot can automatically be triggered.
* New CanReboot(), CanPowerOff() bus calls in systemd-logind.