Eigentlich wollte man systemd (Init-Prozess) bereits in openSUSE 11.4 standardmäßig installieren, musste aber aus Zeitgründen und wegen Inkompatibilität aufgeschoben werden. Frederic Crozat (Novell/Attachmate) will die Integration von systemd voranbringen und zwischen der openSUSE-Community, Entwickler, Paketbauer und dem Upstream-Projekt systemd vermitteln. Er ist auch der Ansprechpartner für jede erdenkliche Hilfe zu systemd.
Der Plan sieht wie folgt aus:
- Phase 1: Probleme mit systemd aufspüren. systemd-Paket installieren und per Kernel-Boot-Kommandozeile „init=/bin/systemd“ manuell booten. Um alle Konfigurationsprobleme zu finden, sollte man die systemd-Statusseite konsultieren, um ein Bugreport an die systemd-Betreuer zu senden. Damit wollen die systemd-Betreuer des openSUSE-Projektes sicher gehen, dass es keine Regressionen zwischen der noch SysVinit und systemd gibt.
- Phase 2: Das systemd-Paket wird standardmäßig installiert und ersetzt dadurch SysVinit.
- Phase 3: Bereitstellung von systemd-Unit-Dateien, um SysVinit-Skripte auszutauschen. Das ist eine gewaltige Aufgabe und wird womöglich nicht vor openSUSE 12.1 abgeschlossen sein, was aber mit Hilfe von den jeweiligen Paketbauern doch gelingen sollte (Im Idealfall sollte jeder Paketbauer in der Lage sein eine systemd-Unit-Datei zu erstellen). Es wird auch in weitere Meilensteine aufgeteilt:
- Phase 3.1: GNOME und KDE Live-CDs sollen nur systemd (ohne SysVinit) verwenden
- Phase 3.2: Von einem GNOME und KDE Live-CD via Live-Installer installiertes System. (Zusätzliche Pfade im Live-Installer soll getestet werden)
- Phase 3.3: Von einer Installations-DVD sollte nur systemd installiert werden
Mehr Informationen zu systemd und wie man die Konvertierung von SysVinit durchführt:
Teil 1: http://0pointer.de/blog/projects/systemd-for-admins-1.html
Teil 2: http://0pointer.de/blog/projects/systemd-for-admins-2.html
Teil 3: http://0pointer.de/blog/projects/systemd-for-admins-3.html
Teil 4: http://0pointer.de/blog/projects/systemd-for-admins-4.html
Teil 5: http://0pointer.de/blog/projects/three-levels-of-off
Teil 6: http://0pointer.de/blog/projects/changing-roots.html
Teil 7: http://0pointer.de/blog/projects/blame-game.html
Teil 8: http://0pointer.de/blog/projects/the-new-configuration-files
Tipp: Bei Teil 3 handelt es sich ausschließlich um die Konvertierung von SysVinit-Skripte zu systemd-Unit-Dateien.
Wer denoch Hilfe sucht oder auch mithelfen möchte, kann über die openSUSE-Factory-Mailingliste oder im IRC-Kanal #opensuse-factory konsultieren.
Quelle: http://blog.crozat.net/2011/06/road-to-systemd-for-opensuse-121.html
Als Maintainer der Packaging-Skripte in der ATI-Catalyst-Reihe für openSUSE muss ich mich in nächster Zeit mit systemd beschäftigen, um das Init-Rebuild-Skript wie auch das ATI-External-Events-Daemon von SysVinit nach systemd zu konvertieren, um weiterhin von der automatischen Kompilierung bzw. dem Neuladen des fglrx-Kernelmodules beim Systemstart zu nutzen.
Ich hab bei OpenSuse 11.4 .. systemd installiert.. mir ist dabei nur aufgefallen das bei powertop recht viele interrups angezeigt werden….bei multicore computern
vieleicht ist das ja bei 12.1 anders.
grüße Johnny
Hallo Johnny,
ja, deswegen funktioniert es noch nicht wirklich unter openSUSE 11.4. Aber man arbeitet daran, dass es mit openSUSE 12.1 funktionieren wird.
Gruß
Sebastian
Ich hatte auch bei 11.4 (beta) systemd installiert, war dann aber von der Geschwindigkeit enttäuscht und bin dann beim stabilen SysinitV geblieben. (Hatte hier auch meine Erfahrungen gepostet). Aber ich denke, dass systemd doch die Zukunft ist und wenn dann auch noch der Window-Manager und andere Tasks gesteuert werden sollen, dann klingt das schon mal nicht schlecht. Ich hoffe, dass systemd in 12.1 stabil und rund läuft. In Fedora tut es das schon. Etwas umdenken ist schon erforderlich, aber auf Kompatibilität wurde geachtet, ein init 3 geht immer noch
Muss jetzt nur noch meinen Kernel-Lieblingshacker Con Kolvias („BFS Erzeuger“) überzeugen, dass eine volle CGroups Unterstützung eingebaut wird
Und Dir Sebastian wünsche ich viel Spass mit den neuen systemd Scripten
CU Mike
Hallo nochmal,
ich bin froh, dass man nicht mit aller Gewalt systemd in openSUSE 11.4 eingeführt hat, sonst wären heute noch ziemlich böse Stimmen von der openSUSE-Community gefallen.
systemd verspricht für die Zukunft interessant zu werden. Ich habe in der VirtualBox openSUSE 12.1 installiert und es probeweise per systemd gestartet. Es ist gefühlt schneller als SysVinit. Es verspricht interessant zu werden, da auch die Dienste erst dann gestartet werden, wenn diese benötigt werden. Das spart unheimlich Ressourcen.
Ich weiß nicht, inwiefern sein BFS-Scheduler mit dem CGroup gegenüber dem CFS-Scheduler kompatibel ist.
Gruß
Sebastian
Hi Sebastian,
ja, die Verzögerung von systemd waren schon o.k.. So hatte OpenSuse 11.4 nicht viel Neues zu bieten, ist dafür aber solide. (Sonst wäre das ja schon 12.1 gewesen )
Hatte schon mit Con bzgl. BFS und cgroups gemailt, wird aber wohl ein grosser Umbau notwendig sein, um das in den BFS zu integrieren und dazu hatte er bis jetzt noch keine Veranlassung. Aber systemd benötigt das eben. Und ich muss zugeben, dass ich mit dem BFS und dem BFQ im Kernel (genauer gesagt dem ZEN-Kernel) ein wirklich gut laufendes Linux hier habe, das ich ungern eintauschen würde. Aber wahrscheinlich wird mit dem systemd der Druck höher, vor allem wenn auch andere Distros (weiß aber nicht, ob Ubuntu das upstart auch umstellt) umsteigen.
Meiner Meinung nach werden aber bei systemd die Dienste prinzipiell einfach nur gestartet, ohne Kontrolle der Abhängigkeiten. Systemd „faked“ die Voraussetzungen, sprich die Sockets etc, so dass alles parallel gestartet werden kann. Wenn also die alten sysinit scripte genutzt werden, werden die Dienste dann auch gestartet, wenn sie nicht genutzt werden, so wie bisher. Aber mit neuen Scripten muss z.B. der cupsd nicht bei jedem Start automatisch starten, nur eben wenn jemand wirklich drucken will. Und für die Zukunft könnte systemd eine Art Prioritätsscheduler sein, so wie ulatency.
Gebe Dir also auch dies Mal Recht
Die Zukunft von (Opensuse) Linux sieht interessant aus Aber die Hardwarewelt verändert sich auch rasant, mal sehen wie Suse da aussieht.
Aber bis 12.1 ist es ja noch ein Stück.
CU Mike
PS: Wie sieht es eigentlich mit BTRFS und 12.1 aus, ist da schon eine Entscheidung gefallen?
Hi Mike,
wenigstens weiß er schon mal von der Existenz von systemd Bescheid und das dieses eben cgroups benötigt. Mal schauen, wann er das implementiert. Für Fedora ist es da bereits schon zu spät, weil die neuste Fedora-Version systemd voraussetzt. Aber spätestens mit openSUSE 12.1 im November sollte man schon cgroups in BFS implementiert haben, wenn da nicht schon der Druck von der Fedora-Community kommt.
Zu btrfs:
In openSUSE 12.1 Milestone 1 kannst du bei einer nagelneuen Platte oder eine Partition mit btrfs per Checkbox als Standard formatieren lassen.
Siehe auch die Diskussion um btrfs: http://lists.opensuse.org/opensuse-factory/2011-03/msg00424.html
Gruß
Sebastian
Help!
I replaced SuSE 11.3 by 12.1 and now face a problem with the new systemd feature. First off all I’m no Linux expert and usually follow just cookbook recipes when digging into the system.
I used to start a specific perl programm by a line in /etc/inittab:
DX:35:respawn:/bin/su -c „/usr/bin/perl -w /spider/perl/cluster.pl“ sysop >/dev/tty11
This worked fine and kept cluster.pl going and restarted it when ever it was shutdown.
Now with Suse 12.1 this line in inittab does nothing anymore. Guess it has to be replaced
somehow due to the introduction of systemd?
Please provide some step by step recipe on how to get it going again.
Thanks, Klaus
Hi Klaus,
i played a bit around with systemd. Have you tried as root
systemctl enable
then you can tab and get a full list of services you can enable. Maybe you are lucky and your service is listed else i would modify an existing initscript with your executable and this will be recognised by systemd after enabling it with systemctl.
Greetings
Peter,
inzwischen habe ich auch gerafft, dass hier Deutsch gesprochen wird…
Habe mit Hilfe eines Bekannten jetzt eine Lösung gefunden. Allerdings funktioniert die Kontrollausgabe nach tty11 noch immer nicht, cluster.pl wird aber jetzt beim Booten gestartet und auch immer wieder erneut hochgefahren, wenn es abstürzt oder sonst was passiert.
So geht es:
Die Lösung für den Autostart und am Leben halten:
Das angehängte File „dxcluster.service“ (könnte man natürlich anders nennen) muß man in das Verzeichnis
/etc/systemd/system/getty.target.wants
(Wahrscheinlich geht auch ein anderes Verzeichnis in /etc/systemd/system)
kopieren und anschießend
# systemctl daemon-reload
# systemctl start dxcluster.service
ausführen und es sollte gehen.
Anstatt der beiden Befehle geht natürlich auch ein Neustart
Ich habe in dem service file eine (veränderbare) Wartezeit von 5 Sekunden eingebaut, damit der Cluster genug Zeit hat, alle Verbindungen abzubauen.
Die Hinweise in deiner letzten Mail haben mir die letzten Fragen beantwortet.
Jetzt bleibt noch herauszufinden, wie das mit >/dev/tty11 geht.
Gruss, Klaus
Oh, hate den Inhalt von dem service file nicht eingefügt. Falls es jemand interessiert, so sieht das aus:
[Unit]
Description=DXCluster
After=syslog.target
[Service]
ExecStart=/bin/su – sysop -c „/usr/bin/perl -w /spider/perl/cluster.pl“ > /dev/tty11 &
Restart=always
RestartSec=5
[Install]
WantedBy=multi-user.target
Jo hallo Klaus,
ich hab mir auch ein eigenes Skript gemacht. Aber wie gesagt ein init.d Skript und
man kann das ebenfalls mit systemctl enable initskriptname.service aktivieren.
nur so um zu testen wie schlau systemd ist.
Grüße Peter