Ich bin keiner der Entwickler, ich kann nicht sagen wie man zu diesem Entschluss gekommen ist. Es wird jedenfalls versucht alles möglichst kompatibel zu systemd zu halten. Evtl. um zukünftig einfacher wechseln zu können, wegen der Vereinheitlichung der Konfiguration der Distributionen ... oder weil Lennart sie alle unter seiner Kontrolle hat (das wars dann mit World Domination)
fs4000 schriebOh weh, ihr habt mich falsch verstanden. Es wird lediglich die Empfehlung ausgesprochen, die Konfiguration nach dem Systemd-Schema zu erstellen. In der rc.conf werden weiter alle Optionen verfügbar sein, nur müssen sie jetzt manuell aus der Manpage rausgesucht und hinzugefügt werden
Ich habe nun auch Toms Kommentar in arch-general gelesen. Trotzdem: Für mich ist das eindeutig das Ende von initscripts+sysvinit unter Archlinux. Punkt.
GerBra schriebIch habe nun auch Toms Kommentar in arch-general gelesen. Trotzdem: Für mich ist das eindeutig das Ende von initscripts+sysvinit unter Archlinux. Punkt.
Das liest sich in der Tat so. Das mit der Abwärtskompatiblität hört sich doch arg nach Höflichkeitsfloskeln an.

Wie hat man SysVinit eigentlich die rc.conf beigebogen? Das ist doch auch nicht Standard, oder irre ich da?
init (aus sysvinit) holt sich alles was es machen kann aus /etc/inittab. Dort dann rc, rs, rm. Die rc.* scripts die aufgerufe werden sind Archspezifisch.
(Man kann dort natürlich auch eigene aufrufen, etwas was ich mir gerade überlege; v.a. wenn man das init aus sysvinit nicht gleich über Bord schmeißen will)

Die Alternativen sehen IMHO eher schlecht aus bzw. scheinen seit Jahren nicht mehr weiterentwickelt zu werden.
Ich hab gestern mir mal verschiedenes angeschaut, daß meiste ist recht tot…

init-ng hätte ich ggf. versucht (werde ich auch mal), aber die stable ist von 2010, die git läßt sich bei mir icht bauen. Sieht auch tot aus. Dito irgedwie für runit. cinit, einit und minit dito.


Ich sehe wirklich nur upstart oder systemd als die, welche wenigstens aktiv entwickelt werden. Wenn es nach der Beschreibung geht werde ich wohl erstmal upstart antesten. OpenRC wäre noch eine Alternative.
Oder halt initscripts einfach weiternutzen bzw. sich was eigenes schreiben…
Und die rc.*-scripts lesen aus der rc.conf?
Ja, das sind einfache Bash-Skripte(/etc/rc.sysinit, schau sie dir ruhig an), die rc.conf dort per Punkt(.) eingelesen, die nötigen Variablen/Werte verarbeitet. Der Vorgang ist halt mittlerweile so komplex das IMHO bashskript eher hinderlich wird. Hier wäre wohl ruby oder python eine bessere Basis (mit allen Vorteile dieser "Hochsprachen", selbst wenn der Interpreter mehr Resourcen bräuchte (Wenn man bei einer Interpreter-Sprache bleiben will, wo ich eher einen Vorteil sehe - zumidest für mich nicht C/C++-Mächtigen).
Also mal als Nutzer von systemd:

Vorteile:
  • wirklich schnelles ausschalten
  • gefühlt leicht schnelleres booten / jedenfalls für mich und nur bis multi-user-target aber ohne X. was aber auch daran liegen kann das außer fscheck keine Meldunge kommen bis VT1 auf meinen login wartet. und im hintergrund dann ja noch einiges passiert.
  • bevor ich ein startscript für sysvinit schreiben müsste mach ich doch lieber nen ca 6 Zeiler bei systemd dort lassen sich auch:
  • abhängigkeiten in den service-files festlegen
  • statusabfragen mit systemd sind hübsch
Nachteile:
  • der Logger ist fürn Po, hab ihn auf syslog umgebogen
  • arg gewöhnungsbedürfig das ganze
  • sehr forciert
  • schlecht dokumentiert
Nachtrag:
Ich hab aus irgendeinem Grund mit systemd nen anderen dpi-wert als mit sysvinit ^^
mannohneschuh schriebwas aber auch daran liegen kann das außer fscheck keine Meldunge kommen bis VT1 auf meinen login wartet
Schade, ich fand es immer ganz nett zu sehen, wie weit das System gerade ist (was aber bei parallelem Start von allem und jedem in der Tat schwierig wird mitsinnvollen Meldungen.
mannohneschuh schrieb statusabfragen mit systemd sind hübsch
[...]
sehr forciert
Könntest du diese beiden Punkte noch etwas näher ausführen?
mannohneschuh schrieb arg gewöhnungsbedürfig das ganze
@mannohneschuh & alle anderen
Aber noch durchgehend File-basiert in der Konfiguration? Ich denke gerade darüber nach, ob es Sinn macht, mir eine "eigene" rc.conf zu nehmen und die (bspw.) per Batchskript auszulesen und in die einzelnen Teildateien schreiben zu lassen (zwar nicht während des Boots, aber immer dann, wenn ich Änderungen vornehmen möchte), quasi so, wie die Initskripte es aktuell machen, nur halt nicht im Initsystem, sondern extern, um nicht mit den einzelnen systemd-Dateien arbeiten zu müssen, sondern noch immer eine zentrale Konfigurationsstelle zu haben.
Ist aktuell nur so eine Idee, ist das ein realistischer Ansatz?

@GerBra
Der Lua-Interpreter soll ziemlich klein und schnell sein. 😉
>Schade, ich fand es immer ganz nett zu sehen, wie weit das System gerade ist
Lässt sich einstellen, systemd hält sich an das "quiet"-Flag vom Kernel. Wenn du das im Bootloader setzt, siehst du halt nur Fehlermeldungen.
Ah, ok, danke! Das Quiet-Flag könnte ich im Betrieb einfach ändern (einfach die entsprechende Zeile in der Datei "namevergessen" abändern, richtig)?
Ovion schrieb
mannohneschuh schrieb statusabfragen mit systemd sind hübsch
[...]
sehr forciert 
$ systemctl status tor.service
tor.service - Anonymizing Overlay Network
	  Loaded: loaded (/usr/lib/systemd/system/tor.service; enabled)
	  Active: active (running) since Sun, 22 Jul 2012 00:27:41 +0200 ## wobei 'active (running)'  grün geschrieben ist hübsch :)
	 Process: 474 ExecStart=/usr/bin/tor -f $TOR_CONF $TOR_ARGS (code=exited, status=0/SUCCESS)
	Main PID: 500 (tor)
	  CGroup: name=systemd:/system/tor.service
		  └ 500 /usr/bin/tor -f /etc/tor/torrc --quiet
Ovion schrieb
mannohneschuh schrieb [...]
sehr forciert
naja irgendwie bewegt sich sogar arch zwangsläufig darauf zu… und wir sehen ja wohin das führt.
Ovion schrieb
mannohneschuh schrieb arg gewöhnungsbedürfig das ganze
@mannohneschuh & alle anderen
Aber noch durchgehend File-basiert in der Konfiguration? Ich denke gerade darüber nach, ob es Sinn macht, mir eine "eigene" rc.conf zu nehmen und die (bspw.) per Batchskript auszulesen und in die einzelnen Teildateien schreiben zu lassen (zwar nicht während des Boots, aber immer dann, wenn ich Änderungen vornehmen möchte), quasi so, wie die Initskripte es aktuell machen, nur halt nicht im Initsystem, sondern extern, um nicht mit den einzelnen systemd-Dateien arbeiten zu müssen, sondern noch immer eine zentrale Konfigurationsstelle zu haben.
Ist aktuell nur so eine Idee, ist das ein realistischer Ansatz?
klingt irgendwie komisch, aber wenns dir spass macht leg los. Wirst bestimmt irgendwas bei lernen.

Ach und da fällt mir was ein was mich gewaltig nervt:
man kann mit 'systemctl reboot' oder 'systemctl poweroff' den Rechner abschalten obwohl root (zB auf nem anderen VT) angemeldet ist.
Ach, das meintest du mit forciert. Manchmal ist meine Leitung auch über drei Umwege gelegt. *rolleyes*
mannohneschuh schriebklingt irgendwie komisch, aber wenns dir spass macht leg los. Wirst bestimmt irgendwas bei lernen.
Inwiefern komisch? Bin stets daran interessiert, konzepitionelle Fehler vor der Umsetzung zu bereinigen. 😉 Und wenn's überhaupt keinen Sinn macht, bin ich an der Info auch stets interessiert, zum lernen habe ich noch genug Projekte...
mannohneschuh schrieb Ach und da fällt mir was ein was mich gewaltig nervt:
man kann mit 'systemctl reboot' oder 'systemctl poweroff' den Rechner abschalten obwohl root (zB auf nem anderen VT) angemeldet ist.
Ging das unter SysVinit nicht? Ich meine, root (der runterfahrende root) ist Gott und Gott darf alles (wobei ein Hinweis auf noch angemeldete Nutzer tatsächlich nett wäre).
Ovion schriebAch, das meintest du mit forciert. Manchmal ist meine Leitung auch über drei Umwege gelegt. *rolleyes*
mannohneschuh schriebklingt irgendwie komisch, aber wenns dir spass macht leg los. Wirst bestimmt irgendwas bei lernen.
Inwiefern komisch? Bin stets daran interessiert, konzepitionelle Fehler vor der Umsetzung zu bereinigen. 😉 Und wenn's überhaupt keinen Sinn macht, bin ich an der Info auch stets interessiert, zum lernen habe ich noch genug Projekte...
Naja ob du dir nun die einzelnen (von systemd verlangten/bei sysvinit optionalen) Dateieen einmal anlegst und bei bedarf änderst und dir merkst was wo steht, oder das per skript aus einer Datei ziehst und in diese Dateien schreibst… ich finds komisch es auf zweite weise zu machen wenn doch die rc.conf genau das ist.
Ovion schrieb
mannohneschuh schrieb Ach und da fällt mir was ein was mich gewaltig nervt:
man kann mit 'systemctl reboot' oder 'systemctl poweroff' den Rechner abschalten obwohl root (zB auf nem anderen VT) angemeldet ist.
Ging das unter SysVinit nicht? Ich meine, root (der runterfahrende root) ist Gott und Gott darf alles (wobei ein Hinweis auf noch angemeldete Nutzer tatsächlich nett wäre).
Nein, nein. 'systemctl poweroff' kann der normale user aufrufen. die dbus-Variante die ich normalerweise einsetze scheitert zB an einem eingeloggten root.
In der Einstellungsdatei deines jeweiligen Bootloaders, ja.
Ja, ich erinnere mich.^^

Danke, ihr beiden!
Inwiefern ist der Logger fürn Po? Abgesehen von der Tatsache, dass er definitiv nicht in ein Init-/Servicemanagement-System gehört, find ich ihn eigentlich recht gelungen.

Dass systemd schlecht dokumentiert ist, finde ich eigentlich auch mehr oder weniger gelogen. 🙂
runiq schriebInwiefern ist der Logger fürn Po? Abgesehen von der Tatsache, dass er definitiv nicht in ein Init-/Servicemanagement-System gehört, find ich ihn eigentlich recht gelungen.

Dass systemd schlecht dokumentiert ist, finde ich eigentlich auch mehr oder weniger gelogen. 🙂
Dann habe ich wohl den logger falsch verstanden. Aber mich störte zB das ich nichts in den logfiles unter /var/log/ fand. Daher die Änderung damit syslog ieder seinen Dienst tut. Und unnötig ist er auch in einem init-system.

Falls die Dokumentation besser geworden ist werde ich mich mal auf die Suche begeben und sie mir erneut ansehen. als ich systemd zum ersten mal einrichtete wars ziemlich mau, gerade an den Stellen wo ich mehr infos brauchte.
runiq schriebInwiefern ist der Logger fürn Po? Abgesehen von der Tatsache, dass er definitiv nicht in ein Init-/Servicemanagement-System gehört, […]
Nein, nein, du verwechselst da was SysVinit ist ein Init-/Servicemanagement-System, systemd ist eine fette, behäbige, Eier legende Wollmilchsau, die sich mit dem gesamten Gewicht bequem und breit auf das komplette System setzt, und nie mehr weg zu bekommen ist.
Dirk Sohler schriebNein, nein, du verwechselst da was SysVinit ist ein Init-/Servicemanagement-System, systemd ist eine fette, behäbige, Eier legende Wollmilchsau, die sich mit dem gesamten Gewicht bequem und breit auf das komplette System setzt, und nie mehr weg zu bekommen ist.
Das ist jetzt nicht besonders nett, aber doch recht treffend formuliert...

Warum verdammt müssen die da einen eigenen Logger mit einbauen? Der gehört in ein Init-/Servicemanagementsystem einfach nicht rein, genauso, wie man Initsystem und Sessionmanagement meines Erachtens in zwei Komponenten auftrennen sollte. Haben die nicht auch einen inetd-Klon eingebaut, obwohl inetd selbst wunderbar funktioniert?
Das Journal ist Mist. Jedes mal wenn der Rechner abstürzt (ja im Prinzip ein Problem für sich) liegen da seltsame Dateien in /var/log/journal/... und das ganze Teil ist ultra lahm geworden, weil er diesen Müll auch inspiziert.