finit
v4.8
Schneller Init für Linux -Systeme. Reverse aus dem Eeepc Fastinit von Claudio Matsuoka - "Lücken mit Frosch -DNA gefüllt ..."
Abbildung 1: Screenshot des endgültigen Booting Alpine Linux (Howto).
Zu den Funktionen gehören:
/etc/rc.local Support/etc/network/interfacesinitctl topsulogin für geschützte Wartungshüllesyslogd logger hatDer Fokus liegt auf kleinen und eingebetteten Systemen, obwohl Finit auch auf Server- und Desktop -Systemen vollständig verwendbar ist. Beispiele finden Sie im Abschnitt/ Abschnitt mit Tutorials für die folgenden Linux -Verteilungen:
HINWEIS: Die Unterstützung verschiedener Linux -Verteilungen bedeutet nicht, dass Finit -Installationen auf allen Architekturen leicht installiert werden. Die gebündelten Install -Skripte sind Beispiele für Standardinstallationen, die auf AMD64 (x86_64) -Systemen getestet wurden. Benutzerdefinierte Setups, z. B. für eingebettete Systeme, finden Sie in einem der folgenden Beispiele auf BuildRoot-basierten Beispielen: Mylinux, Infix oder in der einfachen Br2-Finit-Demo.
Dieses Beispiel /etc/finit.conf kann auch in mehreren .conf -Dateien in /etc/finit.d aufgeteilt werden. Verfügbar, aber noch nicht aktiviert, können Dienste in /etc/finit.d/available platziert und von einem Bediener über das Initctl -Tool aktiviert werden. Siehe die oben genannten Linux -Verteilungen oder MyLinux.
HINWEIS: Zum Finit V4.4 können .Conf -Linien mit dem Standard -Unix -Fortsetzung von Continuation (
) aufgetrennt werden. Auch nachfolgende Kommentare werden jetzt unterstützt. Letzteres bedeutet, dass Sie allen Hashes entkommen müssen, die in Richtlinien und Beschreibungen verwendet werden (#). Weitere Informationen zu diesem und Beispielen finden Sie im Handbuch end.conf (5) oder doc/config.md.
# Fallback if /etc/hostname is missing
host default
# Runlevel to start after bootstrap, 'S', default: 2
# runlevel 2
# Support for setting global environment variables, using foo=bar syntax
# be careful though with variables like PATH, SHELL, LOGNAME, etc.
# PATH=/usr/bin:/bin:/usr/sbin:/sbin
# Max file size for each log file: 100 kiB, rotate max 4 copies:
# log => log.1 => log.2.gz => log.3.gz => log.4.gz
log size=100k count=4
# Services to be monitored and respawned as needed
service [S12345] env:-/etc/conf.d/watchdog watchdog $WATCHDOG_OPTS $WATCHDOG_DEV -- System watchdog daemon
service [S12345] env:-/etc/conf.d/syslog syslogd -n $SYSLOGD_OPTS -- System log daemon
service [S12345] < pid /syslogd> env:-/etc/conf.d/klogd klogd -n $KLOGD_OPTS -- Kernel log daemon
service [2345] env:-/etc/conf.d/lldpd lldpd -d $LLDPD_OPTS -- LLDP daemon (IEEE 802.1ab)
# The BusyBox ntpd does not use syslog when running in the foreground
# So we use this trick to redirect stdout/stderr to a log file. The
# log file is rotated with the above settings. The condition declares
# a dependency on a system default route (gateway) to be set. A single
# <!> at the beginning means ntpd does not respect SIGHUP for restart.
service [2345] log:/var/log/ntpd.log <!net/route/default> ntpd -n -l -I eth0 -- NTP daemon
# For multiple instances of the same service, add :ID somewhere between
# the service/run/task keyword and the command.
service :80 [2345] merecat -n -p 80 /var/www -- Web server
service :8080 [2345] merecat -n -p 8080 /var/www -- Old web server
# Alternative method instead of below runparts, can also use /etc/rc.local
# sysv [S] /etc/init.d/keyboard-setup -- Setting up preliminary keymap
# sysv [S] /etc/init.d/acpid -- Starting ACPI Daemon
# task [S] /etc/init.d/kbd -- Preparing console
# Hidden from boot progress, using empty `--` description
# sysv [S] /etc/init.d/keyboard-setup --
# sysv [S] /etc/init.d/acpid --
# task [S] /etc/init.d/kbd --
# Run start scripts from this directory
# runparts /etc/start.d
# Virtual consoles run BusyBox getty, keep kernel default speed
tty [12345] /sbin/getty -L 0 /dev/tty1 linux nowait noclear
tty [2345] /sbin/getty -L 0 /dev/tty2 linux nowait noclear
tty [2345] /sbin/getty -L 0 /dev/tty3 linux nowait noclear
# Use built-in getty for serial port and USB serial
# tty [12345] /dev/ttyAMA0 noclear nowait
# tty [12345] /dev/ttyUSB0 noclear
# Just give me a shell, I need to debug this embedded system!
# tty [12345] console noclear nologin Der service Streamza sowie task , run und andere werden vollständig in doc/config.md beschrieben. Hier finden Sie einen kurzen Überblick über einige der häufigsten Komponenten, die zum Starten eines Unix -Daemon erforderlich sind:
service [LVLS] <COND> log env:[-]/etc/default/daemon daemon ARGS -- Daemon daemon
^ ^ ^ ^ ^ ^ ^ ^
| | | | | | | `---------- Optional description
| | | | | | `------------------ Daemon arguments
| | | | | `------------------------- Path to daemon
| | | | `---------------------------------------------------- Optional env. file
| | | `-------------------------------------------------------- Redirect output to log
| | `--------------------------------------------------------------- Optional conditions
| `---------------------------------------------------------------------- Optional Runlevels
`------------------------------------------------------------------------------ Monitored application
Einige Komponenten sind optional: Runlevel (en), Bedingungen (n) und Beschreibung, so dass es einfach ist, einfache Startskripte zu erstellen und dennoch auch für fortgeschrittenere Verwendungen möglich zu sein:
service /usr/sbin/sshd -D
Abhängigkeiten werden unter Verwendung von Bedingungen behandelt. Eine der häufigsten Bedingungen besteht darin, auf die verfügbare grundlegende Networking zu warten:
service <net/route/default> nginx -- High performance HTTP server
Hier ist ein weiteres Beispiel, in dem wir Finit anweisen, die Belegebox ntpd nicht zu starten, bis syslogd ordnungsgemäß begonnen hat. Finit wartet darauf, dass syslogd standardmäßig seine PID -Datei erstellt /var/run/syslogd.pid .
service [2345] log <!pid/syslogd> ntpd -n -N -p pool.ntp.org
service [S12345] syslogd -n -- Syslog daemon
Beachten Sie das Keyword log , BusyBox ntpd verwendet stderr zum Anmelden beim Ausführen im Vordergrund. Mit log leitet stdout + stderr in den Systemprotokoll -Daemon mit dem Befehlszeilen logger(1) Tool um.
Ein Dienst oder eine Aufgabe kann mehrere Abhängigkeiten auflistet. Hier warten wir, bis sowohl syslogd begonnen hat als auch grundlegende Vernetzung:
service [2345] log <pid/syslogd,net/route/default> ntpd -n -N -p pool.ntp.org
Wenn eine Bedingung fehlschlägt, z. B. ein Networking -Verlust, wird ntpd gestoppt und sobald es wieder auftritt, wird ntpd automatisch neu gestartet.
HINWEIS: Stellen Sie sicher, dass Daemons sich nicht von der kontrollierenden TTY, normalerweise einem -n oder -f -Flag, oder -D wie im Fall von OpenSSH. Wenn es sich selbst löst, kann Finit es nicht überwachen und versuchen stattdessen, es neu zu starten.
Prozessaufsicht
Starten, überwachen und starten Sie sie neu, falls sie scheitern sollten.
Getty
Finit unterstützt externe Getty, verfügt jedoch auch über ein begrenztes integriertes Getty, das für wirklich kleine Systeme nützlich ist. Ein Getty richtet die TTY ein und wartet auf die Benutzereingabe, bevor sie an /bin/login übergeben, was für die Behandlung der tatsächlichen Authentifizierung verantwortlich ist.
tty [12345] /dev/tty1 nowait linux
tty [12345] /dev/ttyAMA0 noclear vt100
tty [12345] /sbin/getty -L /dev/ttyAMA0 vt100
Benutzer von eingebetteten Systemen möchten möglicherweise eine automatische serielle Konsole mit dem speziellen @console -Gerät aktivieren. Dies funktioniert unabhängig davon, ob das System ttyS0 , ttyAMA0 , ttyMXC0 oder irgendetwas anderes verwendet. Finit int es heraus, indem SYSFS: /sys/class/tty/console/active abfragt.
tty [12345] @console linux noclear
Beachten Sie die optionalen Flaggen von noclear , nowait und nologin . Letzteres dient zum vollständigen Überspringen des Anmeldevorgangs. Weitere Informationen finden Sie unter doc/config.md.
Runlevels
Die Unterstützung für Runlevels im SYSV Init-Stil ist im gleichen minimalen Stil wie alles andere in Finitien erhältlich. Die [2345] -Syntax kann auf Service, Aufgabe, Run und Ty Stropa angewendet werden.
Reservierte Runlevels sind 0 und 6, halten und starten neu, genau wie Sysv init. Runlevel 1 kann frei konfiguriert werden, es wird jedoch empfohlen, als System mit einem Benutzer-User Runlevel aufbewahrt zu werden, da Finit hier nicht mit dem Networking beginnt. Die konfigurierte runlevel NUM von /etc/finit.conf ändert sich endgültig nach Bootstrap, es sei denn, 'Single' (oder 'S') ist auf der Kernel Cmdline angegeben. In diesem Fall wird Runlevel 1 gestartet.
Alle Dienste in Runlevel S) werden zuerst gestartet, gefolgt von der gewünschten Laufzeit Runlevel. Run -Aufgaben in Runlevel S können unter Verwendung von run [S] cmd nacheinander gestartet werden. Das Ändern von Runlevels zur Laufzeit erfolgt wie bei jedem anderen Init, z. B. init 4 , aber auch das erweiterte intictl -Tool.
Bedingungen
Wie bereits erwähnt, verfügt Finit über ein fortschrittliches Abhängigkeitssystem, um die Synchronisation zu verarbeiten, die als Bedingungen bezeichnet wird. Es kann in vielerlei Hinsicht verwendet werden; Abhängig von einem anderen Service, der Verfügbarkeit von Netzwerk usw.
Ein wirklich cooles Beispiel, das für eingebettete Systeme nützlich ist, ist es, bestimmte Skripte auszuführen, wenn eine Platine eine bestimmte Funktion in seinem Gerätebaum enthält. Bei Bootstrap führen wir das folgende ident aus:
#! /bin/sh
conddir=/var/run/finit/cond/hw/model
dtmodel=/sys/firmware/devicetree/base/model
if ! test -e $dtmodel ; then
exit 0
fi
model= $( cat $dtmodel | tr " [A-Z] " " [a-z]- " )
mkdir -p $conddir && ln -s ../../reconf $conddir / $model Vorausgesetzt, der Gerätebaumknoten existiert und eine Zeichenfolge ist, können wir dann den Zustand <hw/model/foo> verwenden, wenn andere Skripte gestartet werden. Hier ist ein Beispiel:
run [S] /path/to/ident --
task [2] <hw/model/foo> /path/to/foo-init -- Initializing Foo board
Beachten Sie den Trick mit einer leeren Beschreibung, um den Anruf zu verbergen, um die Finit -Fortschrittsausgabe zu
ident.
Plugins
Plugins können die Funktionen von Finit und die verschiedenen Phasen des Boot -Prozesses und zur Laufzeit erweitern . Plugins werden in C geschrieben und in eine dynamische Bibliothek zusammengestellt, die automatisch nach Finit am Start geladen wird. Ein grundlegender Satz von Plugins wird im plugins/ Verzeichnis gebündelt.
Fähigkeiten:
Erweiterungen und Funktionen, die nicht nur mit dem zu tun haben, was An /sbin/init zum Starten eines Systems benötigt, sind als Set von Plugins erhältlich, die entweder in den Startprozess einbinden oder auf verschiedene E/A reagieren.
Weitere Informationen finden Sie unter doc/plugins.md.
Automatisches Nachladen
Standardmäßig sind Finit -Monitore /etc/finit.d/ und /etc/finit.d/enabled/ Änderungen an .conf -Dateien registrieren. Um eine Änderung zu aktivieren, muss der Benutzer initctl reload aufrufen, das alle geänderten Dateien neu lädt, alle entfernten Dienste gestoppt, neue gestartet und alle geänderten neu gestartet werden. Wenn sich die Befehlszeilenargumente eines Dienstes geändert haben, wird der Prozess beendet und dann erneut mit den aktualisierten Argumenten gestartet. Wenn die Argumente nicht geändert wurden und der Prozess Seufzer unterstützt, erhält der Prozess eher einen Seufzer als beendet und gestartet.
Für einige Anwendungsfälle erzeugt der zusätzliche Schritt des Aufrufens initctl reload einen unnötigen Overhead, der zur Build-Time mithilfe voneinander entfernt werden kann:
configure --enable-auto-reload
CGROUPS
Finit unterstützt CGroups V2 und wird mit den folgenden Standardgruppen ausgestattet, in denen Dienste und Benutzersitzungen eingesetzt werden:
/sys/fs/cgroup
|-- init/ # cpu.weight:100
|-- system/ # cpu.weight:9800
`-- user/ # cpu.weight:100
Finit selbst und seine Helfer-Skripte und -Dienste werden in der obersten Blattknotengruppe init/ platziert, die ebenfalls reserviert ist.
Alle Prozesse für Auslauf/Task/Service/SYSV werden in der Untergruppe in system/ in ihre eigene Untergruppe platziert. Der Name jeder Untergruppe stammt aus der jeweiligen .conf Datei von /etc/finit.d .
Alle Getty/ Tty-Prozesse werden in ihrer eigenen Untergruppe im user/ in ihre eigene Untergruppe platziert. Der Name jeder Untergruppe stammt aus dem Benutzernamen.
Es gibt auch eine vierte Gruppe, die root . Es ist auch reserviert und hauptsächlich für RT -Aufgaben bestimmt. Wenn Sie RT -Aufgaben haben, müssen sie in ihrer Dienstleistung wie folgt als solche deklariert werden:
service [...] <...> cgroup.root /path/to/foo args -- description
oder
cgroup.root
service [...] <...> /path/to/foo args -- description
service [...] <...> /path/to/bar args -- description
Weitere Informationen finden Sie unter DOC/CONFIG.MD, z. B. die Konfiguration von Grenzwerten pro Gruppen.
Das initctl -Tool verfügt über drei Befehle, um das Setup und die Überwachung von CGroups zu debuggen und zu optimieren. Weitere Informationen finden Sie in den Befehlen ps , top und cgroup .
HINWEIS: Systeme, die keine CGroups unterstützen, insbesondere Version 2, werden automatisch erkannt. Bei solchen Systemen wird die obige Funktionalität beim BOOT frühzeitig deaktiviert.
Am Ende des Bootes, wenn alle Bootstrap ( S ) Aufgaben und Dienste begonnen haben, aber nicht mit dem Networking, ruft Finit seinen integrierten Befehl Run-Parts (8) auf einem konfigurierten runparts <DIR> -Verzeichnis auf. Dies geschieht kurz vor dem Wechsel zum konfigurierten Runlevel (Standard 2). (Das Netzwerk ist kurz vor dem Wechsel vom Einzelbenutzermodus aktiviert.)
runparts /etc/rc.d/ Gleich nach der Änderung des Runlevel, wenn alle Dienste ordnungsgemäß gestartet wurden, wird /etc/rc.local aufgerufen.
Für rc.local ist keine Konfiguration Streamza in /etc/finit.conf erforderlich. Wenn es existiert und ein ausführbares Shell -Skript ist, ruft es am Ende des Starts auf, bevor er den HOOK_SYSTEM_UP aufruft. Weitere Informationen finden Sie in Doc/Plugins.md.
Es ist nicht möglich, Finit über Signale aufzurufen oder initctl in RunParts oder /etc/rc.local Skript zu verwenden. Dies, weil Finit einzelner Thread ist und diese Skripte am Ende von Runlevel S auf blockierende Weise aufruft. Zu diesem Zeitpunkt wurde die Ereignisschleife noch nicht gestartet.
Die Veranstaltungsschleife ist das Ganze, das Finit aufgebaut hat, mit Ausnahme von Runlevel S, das eine langsame Prozession durch viele Einrichtungen bleibt, mit ein paar Haken und Blockieren von Aufrufen von externen Skripten.
Es sind jedoch nicht alle initctl -Befehle verboten. Unterstützte Befehle:
inictl cond : Nur den Betrieb von Dateien in /run/finit/cond betreibeninitctl enable/disable : Aktiviert Auslauf/Task/Service wird auf der Runlevel -Änderung von s zu 2 aktiviertinitctl touch/show/create/delete/list : create , vorausgesetzt, der nicht-interaktive Modus wird verwendet, und Änderungen wirken sich wieder in der Runlevel-Änderung direkt nach dem Bootstrap wirksaminitctl -f reboot/poweroff/halt : vorausgesetzt, das -f -Flag wird verwendet, um Direktkernelbefehle zu erzwingen Beispiel: Sie können einen usr/ Bedingung in /etc/rc.local festlegen und eine Dienst/Aufgabe in Runlevel 2 haben, die davon abhängt.
Die grundlegende Unterstützung für Runlevels ist in Finit von V1.8 enthalten. Standardmäßig werden alle Dienste, Aufgaben, Befehle und TTYs ausführen, die ohne eine Reihe von Runlevels aufgelistet sind, erhalten einen Standardsatz [234] zugewiesen. Der Standard -Runlevel nach dem Start ist 2.
Finit unterstützt Runlevels 0-9 und S, wobei 0 für Halt, 6 Neustart und S für Dienste reserviert sind, um nur am Bootstrap zu laufen. Runlevel 1 ist die einzelnen Benutzerebene, bei der normalerweise kein Netzwerk aktiviert ist. Endlich ist dies eher eine Richtlinie für den Benutzer zu definieren. Normalerweise werden nur Runlevels 1-6 verwendet, und noch häufiger wird nur der Standard-Runlevel verwendet.
Um einen zulässigen Satz von Runlevels für einen service , einen Befehl, task run , oder tty , fügen Sie [NNN] zu Ihrem /etc/finit.conf wie folgt hinzu:
service [S12345] syslogd -n -x -- System log daemon
run [S] /etc/init.d/acpid start -- Starting ACPI Daemon
task [S] /etc/init.d/kbd start -- Preparing console
service [S12345] <pid/syslogd> klogd -n -x -- Kernel log daemon
tty [12345] /dev/tty1
tty [2] /dev/tty2
tty [2] /dev/tty3
tty [2] /dev/tty4
tty [2] /dev/tty5
tty [2] /dev/tty6
In diesem Beispiel wird Syslogd zuerst parallel gestartet, und dann wird ACPID unter Verwendung eines herkömmlichen SYSV -Init -Skripts aufgerufen. Es wird mit dem Befehl run aufgerufen, was bedeutet, dass der folgende Aufgabebefehl das Starten des KBD -Skripts erst aufgerufen wird, wenn das ACPID -Init -Skript vollständig abgeschlossen ist. Anschließend wird das Tastatur -Setup -Skript parallel zu KLogd als überwachten Dienst aufgerufen.
Auch hier werden Aufgaben und Dienste parallel gestartet, während Run -Befehle in der aufgelisteten Reihenfolge aufgerufen werden und die nachfolgenden Befehle erst gestartet werden, wenn ein Run -Befehl abgeschlossen ist. Außerdem werden Aufgaben- und Auslaufbefehle in einer Shell ausgeführt, sodass Rohre und Umleitungen verwendet werden können.
Die folgenden Beispiele veranschaulichen dies. Bootstrap -Aufgabe und Ausführungsbefehle werden ebenfalls entfernt, wenn sie abgeschlossen sind. initctl show wird nicht aufgeführt.
task [S] echo "foo" | cat >/tmp/bar
run [S] echo "$HOME" >/tmp/secret
Das Umschalten zwischen Runlevels kann durch Aufrufen von Init mit einem einzigen Argument, z. B. init 5 , oder initctl runlevel 5 durchgeführt werden, wechseln beide zu Runlevel 5. Beim Ändern von Runlevels Finit wird auch automatisch alle .conf -Dateien in /etc/finit.d/ neu geladen. Wenn Sie also eine neue Systemkonfiguration festlegen möchten, wechseln Sie zu Runlevel 1, ändern Sie alle Konfigurationsdateien im System und berühren Sie alle .conf -Dateien in /etc/finit.d bevor Sie wieder zum vorherigen Runlevel zurückkehren. Auf diese Weise kann endkulär die alten Dienste stoppen und neue für Sie starten, ohne das System neu zu starten.
Traditionell wird das Neustart und Stoppen eines UNIX -Systems durch Ändern seiner Runneigung durchgeführt. Finit wird mit einem eigenen Werkzeug ausgestattet, das: shutdown , reboot , poweroff und suspend , aber auch das im nächste Abschnitt beschriebene initctl -Tool.
Aus Kompatibilitätsgründen hört Finit den gleichen Signalen wie BusyBox Init auf. Dies ist nicht zu 100% kompatibel mit SYSV INIT, aber eindeutig die häufigere Kombination für Finit. Weitere Informationen finden Sie unter DOC/Signals.md.
Finit implementiert auch eine moderne API für den Abfragebatus und startete/stoP -Dienste, die als initctl bezeichnet werden. Im Gegensatz zu telinit kehrt das initctl -Tool erst zurück, wenn der angegebene Befehl vollständig abgeschlossen ist.
Usage: initctl [OPTIONS] [COMMAND]
Options:
-b, --batch Batch mode, no screen size probing
-c, --create Create missing paths (and files) as needed
-f, --force Ignore missing files and arguments, never prompt
-h, --help This help text
-j, --json JSON output in 'status' and 'cond' commands
-1, --once Only one lap in commands like 'top'
-p, --plain Use plain table headings, no ctrl chars
-q, --quiet Silent, only return status of command
-t, --no-heading Skip table headings
-v, --verbose Verbose output
-V, --version Show program version
Commands:
debug Toggle Finit (daemon) debug
help This help text
version Show program version
ls | list List all .conf in /etc/finit.d
create <CONF> Create .conf in /etc/finit.d/available
delete <CONF> Delete .conf in /etc/finit.d/available
show <CONF> Show .conf in /etc/finit.d/available
edit <CONF> Edit .conf in /etc/finit.d/available
touch <CONF> Change .conf in /etc/finit.d/available
enable <CONF> Enable .conf in /etc/finit.d/available
disable <CONF> Disable .conf in /etc/finit.d/enabled
reload Reload *.conf in /etc/finit.d (activate changes)
cond set <COND> Set (assert) user-defined conditions +usr/COND
cond get <COND> Get status of user-defined condition, see $? and -v
cond clear <COND> Clear (deassert) user-defined conditions -usr/COND
cond status Show condition status, default cond command
cond dump [TYPE] Dump all, or a type of, conditions and their status
log [NAME] Show ten last Finit, or NAME, messages from syslog
start <NAME>[:ID] Start service by name, with optional ID
stop <NAME>[:ID] Stop/Pause a running service by name
reload <NAME>[:ID] Reload service as if .conf changed (SIGHUP or restart)
This allows restart of run/tasks that have already run
Note: Finit .conf file(s) are *not* reloaded!
restart <NAME>[:ID] Restart (stop/start) service by name
signal <NAME>[:ID] <S> Send signal S to service by name, with optional ID
ident [NAME] Show matching identities for NAME, or all
status <NAME>[:ID] Show service status, by name
status Show status of services, default command
cgroup List cgroup config overview
ps List processes based on cgroups
top Show top-like listing based on cgroups
plugins List installed plugins
runlevel [0-9] Show or set runlevel: 0 halt, 6 reboot
reboot Reboot system
halt Halt system
poweroff Halt and power off system
suspend Suspend system
utmp show Raw dump of UTMP/WTMP db
Für Dienste, die SIGHUP nicht unterstützt, muss die <!> Notation in der .conf -Datei verwendet werden, um Finit zu sagen, dass er reload und mit Änderungen runlevel gestartet werden soll. Wenn <> mehr Bedingungen enthält, beeinflussen diese auch die Aufrechterhaltung eines Dienstes.
Hinweis: Auch wenn es möglich ist, Dienste zu starten, die nicht in den aktuellen Runlevel gehören, werden diese Dienste nicht automatisch durch endgültiges Versand wiederhergestellt, wenn sie beenden (Absturz). Wenn der Runlevel 2 ist, wird der folgende DropBear -SSH -Service nicht neu gestartet, wenn er getötet oder ausgeht.
Der status ist die Standardeinstellung. Er zeigt einen schnellen Überblick über alle überwachten Run/Task/-Dienste an. Hier nennen wir initctl -p , geeignet für Skript- und Dokumentation:
alpine:~# initctl -p
PID IDENT STATUS RUNLEVELS DESCRIPTION
======================================================================
1506 acpid running [---2345----] ACPI daemon
1509 crond running [---2345----] Cron daemon
1489 dropbear running [---2345----] Dropbear SSH daemon
1511 klogd running [S-12345----] Kernel log daemon
1512 ntpd running [---2345----] NTP daemon
1473 syslogd running [S-12345----] Syslog daemon
alpine:~# initctl -pv
PID IDENT STATUS RUNLEVELS COMMAND
======================================================================
1506 acpid running [---2345----] acpid -f
1509 crond running [---2345----] crond -f -S $CRON_OPTS
1489 dropbear running [---2345----] dropbear -R -F $DROPBEAR_OPTS
1511 klogd running [S-12345----] klogd -n $KLOGD_OPTS
1512 ntpd running [---2345----] ntpd -n $NTPD_OPTS
1473 syslogd running [S-12345----] syslogd -n
Die Umgebungsvariablen für jedes der oben genannten Dienste werden im Fall von Alpine Linux, /etc/conf.d/ gelesen. Andere Verteilungen können andere Verzeichnisse haben, z. B. Debian -Nutzung /etc/default/ .
Der status nimmt einen optionalen NAME:ID -Argument an. Hier überprüfen wir den Status von dropbear , der nur eine Instanz in diesem System enthält:
alpine:~# initctl -p status dropbear
Status : running
Identity : dropbear
Description : Dropbear SSH daemon
Origin : /etc/finit.d/enabled/dropbear.conf
Environment : -/etc/conf.d/dropbear
Condition(s):
Command : dropbear -R -F $DROPBEAR_OPTS
PID file : !/run/dropbear.pid
PID : 1485
User : root
Group : root
Uptime : 2 hour 46 min 56 sec
Runlevels : [---2345----]
Memory : 1.2M
CGroup : /system/dropbear cpu 0 [100, max] mem [--.--, max]
|- 1485 dropbear -R -F
|- 2634 dropbear -R -F
|- 2635 ash
`- 2652 initctl -p status dropbear
Apr 8 12:19:49 alpine authpriv.info dropbear[1485]: Not backgrounding
Apr 8 12:37:45 alpine authpriv.info dropbear[2300]: Child connection from 192.168.121.1:47834
Apr 8 12:37:46 alpine authpriv.notice dropbear[2300]: Password auth succeeded for 'root' from 192.168.121.1:47834
Apr 8 12:37:46 alpine authpriv.info dropbear[2300]: Exit (root) from <192.168.121.1:47834>: Disconnect received
Apr 8 15:02:11 alpine authpriv.info dropbear[2634]: Child connection from 192.168.121.1:48576
Apr 8 15:02:12 alpine authpriv.notice dropbear[2634]: Password auth succeeded for 'root' from 192.168.121.1:48576
Finit kann sowohl auf Desktop/Server -Systemen mit UDEV- als auch eingebetteten Systemen ausgeführt werden, die normalerweise mit Busybox MDEV geliefert werden. Einige Systeme verfügen heute anstelle des ursprünglichen UDEV, Endsonden für alle zur Laufzeit und erwarten /dev/ um ein beschreibbares Dateisystem, das devtmpfs ist. Es ist auch möglich, bei Bedarf auf einem staatlichen Einrichten /dev auszuführen. Es ist jedoch keine gute Idee, dass UDEV und MDEV gleichzeitig installiert werden. Dies führt zu unvorhersehbaren Ergebnissen.
Bei Boot Finit Calls entweder mdev oder udevd , um /dev zu füllen, wird dies etwas anders gemacht. Auf Systemen mit Udev möchten Sie möglicherweise zu Beginn Ihres /etc/finit.conf die folgende One-Shot-Aufgabe hinzufügen:
run [S] udevadm settle --timeout=120 -- Waiting for udev
Finit verfügt über ein integriertes Getty für TTYs, erfordert jedoch eine Arbeit /bin/login oder /bin/sh , wenn keine TTYs in /etc/finit.conf konfiguriert sind.
Für ein voll operatives System /var , /run und /tmp müssen in /etc/fstab ordnungsgemäß eingerichtet werden - das am Start überholt wird.
Dieses Projekt basiert auf dem ursprünglichen Finit von Claudio Matsuoka, das aus den Syscalls des EEEPC Fastinit umgekehrt wurde - "Lücken, die mit Frosch -DNA gefüllt sind ..."
Finit wird von Joachim Wiberg in GitHub entwickelt und aufrechterhalten. Bitte stellen Sie Fehlerberichte vor, klonen Sie diese oder senden Sie Pull -Anfragen für Fehlerbehebungen und vorgeschlagene Erweiterungen.
