s6 overlay
v3.2.0.2
Inhaltsverzeichnis
CMDs6-overlay ist ein einfach zu installierender Satz von Skripten und Dienstprogrammen (extrahieren Sie einfach ein oder zwei Tarballs!), mit dem Sie vorhandene Docker-Images verwenden können, während Sie s6 als PID 1 für Ihren Container und Prozess-Supervisor für Ihre Dienste verwenden.
Erstellen Sie die folgende Docker-Datei und probieren Sie es aus:
# Use your favorite image
FROM ubuntu
ARG S6_OVERLAY_VERSION=3.2.0.2
RUN apt-get update && apt-get install -y nginx xz-utils
RUN echo "daemon off;" >> /etc/nginx/nginx.conf
CMD ["/usr/sbin/nginx"]
ADD https://github.com/just-containers/s6-overlay/releases/download/v${S6_OVERLAY_VERSION}/s6-overlay-noarch.tar.xz /tmp
RUN tar -C / -Jxpf /tmp/s6-overlay-noarch.tar.xz
ADD https://github.com/just-containers/s6-overlay/releases/download/v${S6_OVERLAY_VERSION}/s6-overlay-x86_64.tar.xz /tmp
RUN tar -C / -Jxpf /tmp/s6-overlay-x86_64.tar.xz
ENTRYPOINT ["/init"]
docker-host $ docker build -t demo .
docker-host $ docker run --name s6demo -d -p 80:80 demo
docker-host $ docker top s6demo acxf
PID TTY STAT TIME COMMAND
11735 ? Ss 0:00 _ s6-svscan
11772 ? S 0:00 _ s6-supervise
11773 ? Ss 0:00 | _ s6-linux-init-s
11771 ? Ss 0:00 _ rc.init
11812 ? S 0:00 | _ nginx
11814 ? S 0:00 | _ nginx
11816 ? S 0:00 | _ nginx
11813 ? S 0:00 | _ nginx
11815 ? S 0:00 | _ nginx
11779 ? S 0:00 _ s6-supervise
11785 ? Ss 0:00 | _ s6-ipcserverd
11778 ? S 0:00 _ s6-supervise
docker-host $ curl --head http://127.0.0.1/
HTTP/1.1 200 OK
Server: nginx/1.18.0 (Ubuntu)
Date: Mon, 17 Jan 2022 13:33:58 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Mon, 17 Jan 2022 13:32:11 GMT
Connection: keep-alive
ETag: "61e56fdb-264"
Accept-Ranges: bytes
Wenn Sie von einer früheren Version von s6-overlay ( v2 ) auf die neue Version ( v3 ) migrieren, müssen Sie möglicherweise einige Änderungen an Ihren Diensten oder der Art und Weise vornehmen, wie Sie s6-overlay verwenden, damit alles reibungslos funktioniert. In diesem Dokument wird versucht, die Funktionsweise von Version 3 genau darzustellen. Wir haben jedoch eine separate Seite, auf der die Hauptunterschiede und Dinge aufgeführt sind, die Ihnen wahrscheinlich auffallen werden. Bitte lesen Sie es, wenn Sie sich in dieser Situation befinden!
Das Projekt hat folgende Ziele:
cont-init.d ), Finalisierung ( cont-finish.d ) und eigene Dienste mit Abhängigkeiten zwischen ihnen auszuführenPID 1 Funktionalitäts6 und s6-portable-utils enthalten sind. Dazu gehören praktische und zusammensetzbare Dienstprogramme, die unser Leben viel einfacher machen.logutil-service , der unter der Haube s6-log verwendet.USER Direktive von Docker, um Ihren gesamten Prozessbaum als bestimmter Benutzer auszuführen. Nicht mit allen Funktionen kompatibel, Details im Abschnitt „Hinweise“. Eines der oft wiederholten Docker-Mantras ist „ein Prozess pro Container“, aber wir sind anderer Meinung. Es ist grundsätzlich nichts Schlechtes daran, mehrere Prozesse in einem Container auszuführen. Das abstraktere „eine Sache pro Container“ ist unsere Richtlinie – ein Container sollte eine Sache tun, wie zum Beispiel „einen Chat-Dienst ausführen“ oder „gitlab ausführen“. Dies kann mehrere Prozesse umfassen, was in Ordnung ist.
Der andere Grund, warum Bildautoren vor Prozessüberwachern zurückschrecken, besteht darin, dass sie glauben, dass ein Prozessüberwacher ausgefallene Dienste neu starten muss , was bedeutet, dass der Docker-Container niemals sterben wird.
Dadurch wird das Docker-Ökosystem tatsächlich zerstört – die meisten Images führen einen Prozess aus, der beendet wird, wenn ein Fehler auftritt. Durch das Beenden bei Fehler ermöglichen Sie dem Systemadministrator, Fehler nach eigenem Ermessen zu behandeln. Wenn Ihr Image niemals beendet wird, benötigen Sie jetzt eine alternative Methode zur Fehlerbehebung und Fehlerbenachrichtigung.
Unser Grundsatz ist, dass, wenn „das Ding“ ausfällt, auch der Container ausfallen sollte. Dazu ermitteln wir, welche Prozesse neu gestartet werden können und welche den Container herunterfahren sollen. Wenn beispielsweise cron oder syslog fehlschlagen, kann Ihr Container ihn höchstwahrscheinlich ohne negative Auswirkungen neu starten. Wenn ejabberd jedoch fehlschlägt, sollte der Container beendet werden, damit der Systemadministrator Maßnahmen ergreifen kann.
Unsere Interpretation von „The Docker Way“ lautet wie folgt:
und unser Init-System ist genau darauf ausgelegt. Ihre Bilder verhalten sich wie andere Docker-Bilder und fügen sich in das bestehende Bild-Ökosystem ein.
Einzelheiten zum Stoppen „des Dings“ finden Sie unter „Ein optionales Finish-Skript schreiben“ im Abschnitt „Verwendung“.
Unser Overlay-Init ist ordnungsgemäß angepasst, um in Containerumgebungen ordnungsgemäß ausgeführt zu werden. In diesem Abschnitt wird kurz erklärt, wie Phasen funktionieren. Wenn Sie jedoch wissen möchten, wie ein vollständiges Init-System funktionieren sollte, können Sie diesen Artikel lesen: So führen Sie s6-svscan als Prozess 1 aus
/etc/cont-init.d enthalten sind./etc/s6-overlay/s6-rc.d deklarierten Benutzer-s6-rc-Dienste gemäß den Abhängigkeiten aus/etc/services.d ) in ein temporäres Verzeichnis und lassen Sie sie von s6 starten (und überwachen)./etc/cont-finish.d enthaltenen Finalisierungsskripts aus.TERM Signal. Es sollten sowieso keine Restprozesse mehr vorhanden sein.KILL Signal. Dann wird der Container ausgegeben. s6-overlay besteht aus einer Reihe von Tarballs, die Sie in Ihr Bild extrahieren können. Die von Ihnen benötigten Tarballs hängen von dem von Ihnen verwendeten Bild ab. Die meisten Leute werden die ersten beiden brauchen, und die anderen sind Extras, die Sie nach Belieben nutzen können.
s6-overlay-noarch.tar.xz : Dieser Tarball enthält die Skripte, die das Overlay implementieren. Wir nennen es „Noarch“, weil es architekturunabhängig ist: Es enthält nur Skripte und andere Textdateien. Jeder, der s6-overlay ausführen möchte, muss diesen Tarball extrahieren.s6-overlay-x86_64.tar.xz : Ersetzen Sie x86_64 durch die Architektur Ihres Systems. Dieser Tarball enthält alle notwendigen Binärdateien aus dem S6-Ökosystem, alle statisch verknüpft und nicht im Weg mit den Binärdateien Ihres Bildes. Sofern Sie nicht sicher wissen, dass Ihr Image bereits alle Pakete enthält, die die im Overlay verwendeten Binärdateien bereitstellen, müssen Sie diesen Tarball extrahieren.s6-overlay-symlinks-noarch.tar.xz : Dieser Tarball enthält Symlinks zu den S6-Overlay-Skripten, sodass sie über /usr/bin zugänglich sind. Dies ist normalerweise nicht erforderlich, da auf alle Skripts über die Umgebungsvariable PATH zugegriffen werden kann. Wenn Sie jedoch über alte Benutzerskripts verfügen, die Shebangs wie #!/usr/bin/with-contenv enthalten, werden sie durch die Installation dieser Symlinks funktionieren.s6-overlay-symlinks-arch.tar.xz : Dieser Tarball enthält Symlinks zu den Binärdateien aus dem S6-Ökosystem, die vom zweiten Tarball bereitgestellt werden, um sie über /usr/bin zugänglich zu machen. Normalerweise wird es nicht benötigt, aber wenn Sie alte Benutzerskripte haben, die Shebangs wie #!/usr/bin/execlineb enthalten, werden sie durch die Installation dieser Symlinks funktionieren.syslogd-overlay-noarch.tar.xz : Dieser Tarball enthält Definitionen für einen syslogd Dienst. Wenn Sie Daemons ausführen, die sich nicht bei stderr anmelden können, um die S6-Protokollierungsinfrastruktur zu nutzen, aber die Verwendung des alten syslog() Mechanismus fest codieren, können Sie diesen Tarball extrahieren, und Ihr Container führt eine schlanke Emulation eines syslogd -Daemons aus. Daher werden Ihre Syslog-Protokolle erfasst und auf der Festplatte gespeichert.Um diese Tarballs zu installieren, fügen Sie Ihrer Docker-Datei Zeilen hinzu, die der Funktionalität entsprechen, die Sie installieren möchten. Die meisten Leute würden zum Beispiel Folgendes verwenden:
ADD https://github.com/just-containers/s6-overlay/releases/download/v${S6_OVERLAY_VERSION}/s6-overlay-noarch.tar.xz /tmp
RUN tar -C / -Jxpf /tmp/s6-overlay-noarch.tar.xz
ADD https://github.com/just-containers/s6-overlay/releases/download/v${S6_OVERLAY_VERSION}/s6-overlay-x86_64.tar.xz /tmp
RUN tar -C / -Jxpf /tmp/s6-overlay-x86_64.tar.xz
Stellen Sie sicher, dass Sie beim Extrahieren die Dateiberechtigungen beibehalten (z. B. die Option -p für tar verwenden).
Das Projekt wird als Satz standardmäßiger .tar.xz-Dateien verteilt, die Sie im Stammverzeichnis Ihres Bildes extrahieren. (Sie benötigen das xz-utils-Paket, damit tar .tar.xz Dateien verstehen kann; es ist in jeder Distribution verfügbar, aber nicht immer in den Standard-Container-Images, daher müssen Sie möglicherweise apt install xz-utils oder apk add xz verwenden, oder Äquivalent, bevor Sie die Archive erweitern können.)
Setzen Sie anschließend Ihren ENTRYPOINT auf /init .
Im Moment empfehlen wir die Verwendung ADD Direktive von Docker, anstatt wget oder curl in einer RUN -Direktive auszuführen. Docker kann die https-URL verarbeiten, wenn Sie ADD verwenden, während Ihr Basis-Image https möglicherweise nicht verwenden kann oder nicht einmal hat wget oder curl überhaupt installiert.
Von dort aus haben Sie mehrere Möglichkeiten:
CMD Ihres Bildes aus.CMD Die Verwendung von CMD ist eine bequeme Möglichkeit, die Vorteile des Overlays zu nutzen. Ihr CMD kann zur Build-Zeit in der Docker-Datei oder zur Laufzeit in der Befehlszeile angegeben werden, beide Möglichkeiten sind in Ordnung. Es wird als normaler Prozess in der von s6 eingerichteten Umgebung ausgeführt. Wenn es fehlschlägt oder beendet wird, wird der Container ordnungsgemäß heruntergefahren und beendet. Sie können interaktive Programme auf diese Weise ausführen: Nur der CMD erhält Ihren interaktiven Befehl, die Supportprozesse bleiben davon unberührt.
Zum Beispiel:
FROM busybox
ADD https://github.com/just-containers/s6-overlay/releases/download/v${S6_OVERLAY_VERSION}/s6-overlay-noarch.tar.xz /tmp
RUN tar -C / -Jxpf /tmp/s6-overlay-noarch.tar.xz
ADD https://github.com/just-containers/s6-overlay/releases/download/v${S6_OVERLAY_VERSION}/s6-overlay-x86_64.tar.xz /tmp
RUN tar -C / -Jxpf /tmp/s6-overlay-x86_64.tar.xz
ENTRYPOINT ["/init"]
docker-host $ docker build -t s6demo .
docker-host $ docker run -ti s6demo /bin/sh
/package/admin/s6-overlay/libexec/preinit: notice: /var/run is not a symlink to /run, fixing it
s6-rc: info: service s6rc-oneshot-runner: starting
s6-rc: info: service s6rc-oneshot-runner successfully started
s6-rc: info: service fix-attrs: starting
s6-rc: info: service fix-attrs successfully started
s6-rc: info: service legacy-cont-init: starting
s6-rc: info: service legacy-cont-init successfully started
s6-rc: info: service legacy-services: starting
s6-rc: info: service legacy-services successfully started
/ # ps
PID USER TIME COMMAND
1 root 0:00 /package/admin/s6/command/s6-svscan -d4 -- /run/service
17 root 0:00 {rc.init} /bin/sh -e /run/s6/basedir/scripts/rc.init top /bin/sh
18 root 0:00 s6-supervise s6-linux-init-shutdownd
20 root 0:00 /package/admin/s6-linux-init/command/s6-linux-init-shutdownd -c /run/s6/basedir -g 3000 -C -B
24 root 0:00 s6-supervise s6rc-fdholder
25 root 0:00 s6-supervise s6rc-oneshot-runner
31 root 0:00 /package/admin/s6/command/s6-ipcserverd -1 -- /package/admin/s6/command/s6-ipcserver-access -v0 -E -l0 -i data/rules -- /packa
58 root 0:00 /bin/sh
66 root 0:00 ps
/ # exit
s6-rc: info: service legacy-services: stopping
s6-rc: info: service legacy-services successfully stopped
s6-rc: info: service legacy-cont-init: stopping
s6-rc: info: service legacy-cont-init successfully stopped
s6-rc: info: service fix-attrs: stopping
s6-rc: info: service fix-attrs successfully stopped
s6-rc: info: service s6rc-oneshot-runner: stopping
s6-rc: info: service s6rc-oneshot-runner successfully stopped
docker-host $
Die andere Möglichkeit, einen Container mit S6-Overlay zu verwenden, besteht darin, Ihre Dienste zu überwachen. Sie können beliebig viele Dienste betreuen; Normalerweise handelt es sich lediglich um Unterstützungsdienste für den Hauptdaemon, den Sie als CMD ausführen. Wenn Sie dies jedoch wünschen, hindert Sie nichts daran, einen leeren CMD zu haben und Ihren Hauptdaemon auch als überwachten Dienst auszuführen. In diesem Fall wird der Daemon bei jedem Beenden von s6 neu gestartet; Der Container stoppt nur, wenn Sie ihn dazu auffordern, entweder über einen docker stop Stoppbefehl oder aus dem Container heraus mit dem Befehl /run/s6/basedir/bin/halt .
Es gibt zwei Möglichkeiten, einen überwachten Service durchzuführen. Der alte Weg, der immer noch unterstützt wird, besteht darin, ein „reines S6“-Dienstverzeichnis zu erstellen. Erstellen Sie in /etc/services.d ein Verzeichnis mit dem Namen Ihres Dienstes und legen Sie dort eine ausführbare run ab. Dies ist die Datei, in der Sie Ihre langlebige Prozessausführung ablegen. Einzelheiten zur Überwachung von Dienstverzeichnissen und wie Sie konfigurieren können, wie s6 mit Ihrem Daemon umgeht, finden Sie in der Servicedir-Dokumentation. Ein einfaches Beispiel würde so aussehen:
/etc/services.d/myapp/run :
#!/command/execlineb -P
nginx -g "daemon off;"
Die neue Möglichkeit besteht darin, ein s6-rc- Quellendefinitionsverzeichnis im Verzeichnis /etc/s6-overlay/s6-rc.d zu erstellen und den Namen dieses Verzeichnisses dem user hinzuzufügen, dh eine leere Datei mit demselben Namen zu erstellen im Verzeichnis /etc/s6-overlay/s6-rc.d/user/contents.d . Auf dieser Seite wird das Format eines Quelldefinitionsverzeichnisses beschrieben. Beachten Sie, dass Sie Longruns definieren können, also Daemons, die wie bei der Methode /etc/services.d von s6 überwacht werden, aber auch Oneshots , also Programme, die einmal ausgeführt und dann beendet werden. Ihr Hauptdienst ist wahrscheinlich ein Langzeitdienst , kein Oneshot : Sie benötigen wahrscheinlich einen Daemon, der in der Nähe bleibt.
Der Vorteil dieses neuen Formats besteht darin, dass Sie damit Abhängigkeiten zwischen Diensten definieren können: Wenn B von A abhängt, startet A zuerst, dann startet B , wenn A bereit ist, und wenn der Container zum Beenden aufgefordert wird, stoppt B zuerst, dann A . Wenn Sie über eine komplexe Architektur verfügen, in der verschiedene Prozesse voneinander abhängen oder Sie einfach Oneshots und Longruns in einer präzisen Reihenfolge mischen müssen, ist dies möglicherweise das Richtige für Sie.
Das obige Beispiel könnte folgendermaßen umgeschrieben werden:
/etc/s6-overlay/s6-rc.d/myapp/type :
longrun
/etc/s6-overlay/s6-rc.d/myapp/run :
#!/command/execlineb -P
nginx -g "daemon off;"
/etc/s6-overlay/s6-rc.d/user/contents.d/myapp : leere Datei. (Dadurch wird myapp zu den Diensten hinzugefügt, die s6-rc beim Booten des Containers startet.)
/etc/s6-overlay/s6-rc.d/myapp/dependencies.d/base : leere Datei. (Dadurch wird s6-rc angewiesen, myapp nur zu starten, wenn alle Basisdienste bereit sind: Dies verhindert Race Conditions.)
Wir empfehlen Ihnen, auf das neue Format umzusteigen, aber wenn Sie dessen Vorteile nicht benötigen, können Sie bei den regulären Serviceverzeichnissen in /etc/services.d bleiben, es wird genauso gut funktionieren.
Wenn Sie Ihren Hauptdienst als CMD ausführen, müssen Sie nichts tun: Wenn Ihr CMD beendet wird oder wenn Sie docker stop ausführen, wird der Container natürlich mit demselben Exit-Code wie Ihr Dienst beendet. (Beachten Sie jedoch, dass Ihr Dienst im docker stop -Fall ein SIGTERM erhält. In diesem Fall hängt der Exit-Code vollständig davon ab, wie Ihr Dienst damit umgeht – er könnte ihn abfangen und beenden, 0, ihn abfangen und etwas anderes beenden , oder es nicht abfangen und die Shell ihren eigenen Code dafür ausgeben lassen – normalerweise 130.)
Wenn Sie Ihren Hauptdienst jedoch als überwachten Dienst ausführen, sind die Dinge anders und Sie müssen dem Container mitteilen, mit welchem Code er beendet werden soll, wenn Sie ihm einen docker stop -Befehl senden. Dazu müssen Sie ein finish -Skript schreiben:
/etc/services.d handelt, benötigen Sie ein ausführbares /etc/services.d/myapp/finish ./etc/s6-overlay/s6-rc.d/myapp/finish die Ihr Skript enthält (die Datei kann ausführbar sein oder auch nicht). Dieses finish wird ausgeführt, wenn Ihr Dienst beendet wird, und akzeptiert zwei Argumente:
Im finish -Skript müssen Sie den gewünschten Container-Exit-Code in die Datei /run/s6-linux-init-container-results/exitcode schreiben – und das war’s.
Das finish -Skript für den oben genannten myapp -Dienst könnte beispielsweise so aussehen:
#! /bin/sh
if test " $1 " -eq 256 ; then
e= $(( 128 + $2 ))
else
e= " $1 "
fi
echo " $e " > /run/s6-linux-init-container-results/exitcode Wenn Sie einen docker stop -Befehl an Ihren Container senden, wird der myapp -Dienst beendet und dieses Skript ausgeführt; Es schreibt entweder den Exit-Code von myapp (wenn myapp das TERM-Signal empfängt) oder 130 (wenn myapp das TERM-Signal nicht empfängt) in die spezielle Datei /run/s6-linux-init-container-results/exitcode wird am Ende des Vorgangs zum Herunterfahren des Containers von s6-overlay gelesen und Ihr Container wird mit diesem Wert beendet.
In diesem Abschnitt wird eine Funktionalität aus den Versionen von s6-overlay vor Version 3 beschrieben. fix-attrs wird in Version 3 weiterhin unterstützt, ist jedoch aus mehreren Gründen veraltet : Einer davon ist, dass es im Allgemeinen keine gute Richtlinie ist, den Eigentümer dynamisch zu ändern, wenn dies statisch möglich ist. Ein weiterer Grund ist, dass es nicht mit USER-Containern funktioniert. Anstelle von „fix-attrs“ empfehlen wir Ihnen jetzt, sich offline um Besitz und Berechtigungen für Host-Mounts zu kümmern, bevor Sie den Container ausführen . Dies sollte in Ihrer Docker-Datei erfolgen, wenn Sie über alle erforderlichen Informationen verfügen.
Das heißt, hier ist, was wir für frühere Versionen geschrieben haben und das auch heute noch gilt (aber bitte hören Sie auf, davon abhängig zu sein):
Manchmal ist es interessant, den Besitz und die Berechtigungen festzulegen, bevor Sie fortfahren, weil Sie beispielsweise einen Host-Ordner in Ihrem Container gemountet/zugeordnet haben. Unser Overlay bietet eine Möglichkeit, dieses Problem mithilfe von Dateien in /etc/fix-attrs.d zu lösen. Dies ist das Musterformat, dem Fix-Attrs-Dateien folgen:
path recurse account fmode dmode
path : Datei- oder Verzeichnispfad.recurse : (Auf true oder false setzen) Wenn ein Ordner gefunden wird, wird eine Rekursion durch alle darin enthaltenen Dateien und Ordner durchgeführt.account : Zielkonto. Es ist möglich, standardmäßig auf die Fallback-ID uid:gid zurückzugreifen, wenn das Konto nicht gefunden wird. Beispielsweise würde nobody,32768:32768 zunächst versuchen, das Konto nobody zu verwenden, und dann stattdessen auf uid 32768 zurückgreifen. Wenn daemon -Konto beispielsweise UID=2 und GID=2 ist, sind dies die möglichen Werte für account :daemon: UID=2 GID=2daemon,3:4: UID=2 GID=22:2,3:4: UID=2 GID=2daemon:11111,3:4: UID=2 GID=1111111111:daemon,3:4: UID=11111 GID=2daemon:daemon,3:4: UID=2 GID=2daemon:unexisting,3:4: UID=2 GID=4unexisting:daemon,3:4: UID=3 GID=211111:11111,3:4: UID=11111 GID=11111fmode : Zieldateimodus. Zum Beispiel 0644 .dmode : Zielverzeichnis-/Ordnermodus. Zum Beispiel 0755 .Hier finden Sie einige Arbeitsbeispiele:
/etc/fix-attrs.d/01-mysql-data-dir :
/var/lib/mysql true mysql 0600 0700
/etc/fix-attrs.d/02-mysql-log-dirs :
/var/log/mysql-error-logs true nobody,32768:32768 0644 2700
/var/log/mysql-general-logs true nobody,32768:32768 0644 2700
/var/log/mysql-slow-query-logs true nobody,32768:32768 0644 2700
Hier ist die alte Vorgehensweise:
Nach dem Korrigieren von Attributen (über /etc/fix-attrs.d/ ) und vor dem Starten der vom Benutzer bereitgestellten Dienste (über s6-rc oder /etc/services.d ) führt unser Overlay alle in /etc/cont-init.d , zum Beispiel:
/etc/cont-init.d/02-confd-onetime :
#!/command/execlineb -P
with-contenv
s6-envuidgid nginx
multisubstitute
{
import -u -D0 UID
import -u -D0 GID
import -u CONFD_PREFIX
define CONFD_CHECK_CMD "/usr/sbin/nginx -t -c {{ .src }}"
}
confd --onetime --prefix="${CONFD_PREFIX}" --tmpl-uid="${UID}" --tmpl-gid="${GID}" --tmpl-src="/etc/nginx/nginx.conf.tmpl" --tmpl-dest="/etc/nginx/nginx.conf" --tmpl-check-cmd="${CONFD_CHECK_CMD}" etcd
Dieser Weg wird weiterhin unterstützt. Allerdings gibt es jetzt eine allgemeinere und effizientere Möglichkeit, dies zu tun: Schreiben Sie Ihre One-Shot-Initialisierungs- und Finalisierungsaufgaben als s6-rc-Dienste, indem Sie Dienstdefinitionsverzeichnisse in /etc/s6-overlay/s6-rc.d hinzufügen und sie so zu einem Teil machen des user -Bundles (damit sie tatsächlich gestartet werden, wenn der Container startet) und sie vom base Bundle abhängig machen (damit sie erst nach base gestartet werden).
Alle Informationen zu s6-rc finden Sie hier.
Beim Starten des Containers werden die Vorgänge in dieser Reihenfolge ausgeführt:
/etc/fix-attrs.d durchgeführt./etc/cont-init.d werden nacheinander ausgeführt.user werden von s6-rc in einer durch Abhängigkeiten definierten Reihenfolge gestartet. Dienste können Oneshots (Initialisierungsaufgaben) oder Longruns (Daemons, die während der gesamten Lebensdauer des Containers ausgeführt werden) sein. Wenn die Dienste von base abhängen, werden sie garantiert an diesem Punkt und nicht früher gestartet. Ist dies nicht der Fall, wurden sie möglicherweise früher gestartet, was zu Rennbedingungen führen kann. Es wird daher empfohlen, sie immer von base abhängig zu machen./etc/services.d werden gestartet.user2 Bundle mit der richtigen Abhängigkeit werden gestartet. (Die meisten Benutzer müssen dies nicht verwenden. Wenn Sie sich nicht sicher sind, bleiben Sie beim user .)Wenn der Container gestoppt wird, entweder weil der Administrator einen Stoppbefehl gesendet hat oder weil der CMD beendet wurde, werden die Vorgänge in umgekehrter Reihenfolge ausgeführt:
user2 Bundle mit der richtigen Abhängigkeit werden gestoppt./etc/services.d werden gestoppt.down -Skript im Quelldefinitionsverzeichnis ausgeführt wird; Auf diese Weise kann s6-rc Finalisierungsaufgaben ausführen./etc/cont-finish.d werden nacheinander ausgeführt. Der Sinn des user2 Bundles besteht darin, den darin deklarierten Benutzerdiensten den Start nach den /etc/services.d zu ermöglichen; Dazu muss jedoch jeder Dienst in user2 eine Abhängigkeit zu legacy-services deklarieren. Mit anderen Worten: Damit eine Service- foobar zu spät startet, müssen Sie Folgendes tun:
/etc/s6-overlay/s6-rc.d/foobar ./etc/s6-overlay/s6-rc.d/foobar/dependencies.d/legacy-services hinzu/etc/s6-overlay/s6-rc.d/user2/contents.d/foobar hinzu. Dadurch wird sichergestellt, dass foobar nach allem in /etc/services.d gestartet wird.
Standardmäßig werden in /etc/services.d erstellte Dienste automatisch neu gestartet. Wenn ein Dienst den Container herunterfahren sollte, sollten Sie ihn stattdessen wahrscheinlich als CMD ausführen. Wenn Sie es jedoch lieber als überwachten Dienst ausführen möchten, müssen Sie ein finish schreiben, das ausgeführt wird, wenn der Dienst ausgefallen ist. Um den Container anzuhalten, muss der Befehl /run/s6/basedir/bin/halt aufgerufen werden. Hier ist ein Beispiel für ein Finish-Skript:
/etc/services.d/myapp/finish :
#!/command/execlineb -S0
foreground { redirfd -w 1 /run/s6-linux-init-container-results/exitcode echo 0 }
/run/s6/basedir/bin/halt
Die erste Zeile des Skripts schreibt 0 in die Datei /run/s6-linux-init-container-results/exitcode . Die zweite Zeile stoppt den Container. Wenn Sie den Container über den Befehl /run/s6/basedir/bin/halt stoppen, der aus dem Container heraus ausgeführt wird, wird /run/s6-linux-init-container-results/exitcode gelesen und sein Inhalt wird als Exit-Code für verwendet der docker run Befehl, der den Container gestartet hat. Wenn die Datei nicht vorhanden ist oder der Container mit docker stop oder aus einem anderen Grund gestoppt wird, ist dieser Exit-Code standardmäßig 0.
Es ist möglich, in einem Finish-Skript erweiterte Vorgänge auszuführen. Hier ist zum Beispiel ein Skript, das den Dienst nur dann herunterfährt, wenn er einen Wert ungleich Null beendet:
/etc/services.d/myapp/finish :
#!/command/execlineb -S1
if { eltest ${1} -ne 0 -a ${1} -ne 256 }
/run/s6/basedir/bin/halt
Beachten Sie, dass Finish-Skripte im Allgemeinen nur für lokale Bereinigungen verwendet werden sollten, nachdem ein Daemon gestorben ist. Wenn ein Dienst so wichtig ist, dass der Container gestoppt werden muss, wenn er ausfällt, empfehlen wir dringend, ihn als CMD auszuführen.
Jeder Dienst kann über einen eigenen Logger verfügen. Ein Logger ist ein S6-Dienst, der automatisch die Standardausgabe Ihres Dienstes liest und die Daten in einer automatisch rotierten Datei an der gewünschten Stelle protokolliert. Beachten Sie, dass Daemons sich normalerweise bei stderr und nicht bei stdout anmelden. Daher sollten Sie das Ausführungsskript Ihres Dienstes wahrscheinlich mit exec 2>&1 in der Shell oder mit fdmove -c 2 1 in execline starten, um stderr abzufangen.
s6-overlay bietet ein Dienstprogramm namens logutil-service , das einen Wrapper für das s6-log -Programm darstellt. Dieser Helfer führt Folgendes aus:
S6_LOGGING_SCRIPT enthaltene Protokollierungsskript lesennobody abgeben (standardmäßig 65534:65534 wenn er nicht existiert) s6-log läuft dann für immer, liest Daten von Ihrem Dienst und schreibt sie in das Verzeichnis, das Sie für logutil-service angegeben haben.
Bitte beachten Sie:
s6-setuidgid nicht erforderlichnobody beschreibbarnobody beschreibbar. Sie können Protokollordner in cont-init.d -Skripten oder als s6-rc-Oneshots erstellen. Hier ist ein Beispiel für einen protokollierten Dienst myapp der auf die alte Weise implementiert wurde:
/etc/cont-init.d/myapp-log-prepare :
#! /bin/sh -e
mkdir -p /var/log/myapp
chown nobody:nogroup /var/log/myapp
chmod 02755 /var/log/myapp /etc/services.d/myapp/run :
#! /bin/sh
exec 2>&1
exec mydaemon-in-the-foreground-and-logging-to-stderr /etc/services.d/myapp/log/run :
#! /bin/sh
exec logutil-service /var/log/myappUnd hier ist derselbe Dienst, myapp, implementiert in s6-rc.
/etc/s6-overlay/s6-rc.d/myapp-log-prepare/dependencies.d/base : leere Datei
/etc/s6-overlay/s6-rc.d/myapp-log-prepare/type :
oneshot
/etc/s6-overlay/s6-rc.d/myapp-log-prepare/up :
if { mkdir -p /var/log/myapp }
if { chown nobody:nogroup /var/log/myapp }
chmod 02755 /var/log/myapp
(Beginn des ausführlichen Abschnitts.)
Die up und down -Dateien sind also etwas Besonderes: Es handelt sich nicht um Shell-Skripte, sondern um einzelne Befehlszeilen, die von execlineb interpretiert werden. Sie sollten sich keine Sorgen um Execline machen müssen; Sie sollten sich nur daran erinnern, dass eine up -Datei eine einzige Befehlszeile enthält. Wenn Sie also ein Skript mit mehreren Anweisungen benötigen, gehen Sie wie folgt vor:
up -Datei auf. So würden Sie normalerweise vorgehen, um die up -Datei für myapp-log-prepare zu schreiben:
/etc/s6-overlay/s6-rc.d/myapp-log-prepare/up :
/etc/s6-overlay/scripts/myapp-log-prepare
/etc/s6-overlay/scripts/myapp-log-prepare : (muss ausführbar sein)
#! /bin/sh -e
mkdir -p /var/log/myapp
chown nobody:nogroup /var/log/myapp
chmod 02755 /var/log/myapp Der Speicherort des eigentlichen Skripts ist beliebig, er muss lediglich mit dem übereinstimmen, was Sie in die up -Datei schreiben.
Aber hier ist es einfach so, dass das Skript so einfach ist, dass es vollständig in die up -Datei passt, ohne dass es zu komplex oder zu schwer verständlich wird. Deshalb haben wir uns entschieden, es als Beispiel aufzunehmen, um zu zeigen, dass Sie mit up -Dateien noch mehr machen können, wenn Sie dazu geneigt sind. Die vollständige Dokumentation für die Execline-Sprache können Sie hier lesen.
(Am Ende des detaillierten Abschnitts klicken Sie erneut auf das Dreieck oben, um es auszublenden.)
/etc/s6-overlay/s6-rc.d/myapp/dependencies.d/base : leere Datei
/etc/s6-overlay/s6-rc.d/myapp-log/dependencies.d/myapp-log-prepare : leere Datei
/etc/s6-overlay/s6-rc.d/myapp/type :
longrun
/etc/s6-overlay/s6-rc.d/myapp/run :
#! /bin/sh
exec 2>&1
exec mydaemon-in-the-foreground-and-logging-to-stderr /etc/s6-overlay/s6-rc.d/myapp/producer-for :
myapp-log
/etc/s6-overlay/s6-rc.d/myapp-log/type :
longrun
/etc/s6-overlay/s6-rc.d/myapp-log/run :
#! /bin/sh
exec logutil-service /var/log/myapp /etc/s6-overlay/s6-rc.d/myapp-log/consumer-for :
myapp
/etc/s6-overlay/s6-rc.d/myapp-log/pipeline-name :
myapp-pipeline
/etc/s6-overlay/s6-rc.d/user/contents.d/myapp-pipeline : leere Datei
Das sind viele Dateien! Eine Zusammenfassung dessen, was das alles bedeutet, ist:
myapp | myapp-log -Pipeline erhält einen Namen, myapp-pipeline , und dieser Name wird als Teil des user deklariert, sodass sie beim Start des Containers gestartet wird.myapp-log-prepare , myapp-log und myapp hängen alle vom base ab, was bedeutet, dass sie nur gestartet werden, wenn das System tatsächlich zum Starten bereit ist. Es erreicht wirklich die gleichen Dinge wie die Methode /etc/cont-init.d plus /etc/services.d , ist aber im Grunde viel sauberer und kann viel komplexere Abhängigkeitsdiagramme verarbeiten. Wir empfehlen Ihnen daher, wann immer Sie die Gelegenheit dazu haben Sie machen sich mit der S6-RC-Methode zur Deklaration Ihrer Dienste und Logger vertraut. Die vollständige Syntax eines Dienstdefinitionsverzeichnisses, einschließlich der Angabe, ob es sich bei Ihrem Dienst um einen Longrun- oder Oneshot-Dienst handelt, der Deklaration von Pipelines, dem Hinzufügen dienstspezifischer Zeitüberschreitungen bei Bedarf usw. finden Sie hier.
Wenn es um die Ausführung eines Dienstes geht, unabhängig davon, ob es sich um einen Dienst oder einen Logger handelt, empfiehlt es sich, die Berechtigungen vor der Ausführung zu entziehen. s6 enthält bereits Dienstprogramme, um genau diese Dinge zu tun:
In execline :
#!/command/execlineb -P
s6-setuidgid daemon
myservice
In sh :
#! /bin/sh
exec s6-setuidgid daemon myservice Wenn Sie mehr über diese Dienstprogramme erfahren möchten, werfen Sie bitte einen Blick auf: s6-setuidgid , s6-envuidgid und s6-applyuidgid .
Wenn Sie möchten, dass in Ihrem benutzerdefinierten Skript Containerumgebungen verfügbar sind, können Sie den with-contenv Helper verwenden, der alle diese in Ihre Ausführungsumgebung schiebt, zum Beispiel:
/etc/cont-init.d/01-contenv-example :
#! /command/with-contenv sh
envDieses Skript gibt den Inhalt Ihrer Containerumgebung aus.
Aktuelle Versionen von Docker ermöglichen die Ausführung von Containern mit einem schreibgeschützten Root-Dateisystem. Wenn Ihr Container in einem solchen Fall ist, sollten Sie S6_READ_ONLY_ROOT=1 setzen, um s6-overlay darüber zu informieren, dass es nicht versuchen soll, in bestimmte Bereiche zu schreiben – stattdessen werden Kopien in ein tmpfs ausgeführt, das auf /run gemountet ist.
Beachten Sie, dass s6-overlay Folgendes voraussetzt:
/run existiert und ist beschreibbar. Ist dies nicht der Fall, wird versucht, dort ein tmpfs einzubinden./var/run ist aus Kompatibilitätsgründen mit früheren Versionen ein symbolischer Link zu /run . Wenn nicht, wird es so sein. Im Allgemeinen sollten Ihre Standard-Docker-Einstellungen bereits ein geeignetes tmpfs in /run bereitstellen.
Es ist irgendwie möglich, das Verhalten von s6-overlay zu optimieren, indem dem Ausführungskontext ein bereits vordefinierter Satz von Umgebungsvariablen bereitgestellt wird:
PATH (Standard = /command:/usr/bin:/bin ): Dies ist der Standardpfad, den alle Dienste im Container, einschließlich CMD, haben. Legen Sie diese Variable fest, wenn Sie viele Dienste haben, die von Binärdateien abhängen, die in einem anderen Verzeichnis gespeichert sind, z. B. /usr/sbin . Beachten Sie, dass /command , /usr/bin und /bin immer zu diesem Pfad hinzugefügt werden, wenn sie sich nicht bereits in dem von Ihnen angegebenen Pfad befinden.S6_KEEP_ENV (Standard = 0): Wenn festgelegt, wird die Umgebung nicht zurückgesetzt und der gesamte Überwachungsbaum sieht den ursprünglichen Satz von Umgebungsvariablen. Es wandelt with-contenv in ein nop um.S6_LOGGING (Standard = 0):0 : Gibt alles nach stdout/stderr aus.1 : Verwendet einen internen catch-all -Logger und speichert alles darauf. Er befindet sich in /var/log/s6-uncaught-logs . Alles, was als CMD ausgeführt wird, wird weiterhin an stdout/stderr ausgegeben.2 : Verwendet einen internen catch-all -Logger und speichert alles darauf, einschließlich der Ausgabe von CMD . Es wird absolut nichts nach stdout/stderr geschrieben.S6_CATCHALL_USER (Standard = Root): Wenn festgelegt und S6_LOGGING 1 oder 2 ist, wird der Catch-All-Logger unter diesem Benutzer ausgeführt, der in /etc/passwd Ihres Images definiert sein muss. Jede noch so kleine Privilegientrennung trägt ein wenig zur Sicherheit bei.S6_BEHAVIOUR_IF_STAGE2_FAILS (Standard = 0): bestimmt, was der Container tun soll, wenn eines der Dienstskripte fehlschlägt. Dazu gehört:fix-attrs fehlschlägt/etc/cont-init.d im alten Stil oder ein s6-rc-Oneshot im neuen Stil fehlschlägt/etc/services.d alten Stils oder ein s6-rc-Longrun neuen Stils als „Bereitschaftsbenachrichtigung erwartend“ markiert ist und nicht innerhalb der vorgegebenen Zeit bereit ist (siehe S6_CMD_WAIT_FOR_SERVICES_MAXTIME unten). Die gültigen Werte für S6_BEHAVIOUR_IF_STAGE2_FAILS sind die folgenden:0 : Stille Fortsetzung, auch wenn ein Skript fehlgeschlagen ist.1 : Fahren Sie fort, aber warnen Sie mit einer lästigen Fehlermeldung.2 : Stoppen Sie den Behälter.S6_KILL_FINISH_MAXTIME (Standard = 5000): Wie lange (in Millisekunden) das System beim Herunterfahren warten soll, bis ein Skript in /etc/cont-finish.d auf natürliche Weise beendet wird. Nach dieser Dauer wird dem Skript ein SIGKILL gesendet. Bedenken Sie, dass Skripte in /etc/cont.finish.d nacheinander ausgeführt werden und die Abschaltsequenz möglicherweise S6_KILL_FINISH_MAXTIME Millisekunden für jedes Skript wartet.S6_SERVICES_READYTIME (Standard = 50): Bei Diensten, die in /etc/services.d deklariert sind, besteht eine unvermeidbare Wettlaufbedingung zwischen dem Zeitpunkt, an dem Dienste gestartet werden, und dem Zeitpunkt, an dem sie auf ihre Bereitschaft getestet werden können. Um dieses Rennen zu vermeiden, schlafen wir ein wenig, standardmäßig 50 Millisekunden, bevor wir die Bereitschaft testen. Wenn Ihr Computer langsam oder sehr ausgelastet ist, erhalten Sie möglicherweise Fehlermeldungen wie s6-svwait: fatal: unable to s6_svstatus_read: No such file or directory . In diesem Fall sollten Sie die Ruhezeit erhöhen, indem Sie sie (in Millisekunden) in der Variablen S6_SERVICES_READYTIME angeben. Beachten Sie, dass es nur /etc/services.d betrifft; s6-rc ist immun gegen die Rennbedingung.S6_SERVICES_GRACETIME (Standard = 3000): Wie lange (in Millisekunden) s6 beim Herunterfahren warten soll, bis die in /etc/services.d deklarierten Dienste beendet sind, bevor mit dem Rest des Herunterfahrens fortgefahren wird.S6_KILL_GRACETIME (Standard = 3000): Wie lange (in Millisekunden) s6 am Ende des Herunterfahrvorgangs warten soll, wenn alle Prozesse ein TERM-Signal erhalten haben, bis sie sterben, bevor ein KILL -Signal gesendet wird, um sicherzustellen, dass sie tot sind .S6_LOGGING_SCRIPT (Standard = „n20 s1000000 T“): Diese Umgebung entscheidet, was und wie protokolliert werden soll. Standardmäßig wird jeder Zeile ISO8601 vorangestellt, gedreht, wenn die aktuelle Protokolldatei 1 MB erreicht, und mit maximal 20 Dateien archiviert.S6_CMD_ARG0 (Standard = nicht festgelegt): Der Wert dieser Umgebungsvariable wird allen vom Docker übergebenen CMD Argumenten vorangestellt. Verwenden Sie es, wenn Sie ein vorhandenes Bild auf s6-overlay migrieren und es zu einem Drop-In-Ersatz machen möchten: Das Festlegen dieser Variablen auf den Wert eines zuvor verwendeten ENTRYPOINT erleichtert Ihnen den Übergang.S6_CMD_USE_TERMINAL (Standard = 0): Setzen Sie diesen Wert auf 1 , wenn Sie einen CMD haben, der ein Terminal für seine Ausgabe benötigt (normalerweise, wenn Sie Ihren Container mit docker run -it ausführen) und Sie S6_LOGGING auf einen Wert ungleich Null gesetzt haben. Diese Einstellung sorgt dafür, dass Ihr CMD tatsächlich auf Ihrem Terminal ausgegeben wird. Der Nachteil besteht darin, dass die Ausgabe nicht protokolliert wird. Standardmäßig (wenn diese Variable 0 ist oder nicht gesetzt ist) werden stdout und stderr Ihres CMD protokolliert, wenn S6_LOGGING ungleich Null ist, was bedeutet, dass sie an eine Pipe weitergeleitet werden, auch wenn Sie sie in einem interaktiven Terminal ausführen.S6_FIX_ATTRS_HIDDEN (Standard = 0): Steuert, wie fix-attrs.d -Skripte Dateien und Verzeichnisse verarbeiten.0 : Versteckte Dateien und Verzeichnisse werden ausgeschlossen.1 : Alle Dateien und Verzeichnisse werden verarbeitet.S6_CMD_WAIT_FOR_SERVICES (Standard = 0): Standardmäßig werden beim Start des Containers Dienste in /etc/services.d gestartet und die Ausführung fährt mit dem Starten des user2 Bundles und des CMD fort, sofern einer dieser definiert ist. Wenn S6_CMD_WAIT_FOR_SERVICES ungleich Null ist, wartet der Container -Startsequenz jedoch, bis die Dienste in /etc/services.d bereit sind, bevor sie mit dem Rest der Sequenz fortfahren. Beachten Sie, dass dies nur von Bedeutung ist, wenn die Dienste in /etc/services.d ihre Bereitschaft auf S6 informieren.S6_CMD_WAIT_FOR_SERVICES_MAXTIME (default = 0, dh unendlich): Die maximale Zeit (in Millisekunden) Die Dienste könnten vor der Verarbeitung der CMD -Ausführung vorgehen. Stellen Sie diese Variable auf einen positiven Wert ein, wenn Sie Dienste haben, die möglicherweise auf unbestimmte Zeit blockieren können, und Sie bevorzugen, dass der Container fehlschlägt, wenn nicht alles nach einer bestimmten Zeit abgelaufen ist. Beachten Sie, dass dieser Wert auch die zeitliche Einrichtung der Legacy-Container-Initialisierung ( /etc/cont-init.d ) und Dienste ( /etc/services.d ) enthält. In Versionen von S6-Overlay bis zu 3,1,6,2 betrug der Standard 5000 (fünf Sekunden), aber es verursachte mehr unerwünschte Behälterfehler als Probleme notwendig, damit alle Dienstleistungen erbracht werden.S6_READ_ONLY_ROOT (default = 0): Wenn Sie in einem Container ausgeführt werden, dessen Root-Dateisystem nur schreibgeschützt ist, setzen Sie diese Env auf 1 , um init in die Stufe 2 zu informieren, dass die von Benutzer bereitgestellten Initialisierungsskripte von /etc zu /run/s6/etc kopiert werden soll Es wird versucht, Berechtigungen usw. zu ändern.S6_SYNC_DISKS (default = 0): Setzen Sie diese Umwelt auf 1, um init in die Stufe 3 zu informieren, dass es versuchen sollte, Dateisysteme vor dem Stoppen des Containers zu synchronisieren. Hinweis: Dies synchronisiert wahrscheinlich alle Dateisysteme auf dem Host.S6_STAGE2_HOOK (default = none): Wenn diese Variable existiert, wird der Inhalt als Shell -Auszug interpretiert, der in der frühen Stufe 2 ausgeführt wird, bevor die Dienste gestartet werden. Dies kann beispielsweise verwendet werden, um die Dienstdatenbank dynamisch zur Laufzeit dynamisch zu pflücken, kurz bevor sie kompiliert und ausgeführt wird. Der falsche Wert kann verhindern, dass Ihr Container Ihre Sicherheit ausführt oder gefährdet. Verwenden Sie dies daher nur, wenn Sie genau wissen, was Sie tun. Lassen Sie diese Variable im Zweifel undefiniert.S6_VERBOSITY (Standard = 2): Steuert die Ausführlichkeit von S6-RC und möglicherweise andere Werkzeuge bei Container-Start- und Stoppzeit. Die Standardeinstellung 2 ist normalerweise ausführlich ausführlich: Es wird den Service -Start- und -Onbetrieb aufgelistet. Sie können den Container leiser machen, indem Sie diese Zahl verringern: 1 druckt nur Warnungen und Fehler und 0 druckt nur Fehler. Sie können den Container auch ausführlicher machen, dh Print -Tracing- und Debugug -Informationen werden, indem Sie diese Zahl bis zu 5 erhöhen, aber die Ausgabe wird schnell sehr laut, und die meisten Menschen sollten dies nicht brauchen.S6_CMD_RECEIVE_SIGNALS (default = 0): Entscheidet, ob an den Container gesendete Signale an die PID 1 des Containers oder an die CMD gesendet werden sollten. Wenn Sie beispielsweise einen docker stop ausführen, wird ein Begriffssignal an die PID 1 des Containers gesendet, wodurch die vollständige Container -Shutdown -Sequenz ausgelöst wird. Wenn jedoch ein CMD vorhanden ist Nur, wenn alles andere unten ist und der Container im Begriff ist, zu verlassen. Wenn diese Variable 1 oder mehr beträgt, werden die Signale von PID 1 zum CMD umgeleitet, was bedeutet, dass docker stop stattdessen eine Sigterm an die CMD sendet, und der Container löst nur seine Herunterfahrenverfahren aus, wenn die CMD tot ist. Beachten Sie, dass nur Sigterm, Sigquit, Sigint, Sigusr1, Sigusr2, Sigpwr und Sigwinch umgeleitet werden; Andere Signale werden entweder ignoriert oder können nicht umgeleitet werden und werden notwendigerweise von PID behandelt. Bitte beachten Sie, dass die Verwendung dieser Option möglicherweise verhindern kann, dass interaktive CMDs überhaupt funktionieren - mit anderen Worten, wenn Sie eine interaktive CMD in einem Terminal ausführen 't setze diese Variable; Das sollte jedoch in Ordnung sein, da Sie in diesem Fall bereits interaktive Möglichkeiten haben, Ihre CMD zu stoppen. Wenn Software, die in Ihrem Container ausgeführt wird, syslog erforderlich ist, extrahieren Sie den syslogd-overlay-noarch.tar.xz Tarball: Das gibt Ihnen eine kleine Syslogd-Emulation. Protokolle finden Sie unter verschiedenen Unterverzeichnissen von /var/log/syslogd , beispielsweise werden in /var/log/syslogd/messages/ verzeichnis gefunden, wobei die neuesten Protokolle in /var/log/syslogd/messages/current verfügbar sind /var/log/syslogd/messages/current
