Wie ist es für das Anzeigen von "Starten ..." [OK] `verantwortlich?

383
nowox

Wenn ich einen Dienst starte, wie: 

root@foo [~]# service foobar stop Stopping Foobar: [ OK ]

Ich kann eine Statusanzeige sehen, [ OK ]die sich von der auf dem folgenden unterscheidet /var/log/boot.log:

[ OK ] Started LSB: disk temperature monitoring daemon. ...

Oder auch anders als: 

* /proc is already mounted * Caching service dependencies ... [ ok ]

Welcher Prozess ist in diesen drei Beispielen dafür verantwortlich, die Daemons anzuzeigen und zu starten? Anders gesagt, wird die Bibliothek verwendet, um anzuzeigen [ OK ], [FAILED]?

1

2 Antworten auf die Frage

3
grawity

Wenn bei einem manuellen Aufruf von serviceSyset ein Skript von /etc/init.d oder /etc/rc.d ausgeführt wird, hängt die gesamte Statusausgabe vollständig von diesem Skript ab.

Richtig geschriebene init.d-Skripte verwenden eine Bibliothek von Shell-Funktionen, die von der Distribution bereitgestellt werden. In Debian laden (zum Beispiel) die meisten Skripts die Datei /lib/lsb/init-functionsund rufen einfach die bereitgestellten Funktionen wie folgt auf :

Fall "$ 1" in Start) log_daemon_msg "$ DESC wird gestartet " "$ NAME" do_start Fall "$?" im 0 | 1) log_end_msg 0 ;; 2) log_end_msg 1 ;; esac ;; [...] esac

Hier ist die Liste der von LSB definierten Standardfunktionen . (Beachten Sie, dass distros kann vorsehen, zusätzliche über die Standardfunktionen, wie das Beispiel oben. Auch zu beachten, dass zB OpenRC oder Arch Linux ist nicht LSB-kompatibel und ganz verschiedene Stile verwenden.)

Tatsächlich stellen einige Distributionen diesen Boilerplate-Code auch zentral bereit, und das init.d-Skript muss nur noch implementiert werden do_start. (Siehe Gentoo OpenRC und Debian /lib/init/init-d-scriptals Beispiele). Dies ist jedoch keine "Standard" -LBB-Funktion - Skripts, die versuchen, LSB-kompatibel zu sein, müssen dies noch manuell tun.

Hinweis: I ‚richtig geschrieben‘ betonen, weil wirklich nichts da ist, das würde zwingen, ein init.d - Skript diese Funktionen, andere als menschliche Aufsicht zu verwenden. Wenn das Skript den Status per Klartext echo(oder über cowsaydiese Angelegenheit) melden möchte, kann es dies immer tun. Dies ist insbesondere bei kommerzieller Software, die außerhalb der normalen Kanäle vertrieben wird, ein Problem: Ihre Statusausgabe sieht nie ganz richtig aus (und ehrlich gesagt, das ganze init.d-Skript verhält sich nie ganz richtig).

Wenn SysV-Skripts während des Startvorgangs aufgerufen werden, ist das Ergebnis sogar noch stärker von der Distribution abhängig. Manchmal wird die Ausgabe direkt aus den Skripts selbst angezeigt. Manchmal liefert das "main" -Init-System jedoch eine eigene Statusausgabe für alle Dienste es beginnt. ( Beispiel: Alte Linux-Initscripts von Arch Linux, wenn ein Dienst im Hintergrund gestartet wird.)

Aber Ihr 2. Beispiel ist eigentlich keine SysV-Stil-Init - es ist systemd (was in Ihrem Beispiel einfach ein "altes" init.d-Skript startet). Systemd ist ein vollständiger Dienstmanager, der Dienstkonfigurationen (keine Skripts) verwendet. Daher wird die gesamte Statusausgabe beim Booten / Herunterfahren von systemd selbst bereitgestellt. Dies gilt auch für die meisten anderen "Service Manager", einschließlich init-ng, SMF oder Upstart.

Ich habe einen kurzen Blick auf `/ lib / lsb / init-functions` geworfen, aber wenn ich versuche, [1! = 2] && log_end_msg 1` auszuführen, bekomme ich` ... fail! `Nicht` [fail] `. Ich bin etwas verwirrt. nowox vor 6 Jahren 0
@nowox: Wahrscheinlich wollen Sie dann `log_failure_msg`. (Die init.d-Skripts sind in den verwendeten Funktionen nicht sehr konsistent. Mein Debian-Sid-System enthält eine Mischung aus verschiedenen Stilen.) grawity vor 6 Jahren 0
@nowox: Tatsächlich gibt die [tatsächliche LSB-Spezifikation] (http://refspecs.linuxbase.org/LSB_3.0.0/LSB-PDA/LSB-PDA/iniscrptfunc.html) für diesen Zweck "log_success_msg" und "log_failure_msg" an. (Natürlich verwenden viele Distributionen _non_-LSB-konforme Skripte ...) grawity vor 6 Jahren 1
0
Tomasz Pala

Dies kommt von distro-abhängigen Init-Skripten. Überprüfen Sie den serviceProgramminhalt. Dies ist wahrscheinlich ein Shellskript, das die darunter liegenden Verwaltungsskripts (SysV wird jetzt als veraltet angesehen) oder Binärdateien (Systemd ist der Weg). Dies ist einer der systembedingten Profis - Sie erhalten keine Antworten, die "abhängig" sind.

... weil "systemctl start" keinerlei Rückmeldungen liefert. grawity vor 6 Jahren 0
... und es scheint, dass "systemctl" auf "start-stop-daemon" setzt. nowox vor 6 Jahren 0
Nein, systemctl ist nicht auf den start-stop-daemon angewiesen, es sei denn, Sie verwenden eine Braindead-Distribution. Tomasz Pala vor 6 Jahren 0
Nein, das tut es nicht. (Die einzige Zeit, in der systemd den start-stop-daemon ausführt, ist _, wenn keine systemd .service-Datei vorhanden ist und das alte /etc/init.d-Skript aufgerufen werden muss - _those_ benutze den start-stop-daemon, wenn er richtig geschrieben ist .) grawity vor 6 Jahren 0
@grawity - Ja, es gibt keine Ausgabe, da die Nachricht [[OK]] nichts weiter als eine Lüge war, da es nur der Status eines ersten Starts war, bevor sich das System befand und deamonisierte. Sehr oft starb ein Sekunden später. Die einzige zuverlässige Nachricht war "[FAILED]", was manchmal nur bedeutete, dass der Dienst bereits lief, aber der Befehl "service" wusste das nicht. Tomasz Pala vor 6 Jahren 1
Oder gelegentlich [keine der oben genannten] (https://i.imgur.com/xj9nWKx.png) grawity vor 6 Jahren 1
Gut das zu wissen :( nowox vor 6 Jahren 0

Verwandte Probleme