| View previous topic :: View next topic |
| Author |
Message |
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
 Posted: Mon Jan 06, 2014 3:10 pm Post subject: |
 |
|
| schmidicom wrote: | | .maverick wrote: | | Die Notwendigkeit von (echten) Skripten um Dämonen zu starten hat sich mir eh nie so richtig erschlossen. |
Eine echte Notwendigkeit gibt/gab es dafür offensichtlich nicht/nie. Nur hatte man unter init eben keine andere Möglichkeit als für jeden Hintergrunddienst ein regelrecht monströses Scriptgedöns hochzuziehen, wodurch es im Fehlerfall für viele Linuxbenutzer stellenweise fast unmöglich wurde den ganzen Quatsch nachzuvollziehen. |
Erstens mal ist Starten von Daemonen die allerkleinste Aufgabe von Init-Systemen (auch wenn Poettering das anders hinstellen will, weil das die einzige Aufgabe ist, die systemd einigermaßen gut hinbekommt, während es bei so ziemlich allen anderen Aufgaben versagt.)
Zweitens: Bei einem Kommando (start-stop-daemon ...) von "monströsen Scriptgedöns" zu sprechen, ist schon merkwürdig, zumal Du bei systemd da mindestens 3-4 Zeilen benötigst (ExecStart, ExecReload, ExeecStop, KillSigne, Type, PIDFile usw. usf.), von dem ganzen systemd-Drumrum (unit, service, install-Sections) mal ganz abgesehen. Das ist bei systemd also im günstigsten Fall nicht deutlich mehr aufwändig als bei openrc.
Was aber schlimmer ist: Debuggen ist mit systemd praktisch unmöglich. Während es beim Parallelstart mit openrc, wie Du sagst, bei falschen Abhängigkeiten mal zu "zufälligen" Fehlern kommen kann, ist das bei systemd Teil des Konzepts - nur dass Du eben, wenn Du reproduzierbares Verhalten brauchst, nicht die Möglichkeit hast, alles sequentiell zu starten. Schlimmer noch: Wenn Du einen Daemon hast, der das System aufhängt (was in der Praxis durchaus vorkommt: der neue Sound-/Graphic-/Druckertreiber kabbelt sich irgendwie mit den Interrupts mit einem anderen Treiber; u.U. nur manchmal, wenn beide parallel gestartet werden), hast Du nun nicht mehr die Möglichkeit bei jedem Kommando "starten/überspringen/Abbruch" auszuführen, sondern es wird zwangsläufig alles gestartet, so dass Du also im "typischen" Fehlerfall nur noch von einer Rettungs-CD booten kannst (falls Du eine zur Hand hast, und das System einen CD-Leser hat und davon booten kann... durchaus nicht selbstverständlich und schon gar nicht praktisch), und dann musst Du von Hand mit binärer Suche Dienste aktivieren und deaktivieren und ständig neu booten, um herauszufinden, welcher Dienst denn nun den Absturz verursacht. Bei openrc hingegen: "I" "Y" "Y" "Y" "Y" "Y" "Y" (Absturz) - aha, dieses init-file ist die Ursache. |
|
| Back to top |
|
 |
frostschutz
Advocate
Joined: 22 Feb 2005
Posts: 2977
Location: Germany
|
| Posted: Mon Jan 06, 2014 5:32 pm Post subject: |
|
|
| Code: | $ zgrep -i cgroup /proc/config.gz
# CONFIG_CGROUPS is not set |
Aber ich fürchte daß das ne Alterungserscheinung ist. Bei systemd, btrfs und zfs mache ich ja auch nicht mit. pam ist auch deaktiviert. pulseaudio ebenso Fehlanzeige.
Mit Gentoo kann mans ja machen.
EDIT: Sorry, seh gerade erst daß es ja nur noch um Bootgeschwindigkeit geht. Wäre vielleicht was für ein eigenes Thema. |
|
| Back to top |
|
|
schmidicom
Veteran
Joined: 09 Mar 2006
Posts: 1923
Location: Schweiz
|
| Posted: Mon Jan 06, 2014 5:48 pm Post subject: |
|
|
Also mit der Interaktivität von OpenRC würde ich jetzt nicht unbedingt "Werbung" machen. Erstens ist diese standardmäßig deaktiviert und muss somit vor dem Crash manuell aktiviert werden (kann man auch nachträglich per Live-CD, aber das macht die Sache auch nicht besser), und zweitens ist diese aus gutem Grund standardmäßig deaktiviert denn sie ist mit machen Dingen (plymouth hat z.B. wenig Freude daran) inkompatibel. Dazu kommt das in so einem Scenario alle Treiber (PS2, USB oder noch schlimmer Bluetooth) für die Tastatur schon geladen sein und laufen müssen um interaktiv zu werden, was je nach Kernelkonfiguration auch nicht immer rechtzeitig der Fall ist.
Wenn es unter systemd ein Hintergrunddienst trotz cgroups schafft das ganze System in die Knie zu zwingen kann man durch den Kernelparameter "systemd.unit=rescue.target" dafür sorgen das systemd einen in eine Notfallconsole schickt von wo aus das Problem behoben werden kann. Und selbst wenn das nicht mehr geht kann man mit einer Live-CD (vorzugsweise eine mit systemd wegen journald) immer noch die symlinks in /etc/systemd/system entfernen was aber dank der ersten Lösung eigentlich nicht nötig sein sollte.
_________________
Lenovo - ThinkPad P16s Gen 2 - 21K9CTO1WW |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Mon Jan 06, 2014 9:14 pm Post subject: |
|
|
| schmidicom wrote: | | Interaktivität von OpenRC |
Spar Dir Deine Fehlinformations-Kampagne. Deine an den Haaren herbeigezogenen "Argumente" sind sofort als hanebüchener Unsinn enttarnbar.
Dass Du dem ev. nichtinformierten Leser vorzumachen versuchst, man müsste den interaktiven Modus mit Rettungs-CD toggeln ist schon ein starkes Stück!
Natürlich lässt man den Modus normalerweise an!
| Quote: | | aus gutem Grund standardmäßig deaktiviert |
Es gibt genau einen guten Grund ihn deaktiviert zu lassen: Wenn man aus Sicherheitsgründen verhindern will, dass ein Nicht-Root-User sehr einfach durch Neubooten gewisse Dienste deaktivieren kann. Dies macht man aber natürlich ohnehin nur auf einem vorher gut getesteten System (bei dem man deswegen den interaktiven Modus auch garantiert nicht braucht).
Alle anderen "Gründe" sind reiner FUD:
| Quote: | | plymouth hat z.B. wenig Freude daran |
Ein Eyecandy-Tool, das mit systemd gar keine vernünftige Ausgabe liefert, liefert auch mit openrc im interaktiven Modus keine. Und? Wenn man auf das Eyecandy normalerweise nicht verzichten kann, schaltet man es per Grub im Ernstfall ab, wenn man den interaktiven Modus braucht und plymouth tatsächlich den interaktiven Modus verhindern sollte (was ich bezweifle; vermutlich ist halt einfach nur die Ausgabe nicht so schön oder in bestimmten Modi nicht lesbar).
| Quote: | | Dazu kommt das in so einem Scenario alle Treiber (PS2, USB oder noch schlimmer Bluetooth) für die Tastatur schon geladen sein und laufen müssen um interaktiv zu werden |
Die Tastatur-Interaktivität ist erst mit laufender Tastatur möglich. Eine Wahnsinnserkenntnis und ein Riesenargument, die Interaktivität ganz abzuschalten oder gar ein Iniit-System zu benutzen, dass sie nicht unterstützt! Mannmannmannmann....
Zumal bei praktisch allen Systemen (von den vollkommen exotischen Bluetooth-Only Tastatur-Systemen mal abgesehen [die von den systemd-Fans offensichtlich jedes noch so große Fehlkonzept auf allen Systemen rechtfertigen sollen anstatt - wie es sinnvoll wäre - Protest über die unangemessenen Abhängigkeiten der Bluetooth-Tools unter Linux auszulösen]) die Tastatur mit dem Booten des Kernel oder allerspätestens mit dem Initialisieren der Kernel-Module - der ersten Aktion von openrc - geht.
Ich habe wirklich keine Lust, Deinen Unsinn die ganze Zeit zu zerlegen, aber Deine gezielten Propaganda-Falschinformationen konnte ich einfach nicht so stehen lassen.
Last edited by mv on Mon Jan 06, 2014 9:35 pm; edited 1 time in total |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Mon Jan 06, 2014 9:33 pm Post subject: |
|
|
| frostschutz wrote: | | Bei systemd, btrfs und zfs mache ich ja auch nicht mit. pam ist auch deaktiviert. pulseaudio ebenso Fehlanzeige. |
Diese Dinge haben mit cgroups nun wirklich nichts zu tun. In gewissen Anwendungsfällen mit ganz gezielten Konfigurationen kann cgroups als "verschärfte" chroot ein System sicherer machen. (Die Annahme, dass systemd dies tue, nur weil es irgendwie cgroups nutzt, wäre natürlich ein Kurzschluss).
OK, hier ist eine gewisse Symmetrie zu btfrs und zfs zu sehen: Eine separate noexec,nodev,nosuid-Partition kann auch iher in gewissen Anwendungsfällen als "verschärfte" chroot ein System sicherer machen.
Aber ich hoffe, jedem Leser ist klar, dass das verschiedene "Levels" sind.
Mit Geschwindigkeit hat das alles, wie gesagt, wenig zu tun: Lediglich dass man alle zugehörigen Prozesse "aufsummiert" "nicen" kann, spielt hier eine kleine Rolle, aber das ist eigentlich auch eher nur ein Sicherheitsaspekt, nämlich dass nicht ein Prozess mit niedrigen Rechten zu oft forken kann und damit dann doch das Gesamtsystem in die Knie zwingt. |
|
| Back to top |
|
|
frostschutz
Advocate
Joined: 22 Feb 2005
Posts: 2977
Location: Germany
|
| Posted: Tue Jan 07, 2014 12:27 am Post subject: |
|
|
| mv wrote: | | Diese Dinge haben mit cgroups nun wirklich nichts zu tun. |
Hab ich so auch nicht gemeint, war nur ne Feststellung am Rande, daß von dem "neuen Zeugs" viel an mir vorbeigeht.  |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Deutsches Forum (German)
