Ovion
Und alle Pfade, in denen config-Files angegeben sind, sind hardcoded?
fs4000
Auch unsere rc.conf wird angeblich teilweise unterstützt, wie gut das wirklich funktioniert, weiß ich nicht.
Ovion
Ich habe nur gelesen, dass es ein "Umbiegepaket" von systemd auf rc.conf existiert, dessen Verwendung allerdings nicht empfohlen wird. Wenn systemd sich an die elegante Arch-Konfigurationsweise anpasst, könnte man mal drüber nachdenken. Welche config-Files wären von einem Wechsel nach systemd denn betroffen? rc.conf, rc.local auch? Sonst?
fs4000
Die inittab noch, das müssts dann gewesen sein.
Ovion
Drei Files, auf wieviele werden die verteilt?
fs4000
Die inittab und das DAEMONS Array werden massenhaft Symlinks unter /etc/systemd/system/. Der Rest der rc.conf in die 4 Dateien von oben und rc.local gibt es nicht mehr.
Ovion
Ach du liebe Zeit, Übersicht adé.
Nix gegen performante C-Programme, aber nicht so. Da nehme ich die 2s längere Bootzeit in Kauf.
Soll man dann für jeden Daemon einen Symlink auf das Binary in besagtes Verzeichnis werfen oder wie ist das gedacht?
fs4000
Das macht systemctl für dich.
Ovion
Das hört sich dennoch stark nach Windows Autostart an. Bin noch nicht so überzeugt.
Im Prinzip werfe ich also für jeden gewünschten Daemon einen Symlink in besagtes Verzeichnis (ob jetzt selbst oder über ein Tool, müsste ja beides funktionieren, so wie ich das verstehe) und systemd geht dann hin und ruft alle Symlinks (oder sogar alle Dateien) in dem Verzeichnis beim Bootvorgang auf?
Und wie kann ich beeinflussen, in welcher Reihenfolge die Daemons gestartet werden?
fs4000
Ovion schriebund systemd geht dann hin und ruft alle Symlinks (oder sogar alle Dateien) in dem Verzeichnis beim Bootvorgang auf?
Das sind ja keine Binaries, die da verlinkt sind. Das sind Dateien mit Informationen, wie Systemd etwas starten soll.
Ovion schriebUnd wie kann ich beeinflussen, in welcher Reihenfolge die Daemons gestartet werden?
Als User schon mal gar nicht. Wenn nötig steht das in der jeweiligen .service Datei drin, meistens ist die Reihenfolge aufgrund der Socketactivation sowieso uninteressant, da alles gleichzeitig gestartet wird.
Ich glaube, du hast das Konzept hinter Systemd noch nicht verstanden/durchschaut. Es unterscheidet sich teilweise vom bisherigen SysVinit.
Ovion
Aber gibt es nicht Daemons, die erfordern, dass ein anderer Daemon läuft, bevor man sie startet? Ich meine mich daran erinnern zu können, das das bei einem Daemon angemerkt war. Würde man sich in einem solchen Fall auf die Gleichzeitigkeit verlassen oder es in die .service-Datei eintragen?
fs4000
Ja das gibt es natürlich, meistens ist die Abhängigkeit aber nur ein UNIX-Socket oder ein D-BUS Service. Systemd umgeht diese Abhängigkeiten indem es selbst diese Sockets oder Dienste öffnet und den gestarteten Programmen übergibt. Dadurch werden dann Dienste erreichbar, obwohl sie noch nicht gestartet sind. Die Kommunikation wird im Kernel gepuffert. So kann sogar ein Dienst abstürzen und trotzdem zu jedem Zeitpunkt erreichbar sein (bereits aktive Verbindungen gehen natürlich verloren).
Lennart Poettering hat einige Vorträge über Systemd gehalten in denen alle Vorteile von Systemd diskutiert werden, die solltest du dir mal ansehen.
Ovion
Habe gerade mal ein wenig reingehört. Er scheint ja große Pläne für systemd zu haben, wenn es auch noch den session-manager ersetzen soll. Was wiederum systemd für mich unattraktiver macht, weil ich befürchte, dass das gerät einfach nur ein riesiges, unübersichtliches Monstrum werden könnte. Ich mag eher den modularen Gedanken.
Und wenn es stimmt, was Lennart Poettering laut dem englischen ArchLinux-Thread zu systemd im Zusammenhang mit Arch geäußert hat ("
if you would use a proper distro..." * ), dann habe ich wenig Hoffnung, dass sich systemd in irgendeiner Form an Arch anpasst. Bin echt interessiert an genauen Messwerten von systemd und sysvinit unter Arch. Muss ich irgendwann mal durchmessen, bisher hören sich die wirklichen Vorteile nicht so an, dass die die Nachteile, mit denen sie erkauft werden, ausgleichen können.
Und die bisherigen Projekte von Herrn Poettering scheinen auch nicht gerade Begeisterungsstürme hervorzurufen (wobei ich noch nicht lange genug dabei bin, um das angemessen beurteilen zu können, kenne es nur vom Hörensagen, bin an Details aber stets interessiert).
skull-y
Ovion schriebUnd die bisherigen Projekte von Herrn Poettering scheinen auch nicht gerade Begeisterungsstürme hervorzurufen (wobei ich noch nicht lange genug dabei bin, um das angemessen beurteilen zu können, kenne es nur vom Hörensagen, bin an Details aber stets interessiert).
Ich schätze die Begeisterung wird auch nicht steigen, wenn man liest, dass es nur mit Linux funktioniert. Vom Ansatz klingt es aber interessant.
fs4000
Es baut halt nunmal auf Funktionen des Linux-Kernels wie cgroups, die andere Kernel nicht bieten. Soll Systemd deshalb darauf verzichten? Es hat niemand etwas dagegen, wenn man Systemd auf andere Systeme portiert, aber es wird schwer.
stefanhusmann
Ich habe mir systemd noch nicht näher angeschaut und habe ehrlich gesagt auch keine große Lust dazu. Man sollte meiner Meinung nach die Gewohnheiten der langjährigen Admins, die oft von propietären Unix-Systemen kommen, auch respektieren, und diese Leute beherrschen nun einmal eher einen Initskript-Ansatz als einen völlig neuen, auf den Linux-Kernel beschränkten Ansatz - mag dieser auch technisch "besser" sein. Richard Stallman hat ja seinerzeit nicht ohne Grund mit dem Gnu-Projekt den Ansatz verfolgt, ein unixoides System zu schreiben, weil er hoffte - und da lag er ja auch wohl richtig - damit kämen die meisten am besten zurecht.
Was mich gegenüber systemd skeptisch bleiben lässt, ist die fehlende Neigung zur Nachhaltigkeit, die man bei Projekten aus der Richtung des Herrn Poettering hört. In vier Monaten fällt ihm vielleicht noch was viel Tolleres ein, das wieder ganz anders ist.
Ovion
Ließen sich nicht die Initskripte durch C-Programme ersetzen? Oder muss man jene häufiger mal editieren? Wenn C-Programme tatsächlich eine soviel bessere Performance haben als die Initskripte könnte man doch die Endkomponente ersetzen und trotzdem den Arch-Konfigurationsstil aufrechterhalten. Ob die Daemons jetzt aus einem Ordner oder aus einem Array in der rc.conf stammen, dürfte ja ziemlich egal sein. Ist der Gedanke realistisch oder völlig abwegig? Dann könnte man evtl. sogar den Parallelisierungsunterbau von systemd unter die aktuelle Oberfläche setzen. Solange die Userschnittstelle sich nicht groß verändert bzw. so unübersichtlich wird, kann man es ja mal in Erwägung ziehen. Oder gibt es abseits davon noch Nachteile von systemd? Nur so eine Idee von jemandem, der keine Ahnung von Bootsystemen hat (aber gerne dazulernt 😉).
Edit: In welchen Szenarien müsste man eigentlich in den Initskripten schreiben?
fs4000
Ovion schriebIn welchen Szenarien müsste man eigentlich in den Initskripten schreiben?
In keinen, da sie sowieso überschrieben werden. Unsere Initskripte lassen sich per Hooks erweitern.
Systemd ersetzt nicht jedes Skript durch ein Programm. Für die ganzen Dienste gibt es spezielle Dateien, mit denen man ziemlich genau dasselbe anstellen kann, wie mit den rc.d-Skripten, nur dass sie nicht von Bash interpretiert werden und weitaus keinen so komplexen Interpreter brauchen.
Creshal
> In welchen Szenarien müsste man eigentlich in den Initskripten schreiben?
Wenn du irgendwelche Bootprobleme von Hand debuggen "musst" (willst).
Kommt meiner Erfahrung nach ungefähr einmal alle fünf Jahre vor, wenn überhaupt…
> Für die ganzen Dienste gibt es spezielle Dateien, mit denen man ziemlich genau dasselbe anstellen kann,
> wie mit den rc.d-Skripten, nur dass sie nicht von Bash interpretiert werden und weitaus keinen so komplexen Interpreter brauchen.
Was ein ziemlich zweischneidiges Schwert ist – der Vorteil ist, dass Maintainer nicht mehr Programmlogik in das Initscript stopfen. Der Nachteil ist, dass ich als Maintainer nicht mehr Programmlogik in das Initscript stopfen kann. 🙂
In vielen Fällen wirds wohl darauf hinauslaufen, dass die Bash-Logik in irgendein Wrapperscript ausgelagert wird, und die Systemd-Unit nur den Wrapper ausführt…
Ovion
Sehe mir gerade noch etwas dazu an und da fällt mir folgendes ein: systemd handhabt es ja so, dass ein Daemon terminiert wird, wenn er für eine gewisse Zeit nicht gebraucht wird, und startet wieder, sobald er gebraucht wird. Welchen Vorteil hat das?
Mein Tipp wäre, es spart Arbeitsspeicher, CPU-Last verursacht er ja nicht, wenn er schläft. Aber wenn man nicht gerade um jedes KB RAM kämpfen muss, ist es dann nicht sogar so, dass das starten des Dienstes wiederum Last erzeugt und somit das System verlangsamt (auch wenn man das nicht merkt, weil es so wenig ist), als wenn man den Daemon einfach aus dem RAM aufweckt?