systemd - hat funzt - noch hakelig

[ralul]

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.

[Ajen]

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.

[bluelupo]

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

[agaida]

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.

[Ajen]

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.

[ralul]

CHANGES 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...

[devil]

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%23654157
Marco D'Itri meint, kmod sei Standard mit Wheezy.

greetz
devil

[agaida]

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.

[ralul]

@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:

CHANGES 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.