“systemd” unter Opensuse 12.1 – ein Start nicht ohne Probleme
Ich versuche immer mal wieder, mich mit “systemd” anzufreunden – mehr gezwungenermaßen als mit Freude. In diesem Beitrag sammle ich lose einige Gedanken und Erfahrungen, die mir der erste Kontakt mit “systemd” unter Opensuse 12.1 beschert hat. Dieser Erstkontakt war vor allem von Zeitaufwand zur Behebung von schwerwiegenden Upgrade-Probemen auf mehreren unterschiedlichen Systemen gekennzeichnet. Das es nicht nur mir so ging, beweisen zahllose Kommentare, Hilferufe etc. im Internet (s.u.).
Ich bin wirklich kein Spezialist für Initialisierungsverfahren von Betriebssystemen. In der Tiefe kann ich “systemd” deshalb sicher nicht hinreichend würdigen und beurteilen. Vielleicht wird “systemd” in 2 Jahren auch mal ein ganz tolles Ding sein.
Leider wird man das “systemd”-Initialisierungs-Verfahren bis dahin ab Opensuse 12.2 aber nicht mehr einfach abstellen können – wie etwa den fehleranfälligen Soundserver “Pulseaudio”, der ja von einem der Mitautoren von systemd stammt. Das ist eines der Pakete, das ich nach regelmäßig schlechten Erfahrungen unter Opensuse mit gleicher Regelmäßigkeit einfach deinstalliere. Danach funktioniert der Sound auf meinen Systemen regelmäßig besser und zuverlässig!
Da etwas Ähnliches mit systemd ab Opensuse 12.2 nicht mehr auf einfache Weise geht, muss es erlaubt sein, sich nach dem aus meiner Sicht mehr als holprigen Start von “systemd” unter Opensuse 12.1 auch als Unbedarfter ein paar Gedanken zu machen.
Zentralisierte Komplexität
Systemd soll ja in der Theorie eine geradezu riesige Menge von Vorteilen aufweisen. Man sehe hierzu:
http://0pointer.de/blog/projects/why.html
Genau diese überwältigende Fülle an Features macht einen alten IT-Mann aber auch misstrauisch. Denn wenn im Zuge des Hochfahrens eines Linux-Systems so viel (anders und besser) geleistet werden soll, wie in den Tabellen des obigen Links dargestellt, dann besteht schon der begründete Verdacht einer gewissen, wenn nicht gar hochgradigen Komplexität des zugehörigen steuernden Programms.
Der Eindruck verstärkt sich, wenn man anfängt, sich als Linux-Nutzer ganz unbedarft in die Dokumentation und umfassenden Überlegungen eines der Hauptinitiatoren von “systemd” (Lennart Poettering) einzuarbeiten. Siehe die mittlerweile 15 Beiträge der Serie “systemd for Administrators” in “Lennarts Blog” :
Da ich persönlich es schwierig fand, in dem Blog zu navigieren, finden Interessierte eine Auflistung der 15 Poettering-Artikel mit ihren Link-Adressen am Ende meines hiesigen Blog-Beitrags.
“Systemd” wirkt – wenn vielleicht auch nicht aufgebläht, wie manche Kritiker meinen – so doch immerhin äußerst umfangreich und mit extrem hohen, ambitiösen Ansprüchen befrachtet. Eine knappe, halbwegs neutrale Darstellung der wesentlichen Vor- und Nachteile bietet aus meiner Sicht der folgende Artikel:
http://ikhaya.ubuntuusers.de/2012/09/22/systemd-das-init-system/
Dort lesen wir:
“systemd verlagert die Komplexität von vielen kleinen Skripten in eine zentrale Software.”
Man muss sich das einfach mal auf der Zunge zergehen lassen. Als Projektmanager, aber auch als SW-Entwickler lege ich normalerweise Wert darauf, Aufgaben in kontrollierbare, überschau- und kapselbare sowie delegier- und testbare Einheiten zu zerlegen. Alle diese Punkte treffen auf die Organisation des Bootvorgangs unter
System V – trotz der relativ komplexen Organisation der Startskripte – voll zu. Und vor allem:
Unter System V hat der shell-kundige Admin eine sehr weitgehende Kontrolle über den kompletten Startvorgang des Linux-Systems. Man ist deshalb wirklich versucht, die eben zitierte Aussage mal etwas ironisch umzuformulieren:
Man ersetzt die Komplexität vieler kleiner, aber separat kontrollierbarer Monster durch ein großes, komplexes Supermonster – und das Ganze ist ja bekanntlich mehr als die Summe seiner Teile – im Guten wie im Schlechten!
Es beschleicht einen jedenfalls ein ungutes Gefühl. Da wird eine geschlossene zentrale Steuereinheit gebaut, der man als Admin zwar noch Vorgaben machen kann, die – bzw. deren Module – man selbst aber nicht mehr kontrolliert oder kontrollieren kann. Diese zentrale Einheit muss dann auch tatsächlich alles im Griff haben und mit vielen komplexen Abhängigkeiten während des System-Initialisierungsvorgangs umgehen können! So etwas kann man sicherlich bauen – aber man muss kein Prophet sein, um zu prognostizieren, dass die notwendige Qualität und Reife einiges an Zeit erfordern wird.
Genau deswegen wäre es aus meiner Sicht auch sehr verwunderlich gewesen, wenn der praktische Umstieg von “System V” auf “systemd” unter Fedora 15/16 und Opensuse 12.1 ohne Probleme verlaufen wäre.
Ich bin als jemand, der als Anwender Linux-Desktop und -Serversysteme Linux für professionelle Schreibtisch- und SW-Entwicklungsarbeiten immer wieder in den Griff bekommen muss, zwar nicht wirklich kompetent, Grundsatzprobleme wie die Vor- und Nachteile von “System V” und “systemd” objektiv zu beurteilen. Ich bin kein Kernel-Entwickler oder Betriebssystem-Designer und habe keine Zeit, mich mit allen Untiefen von Linux zu befassen. Aber man macht halt beim praktischen Umgang mit “Innovationen” unter Linux im Laufe der Jahre so seine Erfahrungen. Ich erinnere nur an die bebenartigen Auswirkungen der Einführung von Akonadi als zentralem Datenpuffer bzw. Datendrehscheibe unter KDE …..
Zusammenfassen möchte ich meine bisherige Erfahrung mit der Einführung von “systemd” unter Opensuse 12.1 wie folgt:
Für mein Gefühl tauchten nach dem Upgrade von Opensuse 11.4 zu Opensuse 12.1 auf zu vielen meiner Systeme zu viele gravierende Probleme auf, als dass ich mich schnell mit “systemd” hätte anfreunden können.
Einen Teil der Probleme habe ich unter
https://linux-blog.anracom.com/2012/01/08/opensuse-121-erfahrungen-mit-einer-neuinstallation/
beschrieben. Weitere Erfahrungen folgen im Verlauf dieses Artikels.
Bei aller Innovationsfreude:
Die Einführung von systemd unter Opensuse 12.1 ist für mich erneut ein schlagendes Beispiel dafür, dass zu oft zu schnell an Fundamenten gerüttelt wird, ohne distributions- oder entwicklerseitig einen wirklichen Plan B zu haben. Was die langfristig sicher sinnvolle Einführung neuer zentraler Komponenten kurzfristig an massivem Ärger für die davon abhängig gemachten Dienste nach sich ziehen kann, hat man doch exemplarisch bei der Einführung von Akonadi unter KDE studieren können. Bis heute hat ein ehemals phantastisches KDE die Folgen nicht bewältigt!
Natürlich ist es immer schwer, einen geeigneten Zeitpunkt für so fundamentale Umstiege zu finden. Aber die regelmäßigen Schwierigkeiten, komplexere Opensuse 11.4-Systeme auf 12.1-Systeme mit “systemd” upzugraden, empfand ich in der Praxis doch als so schwerwiegend, dass ich “systemd” manchmal innerlich verflucht habe:
Mal ging/geht der gesamte Upgrade schief oder bricht mittendrin ab, manchmal funktioniert auch eine Neuinstallation nicht, mal kommt das Netzwerk nicht hoch, mal treten ewig lange Boot- oder Shutdown-Zeiten auf, dann gehen Shutdowns nicht mehr problemfrei über die Bühne, mal geht Apache
nicht und zieht Open-Xchange mit in den Abgrund, dann wieder funktionieren Postfix und MySQL nicht.
Man macht im Laufe von 6 Monaten so ziemlich alles durch, was in vielen Foren an Problemen im “systemd”-Umfeld beschrieben ist. Und man muss immer in die Trickkiste greifen, um die Probleme zu lösen. Wer es nicht glaubt:
Man google mal mit “systemd Opensuse 12.1 System bootet nicht”. Ein beispielhafter schöner Artikel eines verzweifelnden Users findet sich hier:
Wohlgemerkt:
All die von mir oben genannten Probleme traten zumindest auf meinen Systemen nach einem Umschalten auf System V (sysvinit) von Haus aus nicht auf oder verschwanden wieder. Manche Probleme gaben sich zugegebenermaßen auch im Zuge weiterer Updates.
Gewiss: Man kann sich immer irgendwie durchwurschteln, zwischenzeitlich auf System V zurückschalten, auf Updates mangelhafter Probleme hoffen, etc. – aber nervig und vor allem zeitaufwändig ist der Umstieg auf ein “systemd”-basiertes Opensuse 12.1 bisher doch gewesen.
Das will ich gar nicht den grundlegenden, innovativen Ideen zu “systemd” anlasten, eher unzureichenden praktischen Erprobungen vor dem Opensuse 12.1-Release. Es nutzt halt nichts, dass im Fall simpler Systeme eine Neu-Installation u.U. problemfrei durchläuft. Der Prüfstein ist für mich eher der fehlerfrei durchlaufende Upgrade eines komplexen Systems. Und genau da haperte es gewaltig. Aber ich weiß schon: Irgendwie ist man bei kostenfreien Linux-Systemen halt immer Beta-Tester und bezahlt mit eigenem Aufwand.
Zum Umstieg verdammt …
Immerhin hatte SuSE unter Opensuse 12.1 dem Anwender noch die Wahl gelassen, unter welcher Variante – systemd oder sysvinit – er booten wollte. (Ganz so schön getrennt, wie sich das liest, war die Alternativen übrigens nicht – aber lassen wir mal die technischen Details). Die unterschiedlichen Initialisierungsvarianten konnte man auf SuSE’s Grub-Startschirm über die “F5”-Taste erreichen oder aber durch Installation alternativer Pakete. (Siehe http://news.opensuse.org/2011/12/22/systemd-%E2%80%93-boot-faster-and-cleaner-with-opensuse-12-1/).
Ich fand das eigentlich einen guten Schachzug und hätte mir sehr gewünscht, dass diese Politik der Wahlfreiheit mehr als nur einige wenige Monate Bestand gehabt hätte. Leider wurde und wird man aber durch die “Politik” von SuSE systematisch gezwungen, den Umstieg auf “systemd” zu vollziehen. Es gab bereits im Lauf der letzten Monate eine Reihe von Anzeichen dafür, dass bei SuSE beschlossen wurde, keine Zeit mehr in die alten “System V”-Strukturen zu stecken, sondern alle Kräfte auf “systemd” zu konzentrieren.
Ein spürbares Beispiel ist die Tatsache, dass es auf dem aktuellen Update-Stand bei etlichen Opensuse 12.1-Systemen nicht mehr möglich ist, unter “System V”-Bedingungen einen fehlerfreien Shutdown hinzubringen.
Die auf einen kurzfristigen “systemd”-Umstieg ausgerichtete Politik wurde durch das aktuelle Release von Opensuse 12.2 bestätigt ( (s. die Release Notes zu Opensuse 12.2; http://www.suse.de/relnotes/i386/openSUSE/12.2/RELEASE-NOTES.en.html :
“Some desktop components depend on services provided by systemd only. So while openSUSE 12.2 still has basic support for booting a system with sysvinit as fallback, sysvinit nevertheless is considered deprecated and probably even faulty or broken in some regard.”
Genau, möchte man ergänzen – weil man halt ein
bewährtes Startup-Verfahren kurzfristig von der Wartung der Distribution ausnimmt und verkümmern läßt!
Dieser Blog-Artikel bezieht sich aber noch auf Opensuse 12.1. Nach ein paar grundsätzlichen Anmerkungen zu “systemd” aus der Anwender-Perspektive möchte ich bei aller Kritik auch konstatieren, dass “systemd” tatsächlich erhebliche Geschwindigkeitssteigerungen mit sich bringen kann. Hierzu nenne ich ein paar Zahlen für ein voll ausgestattetes Entwicklungsystem.
Ob der Zeitgewinn beim Booten auf solch speziellen Systemen allerdings all den anderen Ärger wert ist, mag der Leser selbst beurteilen.
Danach gehe ich noch kurz auf meine Shutdown-Probleme und Aspekte einer u.U. erforderlichen Reinstallation von Apache2 auf einem systemd-System ein. Diese stehen stellvertretend als Beispiele dafür, welchen Ärger man sich beim “kurzfristigen” Umstieg auf systemd einhandeln konnte.
Kritik an systemd
Wenn man beginnt, sich mit “systemd” zu beschäftigen, stößt man neben vielfachen Beschwerden frustrierter User nach dem Umstieg auf Opensuse 12.1 (u.a. natürlich in Opensuse-nahen Foren) im Internet auch auf grundsätzliche Kritik.
Kritische Anmerkungen und Gesichtspunkte bzgl. “systemd” findet man u.a. in folgendem Beitrag und der nachfolgenden Diskussion – das Ganze ist trotz persönlicher Aversionen der Autoren wirklich recht interessant zu lesen:
http://lists.debian.org/debian-devel/2011/07/msg00269.html
Etwas übersichtlicher geordnet findet man die Diskussion übrigens unter:
http://thread.gmane.org/gmane.linux.debian.devel.general/163640
Dass es tiefgehende Meinungsverschiedenheiten gab, zeigt auch eine Betrachtung der anfänglichen systemd-Diskussion für das Debian-System unter folgendem Link :
http://lwn.net/Articles/452865/
Wie schwierig und im Detail auch noch unausgegoren die Anpassung diverser Linux-System- und Server-Dienste an “systemd” voranschritt, kann man auch sehr schön an den emotionsgeladenen Dialogen zu folgendem “Bug” unter Red Hat nachvollziehen, der sich auf das Zusammenspiel von MySQL und Systemd sowie auf die Folgen eines (zu) stark parallelisierten Starts von Daemonen und Diensten bezieht:
https://bugzilla.redhat.com/show_bug.cgi?id=714426
Die dortige Diskussion vom Anfang dieses Jahres zeigt, dass der Umstieg auf “systemd”, den nach Red Hat damals auch Opensuse zu vollziehen begonnen hatte, noch nicht fertig, nicht perfekt und an der einen oder anderen Stelle eventuell auch noch nicht völlig durchdacht war. In wieweit das heute auch noch gilt, wird sich u.a. an Opensuse 12.2 erweisen.
Im Kern spricht mir aber einer der Diskussionspartner in Red Hats “bugzilla” aus dem Herzen:
Wieso opfert man eigentlich bewährte Strukturen, mit denen man Abhängigkeiten in der Startreihenfolge klar und eindeutig steuern kann, einem komplexeren System aus parallelisierten Starts an Diensten, wenn das auf einfachen Desktop-Systemen insgesamt nur wenige Sekunden Vorteil bringt?
Ich persönlich bin da konservativ: Klare Strukturen gehen mir vor Geschwindigkeit !
Faktisch war es ja auch so, dass man z.B. im Vergleich zu den Default-Einstellungen von SuSE unter den alten “System V”-Bedingungen den Startvorgang durchaus durch eine optimierte Startreihenfolge von Diensten beschleunigen konnte.
Bzgl. von Serversystemen fällt die Startzeit sowieso nicht besonders ins Gewicht. Wichtiger ist dort vielmehr die störungsfreie Uptime. Und wenn es um Ausfallsicherheit geht, muss man sich eh nach anderen Lösungen im HA-Bereich umsehen.
Instruktiv sind auch folgende
Beiträge zu den konzeptionellen Schwächen von “systemd” in einem serverähnlichen Umfeld:
http://monolight.cc/2011/05/the-systemd-fallacy/
http://www.softpanorama.info/Commercial_linuxes/Startup_and_shutdown/systemd.shtml
Nun ein paar eigene Fragen und Gedanken zu “systemd”:
1. Performance-Vorteile – für wen eigentlich?
Eine erste Fragestellung an “systemd” bzgl. der angeblich so bedeutsamen Geschwindigkeitsvorteile ergibt sich aus der täglichen Praxis für mich wie folgt:
Einfache Linux-Desktop-Systeme ohne serverähnlichen Ballast booten heute auch unter sysvinit schon sehr schnell (z.T. < 20 Sekunden) - auch auf modernen Laptops. Hier ein paar Sekunden gewinnen zu wollen, erscheint als Spielerei und Rekordjagd in einem Wettbewerb, der eigentlich von niemandem ausgerufen wurde. Auf Servern ist ein Zeitgewinn beim Booten hingegen wenig relevant. Für welche Zielgruppe soll "systemd" also eigentlich wirklich etwas bringen? Für Workstations? (Hierzu weiter unten ein paar Zahlen).
2. Verringerte Komplexität der Startup-Konfiguration ? Fehlende Posix-Konformität
Zum Zweiten finde ich auch nach mehreren Monaten Gewöhnungszeit überhaupt nicht, dass “systemd” für den normalen Linux-User/Admin einfacher zu handhaben sein soll, als das alte System V mit seinen Runlevels und der Scriptstruktur unter “/etc/init.d”. Ich finde auch nicht, dass es wirklich überschaubarer ist.
Man schaue sich die relevanten Verzeichnisse unter “/etc/systemd” und /”lib/systemd” sowie diverse Unterverzeichnisse unter “/var” einmal an. Mal ehrlich: Die Script-, Verzeichnis- und Link-Struktur unter “/etc/init.d/” wirkt fast aufgeräumter, wenn man das Prinzip mal verstanden hat.
Ja, andererseits stimmt es schon:
Man konzentriert sich unter “systemd” als Admin (gezwungenermaßen?) mehr auf Abhängigkeiten und Zielzustände des Systems und seiner Dienste und weniger auf Skript-Logik. Aber es gilt auch:
Die Anweisungen für die Konfigurationsdateien erschließen sich auch nicht unmittelbar – das mag allerdings ein Gewohnheitsproblem sein, welches sich mit der Zeit gibt.
Viel problematischer finde ich jedoch, dass dem Admin ein substanzieller Teil an Kontrolle verloren geht:
Ein Script konnte man (bei aller internen Komplexität) auf einfache Weise checken, debuggen, modfizieren, im Detail an eigene Bedürfnisse anpassen und auch erweitern. Diese Freiheit für den Shell-kundigen Anwender ist mit “systemd” plötzlich so gut wie verschwunden. Die Durchführung der begrenzten Konfigurationseinträge wird weitgehend von kompilierten Programmen übernommen.
Ich weiß – gerade nach den unter Opensuse 12.1 aufgetretenen Schwierigkeiten – wirklich nicht, ob ich das gut finden soll:
Wenn nach einem Systemupgrade oder Systemumstellungen das ganze System im Bootvorgang hängen blieb, dann konnte man früher durch Eingriffe in die Startup-Skripts und die Startreihenfolge zur Not immer etwas zur Analyse und Behebung der Schwierigkeiten tun. Unter “systemd”-Bedingungen ist das nach meinen bisherigen Erfahrungen ungleich schwieriger ! Wie gesagt:
Man hat viele kleine Monster, die ein Sysadmin aber zur Not noch einzeln zähmen konnte, durch ein zentrales Supermonster ersetzt, mit dem der Admin nur noch durch Konfigurationszeilen in Textdateien, aber nicht auf Ebene der Programmlogik kommunizieren kann.
Die insgesamt fehlende Posix-Konformität wird von den systemd-Befürwortern als “Befreiung von zu engen Grenzen” dargestellt. Man kann das aber auch als Abspaltung und Sonderweg von Linux gegenüber Unix- und BSD-Derivaten deuten – mit entsprechenden Risiken. Ganz zu schweigen von der
Tatsache, dass Ubuntu (noch) einen eigenen Weg beschreitet. In der Konsequenz werden die Hersteller von Server-SW und graphischen Oberflächen ihre Pakete wieder auf mehr Varianten an Boot/Startup-Verfahren ausrichten müssen. Ob das Linux nützt?
3. Tools für die Verwaltung von Units und Targets?
Zum Dritten fehlen mir im Alltag ordentliche graphische Verwaltungstools für die Einrichtung und das Management von systemd-“Units” und -“Targets”. Vielleicht kenne ich sie auch nur nicht – man stolpert jedenfalls nicht gerade darüber.
Auf der passiven Betrachtungsseite gibt es wenigstens das Kommando “systemadm“, das einem in strukturierter Weise eine Überblick über die laufenden Services verschafft. Viel mehr als eine einfache graphische Umsetzung dessen, was “systemctl” auf der Kommandozeile ausspuckt, plus ein paar Tasten zum Stoppen, Starten, Restarten und Reloaden eines Services, bietet es aber auch nicht.
Beim Einsatz des Befehls “systemctl” (http://en.opensuse.org/openSUSE:Systemd_tips) kommen dagegen Hacker-Gefühle aus früheren Zeiten auf … Wahrscheinlich bin ich auf meine alten Tage einfach zu faul und bequem geworden …
Was bringt systemd an Performance auf einem System mit vielen Server-Diensten ?
Ich habe in einem früheren Blog-Eintrag mal die Zeiten angegeben, die ich mit und ohne systemd beim Booten eines Systems ohne spezielle Server-Dienste gemessen hatte :
https://linux-blog.anracom.com/2012/01/08/opensuse-121-erfahrungen-mit-einer-neuinstallation/.
Für simpel gestrickte Systeme kann ich sagen:
“systemd” bringt auf meinen Opensuse 12.1-PCs ohne komplexere Serverkomponenten ca. 4 Sekunden Zeitersparnis gegenüber insgesamt ca. 14 Sekunden Bootzeit ohne systemd. Das Ergebnis (10 Sek Bootzeit) ist möglicherweise auf moderne Laptops übertragbar.
Betrachtet man einmal genauer, was auf anderen rekordverdächtigen Systemen mit superschnellen Bootzeiten eigentlich abläuft, so muss man konstatieren : Praktisch nichts, weil diese Systeme nur in einer minimalen Grundausstattung gefahren werden !
Siehe hierzu : https://bbs.archlinux.org/viewtopic.php?id=147841&p=1.
Realistisch sind die dort genannten Zahlen z.B. für SW-technisch voll ausgereizte Entwicklungs-Systeme oder Server mit komplexem Innenleben und komplexer Peripherie überhaupt nicht.
Auf einem Workstation-System von mir, dass ich als Entwicklungsystem nutze, laufen i.d.R. viele Server- und auch Desktop-Dienste mit: u.a. Apache2 mit PHP und Tomcat, MySQL mit einer Vielzahl von Datenbanken, Postgres, LDAP, Postfix, IMAP, NFS, SMB, NMB, Open-Xchange 6, KVM, VMware Workstation mit unterschiedlichen virtuellen Netzwerken und DHCP-Komponenten, NTP, Firewalldienste, SSHD, SVN, etc.. Hinzu kommen natürlich KDM/KDE.
Das System ist komplex, hat 2 Raid10-Controller mit Überwachungstools, aktivierte smartmon-Tools und eine Vielzahl von LVM-basierten Partitionen, 2 Netzwerkkarten, 2 Soundkarten, eine Nvidia-Grafikkarte, zig USB3 und USB2-Anschlüsse, ….
Da sieht die Welt dann beim Booten schon ganz anders aus – und ist von der SW-Seite her viel serverähnlicher. Es ist daher interessant, sich für so ein System mal Bootzeiten mit und ohne systemd anzusehen.
Hier die Zahlen für den Bootvorgang unter Opensuse 12.1 bis zum Abschluss der Bereitstellung aller Services und der Möglichkeit zum graphischen Login unter kdm:
- Mit systemd: 48 Sekunden (Kernel 7 Sek + userspace 41 Sek)
- Ohne systemd: > 82 Sekunden
Das sind dann doch schon erhebliche Unterschiede zwischen “System V” und “systemd” – die etwa einen Faktor 1.7 zu Gunsten von “systemd” ausmachen!
Die Zahlen muss man zudem unter dem Vorbehalt interpretieren, dass der Faktor sogar noch größer sein könnte, wenn nicht ein Teil der Dienste unter Opensuse 12.1 (wie etwa MySQL) noch nach dem alten Muster gestartet werden würde (s.u.).
Also man kann nicht sagen, dass systemd nichts bringt ! Aber für wen denn nun eigentlich?
Ob ich ein simples System innerhalb von 10 oder 14 Sekunden booten kann, ist mir ehrlich gesagt wurscht. Bei einem komplexen System, das ich jeden Tag hochfahre, einen Faktor 1.7 zu gewinnen ist mir persönlich nicht ganz egal. Aus dieser Perspektive lohnt sich das Befassen mit “systemd” schon eher. Ist also “systemd” hinsichtlich der Performance-Gewinne eigentlich für Entwicklungs- und Serversysteme gedacht?
Es liegt ja auf der Hand: Wo viele Services gestartet werden, kann man auch viel parallelisieren. Aber schnelle Bootzeiten bei einem Server? Wen interessiert das wirklich?
[Nebenbei gilt auch:
Ein ähnlich schwergewichtiges System wie das oben betrachtete bootet unter Opensuse 11.4 (allerdings ohne OX6) statt in 80 Sekunden in ca. 55 Sekunden. Dann frage ich mich schon, was hier eigentlich abläuft …. Für eine Detailanalyse hatte ich bisher leider keine Zeit.]
Systemd funktioniert unter Opensuse 12.1 eigentlich als gemischter Start von nativen “systemd”-Diensten und konventionellen “LSB”-Diensten
Bei genauerem Hinsehen muss man feststellen:
In Wirklichkeit lebten und leben wir zumindest unter Opensuse 12.1 noch mit einem Mix aus nativen “systemd”-Diensten und anderen Diensten, die praktisch über die alten und bewährten “System V”-Strukturen initialisiert werden.
Dies galt nach einem Upgrade auf Opensuse 12.1 u.a. für MySQL. Native “systemd”-Dienste erfordern ein “.service”-File. Ich habe unmittelbar nach einem Upgrade deshalb mal nach einer Datei “mysql.service” gesucht, eine solche Datei aber leider bis heute nicht gefunden.
Ich weiß nicht mehr genau, ob ein “clean install” von Opensuse 12.1 hieran etwas ändert – glaube es aber nicht. (https://bugzilla.novell.com/show_bug.cgi?id=730904).
MySQL wird zumindest nach einem Opensuse 12.1-Upgrade also nicht als nativer “systemd”-Dienst eingesetzt. Hier vermittelt statt dessen ein “Compatibility-Layer” von systemd und startet den MySQL-Service noch mittels der alten System V-Scripte.
Im “Kofler” (http://kofler.info/uploads/pdf/linux2011-update7.pdf) lesen wir hierzu entsprechend :
“Nach Fedora in Version 15 hat nun auch openSUSE sein Init-System auf Systemd umgestellt. open-SUSE 12.1 geht in diesem Punkt allerdings nicht so weit wie die aktuelle Fedora-Version 16: Sehr viele Dienste, vor allem Netzwerk-Dämonen, werden weiterhin von herkömmlichen Init-V-Scripts
gestartet. (Die Init-V-Kompatibilität von Systemd macht dies möglich.)
Eine grundsätzliche Einführung zu Systemd können Sie im bereits erwähnten Update-Kapitel zu Fedora 15 nachlesen:
http://kofler.info/uploads/pdf/linux2011-update4.pdf
Um die doch recht unübersichtlichen Konfigurationsdateien von Systemd besser zu erforschen, können Sie die grafische Benutzeroberfläche systemadm zu Hilfe nehmen. Das Programm ist im Paket systemd-gtk versteckt.
Wenn ein Dienst im Feld DESCRIPTION mit LSB bezeichnet wird, ist dies übrigens ein Hinweis darauf, dass der Prozess nicht durch ein Init-V-Script und somit nur indirekt via Systemd
gestartet wurde.“
Die kursiven Hervorhebungen habe ich vorgenommen. Siehe zum Vergleich auch :
http://forums.opensuse.org/english/get-technical-help-here/applications/475423-starting-mysql-boot-how.html
MySQL ist auf einem upgegradeten Opensuse 12.1 genau ein solcher “LSB”-Service :
Davon gibt es aber noch eine ganze Menge mehr:
Wen das Thema der sysvinit-Kompatibilität tiefer interessiert, der lese hierzu folgende, einführende Artikel :
https://wiki.archlinux.org/index.php/Systemd
http://en.opensuse.org/openSUSE:Systemd_status
https://fedoraproject.org/wiki/User:Johannbg/Features/SysVtoSystemd
Ich denke heute, dass viele Probleme, die ich beim Upgrade von 11.4 auf 12.1 erleben musste, evtl. damit zusammenhängen, dass das Umstellen auf “service”-files an der einen oder anderen Stelle beim Upgrade im Gegensatz zu einer Neuinstallation schief gegangen sein mag. Ferner mag es sein, dass der Mix aus “alten” und “neuen” Startstrukturen nicht alle Abhängigkeiten richtig auflöst.
Evtl. wurden Abhängigkeiten, die ich selbst definiert hatte oder die im Zuge der Installation von Drittprodukten festgelegt worden waren, im Upgrade nicht richtig in die neue Mischstruktur aus nativen systemd- und alten sysvinit-konfigurierten Diensten transformiert. Diese Gefahr bestand und besteht halt auf komplexen Entwickler-Systemen, auf denen lokal zu Testzwecken eine Vielzahl von Diensten mitläuft.
Deswegen war ich beim Umstieg auf Opensuse 12.1 heilfroh, dass man immer auf die alten System-V-Konstellation zurückgehen konnte. [Ich hatte deshalb auf einigen Systemen dauerhaft das Paket “sysvinit-init” installiert].
Shutdown-Probleme unter sysvinit (und systemd)
Vor einiger Zeit drängt mich aber nicht nur die Politik von SuSE sondern auch meine bessere Hälfte zum Wechsel in Richtung systemd. Ein Grund hierfür ist der, dass SuSE seit dem Erscheinen von Opensuse 12.1 immer wieder auftretende Probleme mit dem Shutdown nicht vollständig in den Griff bekommt.
Im Internet gibt es einen hübsche Liste von Fehlermeldungen, bei denen Leute nach “kernel”-, “systemd”- oder “sysvinit”-Upgrades keinen ordentlichen Shutdown mehr unter Opensuse 12.1 zustande bekommen. Man google mal mit
“Systemd Opensuse 12.1 shutdown hängt” oder “Systemd Opensuse 12.1 shutdown geht nicht mehr” oder entsprechenden englischen Suchbegriffen.
Bei manchen Opensuse-12.1-Systemen mit “systemd” tauchte das Problem zunächst unter KDE und den zugehörigen Shutdown-Tools auf, die leider nicht mit den erforderlichen, aktuellen Kommandos für eine systemd-Umgebung belegt waren. (Soviel zur einfacheren Handhabung von systemd).
Das ließ sich zumindest in meinem Fall aber leicht korrigieren. (Siehe auch :
http://forums.opensuse.org/english/get-technical-help-here/install-boot-login/469017-12-1-computer-does-not-power-down-upon-shutdown.html )
Einige Leute bekamen dann jedoch im Zuge von Opensuse-Updates ein unabhängiges, zusätzliches Problem unter “systemd” . Dieses lag dann nicht an den bekannten Änderungen – nämlich dass das Kommando “halt” als “halt -p” oder “shutdown -h now” ausgeführt
werden muss. Ich habe das auf den bei mir betroffenen Systemen abgeklappert und kontrolliert.
Da half oftmals nur ein Wechsel zurück zur klassischen “sysvinit”-Konfiguration. Unter Opensuse 12 erreicht man das – wie gesagt – schnell durch dei F5-Taste beim Booten oder die Installation des Pakets “sysvinit-init” (“it will uninstall systemd-sysvinit package”).
Die SuSE-Leute haben natürlich versucht, das Thema in seinen auftretenden Variationen zu fixen – das belegt die Kommunikation in vielen Bug-Trackern und Foren. Ich vermute aber, dass hier mehr Energie in das “systemd”-relatierte Probleme gesteckt wurde, als in das gleiche Problem unter “sysvinit”.
Denn leider und/oder interessanterweise tauchte das Thema mit der Zeit erneut auch bei Systemkonstellationen mit der klassischen “System V”-Konfiguration unter Opensuse 12 auf – also mit “sysvinit-init”. Hiervon war und bin u.a. auch ich selbst betroffen.
Ein “shutdown” (oder auch ein “Reboot”) scheitert in diesen Fällen (meist) unmittelbar nach dem “unmount” der Laufwerke. Das “halt”-Kommando wird dann nicht mehr oder nicht richtig ausgeführt. Die Maschine hängt in einem fast ganz heruntergefahrenen Zustand – nur der “Poweroff”-Vorgang findet nicht statt (trotz “halt -p”).
So habe ich bei mir drei unterschiedliche Opensuse 12.1-Systeme, bei denen sich die gesamte Installation gem. der Opensuse-Update-Repositories auf einem aktuellen Stand befindet. Alle Systeme haben KDE als graphische Oberfläche. Hardwareseitig läuft auf allen Systemen ein SATA-Raid-Controller mit je 4 SATA-Platten im Raid10 Modus. Die CPUs sind unterschiedliche Quad-Cores. Auf keinem dieser Systeme ist z.Z. ein problemfreier Shutdown unter “sysvinit-init” möglich!
Neuerdings aber sehr wohl unter “systemd”!
Auf keinem der Systeme liegt es am unvollständigen “halt”-Kommando ! Man kann in den Runlevels 1 bis 3 alle denkbaren Varianten durchführen und wird das Problem unter “sysvinit-init” dennoch nicht los.
Im Gegensatz zu den Workstation-Systemen habe ich dagegen einen Laptop (ohne Raidcontroller), bei dem es interessanterweise genau umgekehrt ist: Hier funktioniert der Shutdown problemfrei unter dem klassischen “sysvinit-init” – nicht aber unter “systemd”.
Gleicher Paketstand bei allen Systemen! Dies deutet darauf hin, dass das Thema nicht unabhängig von der Hardware-Konstellation ist. Vertrackt ist einfach, dass der Zeit-Punkt, zu dem der shutdown stirbt, vom genauen Updatezustand des Systems und auch von der Kernelversion abhängt:
Mit dem original zu Opensuse 12.1 ausgelieferten Kernel 3.1.0-1.2.1 gab und gibt es auf keinem meiner Systeme ein Problem – weder unter systemd noch unter sysvinit-init. Alle nachfolgenden von Opensuse für 12.1 angebotenen Kernelversionen führten dagegen zu Schwierigkeiten.
Diese äußern sich in Abhängigkeit vom Updatestand anderer Pakete und vom System etwas unterschiedlich. Manchmal erscheint von SuSE’s “halt”-scipt eine “missing”-Meldung zum Zustand eines der durchgeführten init.d-scripts – manchmal nicht. Auf einem der Systeme klappt ein shutdown dann, wenn zunächst ein “init 1” durchgeführt wurde, auf den anderen Systemen nicht. Zwischenzeitlich funktonierte ein Shutdown auf einem bestimmten System manchmal vom Runlevel 3 aus, aber leider nicht immer.
Ich habe weder die Zeit und die Lust, das pro System im Detail zu debuggen !
Ich halte fest:
Shutdown/Reboot-Probleme sind bei mir erst mit der Einführung von “systemd” und ab Kernel-Version 3.1.0-1.9.x aufgetreten. Alle Systeme wurden (mühsamst) von Opensuse 11.4 auf 12.1 upgegradet. Unter Opensuse 10.x bis 11.4 und unter Opensuse 12.1 mit der Kernelversion 3.1.0 gab es nie solche Probleme.
Umstieg zu systemd auf meinen vom Shutdown-Problem betroffenen Systemen – Probleme mit Apache2
Nachdem meine bessere Hälfte
es verständlicherweise leid ist, bei einem shutdown zunächst in den Runlevel 1 zu fahren, und unter “systemd” der Shutdown bei diesbezüglichen Tests kein Problem machte, unternahm ich auf zwei der Workstations einen erneuten Anlauf mit “systemd”.
Nach einigem Einsatz und im Gegensatz zu den erheblichen Problemen, die ich unmittelbar nach dem Upgrade auf Opensuse 12.1 mit systemd erlebt habe, fahren die Systeme inzwischen (allso auf dem aktuellen Update-Stand) relativ soft in den Betriebszustand mit graphischer Oberfläche hoch und runter. Diesen Zustand zu erreichen, war allerdings mit einer reihe von Schwierigkeiten verbunden. Zwei Beispiele:
- Auf einem der Systeme liefen weder der Apache2-Service noch dortige lokale OX6-Services unter “systemd” hoch. Wohl aber unter sysvinit.
- Auf einem anderen System hingegen, an dem ein USB-ISDN-Controller angeschlossen ist, der primär von einer virtuellen VMware-Instanz genutzt wird, kam das Netzwerk nicht mehr hoch.
Ich musste mich also u.a. mit Apache und “systemd” befassen. Auch hier kann man reichlich Berichte über ähnliche Erfahrungen im Internet finden. Siehe etwa:
- http://serverfault.com/questions/338048/apache-not-starting-after-upgrade-to-opensuse-12-1
- http://forums.opensuse.org/english/get-technical-help-here/applications/471026-apache2-sysvinit-vs-systemd.html
- http://forums.opensuse.org/deutsch-german/hilfe-und-helfen/installation-administration/478587-opensuse-12-2-kde-problem-mit-rc-script-beim-start.html
- http://linux.derkeiler.com/Newsgroups/alt.os.linux.suse/2012-01/msg00040.html
- http://web.archiveorange.com/archive/v/wmeLD0IkFcBxBaZfnWGC
- http://www.howtoforge.com/using-php5-fpm-with-apache2-on-opensuse-12.1
- http://web.archiveorange.com/archive/v/TDuKzP57TCmcXBqqezJd
- http://lists.opensuse.org/opensuse-factory/2012-07/msg00060.html
- http://lists.opensuse.org/archive/opensuse-de/2012-03/msg00233.html
Die netten Lösungsansätze in folgenden Artikeln funktionierten bei mir leider nicht:
http://forums.opensuse.org/english/get-technical-help-here/applications/470208-how-start-apache-service-12-1-a.html
http://www.linux-club.de/viewtopic.php?f=21&t=114874
Nach mehreren vergeblichen Versuchen, durch Änderungen der Startup-Scripts wie auch der Apache-Konfiguration etwas Funktionsfähiges zustande zu bringen, habe ich aufgegeben. Ich habe schließlich Apache2 deinstalliert, anschließend neu reinstalliert und danach wieder mit den vorherigen Konfigurationsdateien ausgestattet. Danach lief und läuft Apache2 nun auch unter “systemd”-Startbedingungen anstandslos hoch.
Im Zuge dieser De- und Re-Installations-Arbeiten gibt es mehrere Dinge zu beachten, die zwar selbstverständlich
erscheinen, die ich anderen Betroffenen dennoch ans Herz legen möchte. Dies gilt vor allem für Leute, die auf einem betroffenen System Open-Xchange 6 [OX6-CE] installiert haben:
- Zur Sicherheit die gesamten Web-Server-Verzeichnisse sichern – unter Opensuse also “/srv/www/” bzw. “/srv/www/htdocs” und zugehörige Unterverzeichnisse. Unbedingt aber das ox6-Verzeichnis unterhalb /srv/www/htdocs sichern!
- Es lohnt sich, die alten Konfigurationsdateien unter “/etc/apache2” zu sichern. Die Restaurierung des alten Apache-Zustands geht dann einfach viel schneller. Insbesondere dann, wenn man zu Testzwecken eine Reihe unterschiedlicher Domainen eingerichtet hat und Zertifikate für SSL/TLS benutzt.
- Zur Sicherheit auch alle Dateien unter “/etc/php5” oder “/etc/php” sichern. Man will seine php.ini-Konfiguration für den Apache-Server ja bei Bedarf auch restaurieren können. Echte Abhängigkeiten bestehen nur bzgl. des PHP-Moduls; aber sicher ist sicher.
Der erste Punkt ist wirklich wichtig, wenn man OX6[CE] im Schadensfall nicht neu installieren will:
Mir gingen im Zuge der Reinstallation und eines ersten fehlgeschlagenen Apache2-Starts alle OX6-Dateien verloren! Nur die – nicht die Daten anderer Verzeichnisse und Domainen! Warum habe ich bis heute nicht verstanden. Ich hätte das allerdings auch nicht für möglich gehalten. Evtl. ist das auch so ein Problem, das mit dem Mix aus nativen systemd-Diensten (hier dem neu installierten Apache2) und konverntionell gestarteten Diensten (hier dem Dienst “openxchange-groupware”) zusammenhängt? Ich weiß es nicht.
Aus der Sicherung ohne Modifikation eingespielt, nahmen die OX6-Dateien bei mir danach auf dem schließlich von “systemd” hochgefahrenen Apache2 anstandslos ihren Dienst wieder auf. Gegenüber einer potentiell erforderlichen OX6-Reinstallation und Dateneinspielung aus Sicherungen der OX6-Datenbank war das jedenfalls ein erheblicher Zeitvorteil.
Kurz noch eine Anmerkung zu dem erwähnten System mit dem Netzwerk-Problem:
Das Netzwerk fuhr auf diesem System nach der Umstellung auf “systemd” nicht mehr hoch. Damit stoppte der Bootvorgang insgesamt, weil weitere Dienste zwingend das Netzwerk benötigten. Als Ursache ließ sich nach einigem Testen ein Fehler beim Hochfahren eines problematischen ISDN-Treibers lokalisieren. Von “sysvinit” locker geschluckt, verursachte dies erhebliche Probleme unter “systemd”. Ein Neuaufsetzen der Runlevel (! Lol …) mit Hilfe von YaST – Deaktivieren des ISDN-Moduls und Eliminieren von VMware aus dem Runlevel 2 – “löste” schließlich das Problem.
Dieses “Phänomen” zeigt einerseits, wie anfällig systemd ist, und in welchem Mischzustand sich Opensuse 12.1 noch befindet.
Konsequent umsteigen
Abschließend möchte ich auch anfügen, dass man den Umstieg auf “systemd” zur Behebung von Shutdown-Problemen konsequent durchziehen sollte, wenn und nachdem man alle anderen Schwierigkeiten mit Apache und anderen Diensten unter systemd in den Griff bekommen hat.
Ich habe z.T. schlechte Erfahrungen mit abwechselnden systemd/sysvinit Boot- und Shutdownvorgängen – zumindest bei installiertem “sysvinit-init”-Paket. Da verschluckt sich beim Shutdown immer wieder mal eine Komponente. Man sollte also das Paket “systemd-sysvinit” installieren und das Paket “sysvinit-init” deinstallieren. Und danach halt versuchen, dauerhaft mit “systemd” zu leben.
Fazit
Mein Unbehagen im Zusammenhang mit “systemd” ist auf dem aktuellen Stand von Opensuse 12.1 nur gemildert, aber nicht beseitigt. Die Einführung von “systemd” im Zuge von Upgrades auf Opensue 12.1 verursachte auf etlichen Systemen erhebliche Probleme, die sich nur mit Mühe und/oder zeitweiligen Wechsel
zurück zu “sysvinit” umschiffen ließen.
Es ist allerdings spürbar, dass sich die Lage unter “systemd” und Opensuse im Zuge von Updates zu 12.1 in den letzten Monaten systematisch verbessert hat. Bei Opensuse allerdings dezidiert zu Ungunsten der Pflege und Wartung des bisherigen bewährten System-V-Initialisierungs-Verfahrens.
Wem die Performance-Vorteile eines hochparallelisierten Starts von Systemdiensten eigentlich zu Gute kommen sollen, ist mir heute viel unklarer als zum Zeitpunkt der Einführung von “systemd”. Den größten Effekt bringt “systemd” offenbar auf Systemen, bei denen viele Dienste gestartet werden, denn gerade dort ist ja auch viel parallelisierbar. Das sind aber Server oder server-ähnliche Systeme – und dort ist ein superschneller Start irrelevant.
An “systemd” führt aufgrund der Politik des Distributors trotz aller Zweifel kein Weg mehr vorbei, wenn man Linux weiter unter Opensuse nutzen will. Wirklich offenkundige Vorteile sehe ich als Anwender noch nicht. Aber vielleicht kommt das ja noch, wenn ich mich künftig noch intensiver mit “systemd” befassen muss.
Aus den bisherigen, sehr gemischten Erfahrungen ziehe ich auch folgende Konsequenz :
Ich werde Opensuse 12.2 im ersten Anlauf jedenfalls nicht durch Upgrade von 12.1, sondern von Grund auf neu installieren und danach Stück für Stück Dienste und Daten aus der alten Umgebung übernehmen. Die Politik, mehrere Versionen eines Betriebssystems parallel am Laufen zu haben, ist sowieso klug, wenn man mit kostenfreien Linux-Distributionen arbeitet. Aber das ist keine neu Erkenntnis.
Bis bald! Hoffentlich in einer besseren Opensuse 12.2-Welt!
Liste der grundlegenden Artikel von Lennart Poettering zu “systemd”
- systemd for Administrators I
- systemd for Administrators II
- systemd for Administrators III
- systemd for Administrators IV
- systemd for Administrators V
- systemd for Administrators VI
- systemd for Administrators VII
- systemd for Administrators VIII
- systemd for Administrators IX
- systemd for Administrators X
- systemd for Administrators XI
- systemd for Administrators XII
- systemd for Administrators XIII
- systemd for Administrators XIV
- systemd for Administrators XV