finit
v4.8
Init rapide pour les systèmes Linux. Ingénieur à la recherche de l'EEEPC Fastinit par Claudio Matsuoka - "Des lacunes remplies d'ADN de grenouille…"
Figure 1: Capture d'écran du botter du finit Alpine Linux (Howto).
Les fonctionnalités incluent:
/etc/rc.local Support/etc/network/interfacesinitctl topsulogin groupée pour une coque de maintenance protégéesyslogd , voir le projet Sysklogd recommandé pour une intégration de journalisation complète et comment se connecter au tampon d'anneau de noyau à partir de scripts à l'aide loggerL'accent est mis sur les systèmes petits et intégrés, bien que Finit soit également entièrement utilisable sur les systèmes de serveur et de bureau. Pour les exemples de travail, consultez la section contrib / avec des tutoriels pour les distributions Linux suivantes:
Remarque: La prise en charge de diverses distributions Linux ne signifie pas que Finit s'installe facilement sur toutes les architectures. Les scripts d'installation groupés sont des exemples d'installations standard, testés sur des systèmes AMD64 (x86_64). Les configurations personnalisées, par exemple, pour les systèmes embarqués, peuvent être trouvées dans l'un des exemples basés sur Buildroot suivants: MyLinux, Infix ou le Plain BR2-finit-Demo.
Cet exemple /etc/finit.conf peut également être divisé dans plusieurs fichiers .conf dans /etc/finit.d . Les services disponibles, mais pas encore activés, peuvent être placés dans /etc/finit.d/available et activés par un opérateur à l'aide de l'outil INITCTL. Voir les distributions Linux mentionnées ci-dessus, ou MyLinux.
Remarque: En ce qui concerne le finit v4.4, les lignes .Conf peuvent être brisées en utilisant le caractère standard de continuation UNIX (
), les commentaires de fin sont désormais pris en charge. Ce dernier signifie que vous devez échapper à tous les hachages utilisés dans les directives et les descriptions (#). Pour en savoir plus à ce sujet et sur des exemples, consultez le manuel finit.conf (5) ou 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 La strophe service , ainsi que task , run et les autres sont décrites en totalité dans doc / config.md. Voici un aperçu rapide de certains des composants les plus courants nécessaires pour démarrer un démon Unix:
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
Certains composants sont facultatifs: le (s) runlevel (s), les conditions et la description, ce qui facilite la création de scripts de démarrage simples et toujours possible pour des utilisations plus avancées:
service /usr/sbin/sshd -D
Les dépendances sont gérées à l'aide de conditions. L'une des conditions les plus courantes est d'attendre que le réseautage de base soit disponible:
service <net/route/default> nginx -- High performance HTTP server
Voici un autre exemple où nous demandons à Finit de ne pas démarrer Busybox ntpd jusqu'à ce que syslogd ait démarré correctement. Finit attend que syslogd crée son fichier PID, par défaut /var/run/syslogd.pid .
service [2345] log <!pid/syslogd> ntpd -n -N -p pool.ntp.org
service [S12345] syslogd -n -- Syslog daemon
Remarquez le mot clé log , BusyBox ntpd utilise stderr pour la journalisation lors de l'exécution au premier plan. Avec log finit redirige stdout + stderr vers le démon du journal système à l'aide de l'outil logger(1) .
Un service, ou tâche, peut avoir plusieurs dépendances répertoriées. Ici, nous attendons que Syslogd ait commencé et syslogd les réseaux de base soient en place:
service [2345] log <pid/syslogd,net/route/default> ntpd -n -N -p pool.ntp.org
Si l'une ou l'autre condition échoue, par exemple la perte de réseautage, ntpd est arrêté et dès qu'il revient à nouveau ntpd est redémarré automatiquement.
Remarque: assurez-vous que les démons ne se débarquent pas et ne se détachent pas du tty de contrôle, généralement un drapeau -n ou -f , ou -D comme dans le cas d'OpenSSH ci-dessus. S'il se détache, Finit ne peut pas le surveiller et essaiera plutôt de le redémarrer.
Supervision de traitement
Démarrer, surveiller et redémarrer les services s'ils échouent.
Getty
Finit prend en charge Getty externe, mais est également livré avec un Getty intégré limité, utile pour des systèmes vraiment petits. Un Getty configure le TTY et attend la saisie de l'utilisateur avant de remettre à /bin/login , qui est responsable de la gestion de l'authentification réelle.
tty [12345] /dev/tty1 nowait linux
tty [12345] /dev/ttyAMA0 noclear vt100
tty [12345] /sbin/getty -L /dev/ttyAMA0 vt100
Les utilisateurs de systèmes embarqués peuvent souhaiter activer la console série automatique avec le périphérique @console spécial. Cela fonctionne malgré le temps que le système utilise ttyS0 , ttyAMA0 , ttyMXC0 ou autre chose. Finit le figure en interrogeant sysfs: /sys/class/tty/console/active .
tty [12345] @console linux noclear
Remarquez les drapeaux facultatifs noclear , nowait et nologin . Ce dernier est pour sauter entièrement le processus de connexion. Pour plus d'informations, voir doc / config.md.
Couleurs
La prise en charge des niveaux de coulée de style SYSV est disponible, dans le même style minimal que tout le reste de Finit. La syntaxe [2345] peut être appliquée aux strophes de service, de tâche, d'exécution et de tty.
Les niveaux coulants réservés sont 0 et 6, s'arrêtez et redémarrez, respectivement, tout comme SYSV INIT. RunLevel 1 peut être configuré librement, mais il est recommandé d'être conservé en tant que niveau de course à utilisateur unique, car Finit ne commencera pas à réseauter ici. Le runlevel NUM configuré de /etc/finit.conf est ce que le finit se transforme après bootstrap, à moins que «célibataire» (ou «») ne soit donné sur le noyau CMDline, auquel cas RunLevel 1 est démarré.
Tous les services dans RunLevel S) sont démarrés en premier, suivis de la course de course à temps d'exécution souhaitée. Les tâches d'exécution dans les niveaux de course peuvent être démarrées en séquence en utilisant run [S] cmd . La modification des coureurs à l'exécution est effectuée comme n'importe quelle autre init, par exemple init 4 , mais également en utilisant l'outil intictl le plus avancé.
Conditions
Comme mentionné précédemment, Finit a un système de dépendance avancé pour gérer la synchronisation, appelés conditions. Il peut être utilisé de plusieurs manières; dépendent d'un autre service, de la disponibilité du réseau, etc.
Un exemple vraiment cool utile pour les systèmes embarqués consiste à exécuter certains scripts si une carte a une certaine fonctionnalité codée dans son arborescence d'appareil. Chez Bootstrap, nous exécutons le script ident suivant:
#! /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 À condition que le nœud d'arborescence de périphérique existe et est une chaîne, nous pouvons ensuite utiliser la condition <hw/model/foo> lors du démarrage d'autres scripts. Voici un exemple:
run [S] /path/to/ident --
task [2] <hw/model/foo> /path/to/foo-init -- Initializing Foo board
Remarquez l'astuce avec une description vide pour masquer l'appel à
identdans la sortie de progression du finit.
Plugins
Les plugins peuvent étendre les fonctionnalités du finit et du crochet dans les différentes étapes du processus de démarrage et au moment de l'exécution. Les plugins sont écrits en C et compilés dans une bibliothèque dynamique chargée automatiquement par finit au démarrage. Un ensemble de plugins de base est regroupé dans les plugins/ répertoire.
Capacités:
Les extensions et les fonctionnalités non liées à ce dont AN /sbin/init ont besoin pour démarrer un système sont disponibles en tant que plugins qui s'accrochent au processus de démarrage ou répondent à diverses E / S.
Pour plus d'informations, voir Doc / Plugins.md.
Rechargement automatique
Par défaut, les moniteurs finiteurs /etc/finit.d/ et /etc/finit.d/enabled/ enregistrent toutes les modifications des fichiers .conf . Pour activer un modification, l'utilisateur doit appeler initctl reload , qui recharge tous les fichiers modifiés, arrête tous les services supprimés, en lance de nouveaux et en redémarre tous les modifications. Si les arguments de ligne de commande d'un service ont changé, le processus sera résilié puis recommencé avec les arguments mis à jour. Si les arguments n'ont pas été modifiés et que le processus prend en charge SIGHUP, le processus recevra un sighup plutôt que de se terminer et de démarrer.
Pour certaines cas d'utilisation, l'étape supplémentaire d'appeler initctl reload crée une surcharge inutile, qui peut être supprimée au moment de la construction en utilisant:
configure --enable-auto-reload
Troupes
Finit prend en charge CGROUPS V2 et est livré avec les groupes par défaut suivants dans lesquels les services et les sessions utilisateur sont placés:
/sys/fs/cgroup
|-- init/ # cpu.weight:100
|-- system/ # cpu.weight:9800
`-- user/ # cpu.weight:100
Le finit lui-même et ses scripts et services d'assistance sont placés dans le groupe de nœuds à feuilles de haut niveau init/ , qui est également réservé .
Tous les processus d'exécution / tâche / service / sysv sont placés dans leur propre sous-groupe dans system/ . Le nom de chaque sous-groupe est tiré du fichier .conf respectif de /etc/finit.d .
Tous les processus Getty / Tty sont placés dans leur propre sous-groupe dans user/ . Le nom de chaque sous-groupe est tiré du nom d'utilisateur.
Un quatrième groupe existe également, le groupe root . Il est également réservé et principalement destiné aux tâches RT. Si vous avez des tâches RT, ils doivent être déclarés en tant que tels dans leur service Stanza comme ceci:
service [...] <...> cgroup.root /path/to/foo args -- description
ou
cgroup.root
service [...] <...> /path/to/foo args -- description
service [...] <...> /path/to/bar args -- description
Voir doc / config.md pour plus d'informations, par exemple, comment configurer les limites par groupe.
L'outil initctl propose trois commandes pour aider à déboguer et à optimiser la configuration et la surveillance des CGROUP. Voir les commandes ps , top et cgroup pour plus de détails.
Remarque: les systèmes qui ne prennent pas en charge les CGROUP, en particulier la version 2, sont automatiquement détectés. Sur ces systèmes, la fonctionnalité ci-dessus est désactivée tôt au démarrage.
À la fin du démarrage, lorsque toutes les tâches et services de bootstrap ( S ) ont commencé, mais pas de mise en réseau, Finit appelle sa commande Run-Parts (8) intégrée sur n'importe quel répertoire runparts <DIR> configuré. Cela se produit juste avant de passer au niveau du runlevel configuré (par défaut 2). (La mise en réseau est activée juste avant de passer du mode utilisateur unique.)
runparts /etc/rc.d/ Juste après la modification du niveau du couloir lorsque tous les services ont commencé correctement, /etc/rc.local est appelé.
Aucune strophe de configuration dans /etc/finit.conf n'est requise pour rc.local . S'il existe et est un script de shell exécutable, le finit l'appelle à la toute fin du démarrage, avant d'appeler le HOOK_SYSTEM_UP . Voir plus sur les crochets dans doc / plugins.md.
Il n'est pas possible d'appeler Finit via des signaux ou d'utiliser initctl dans un script Runparts ou /etc/rc.local . Ceci parce que Finit est unique et appelle ces scripts de manière bloquante à la fin des niveaux de coulée, à quel point la boucle d'événement n'a pas encore été lancée.
La boucle d'événements est la chose qui est construite par le finit, à l'exception des niveaux coulants, qui reste une procession lente grâce à beaucoup de configuration, avec quelques crochets et bloquant les appels à des scripts externes.
Cependant, toutes les commandes initctl ne sont pas interdites. Commandes prises en charge:
/run/finit/cond inictl cond : UNIQUEMENT OPÉRATIVinitctl enable/disable : Run / tâche / service activé est activé sur le passage du niveau du runle de S à 2initctl touch/show/create/delete/list : create , à condition que le mode non interactif soit utilisé, les modifications à nouveau prennent effet dans le changement de coulée directement après bootstrapinitctl -f reboot/poweroff/halt : à condition que l'indicateur -f soit utilisé pour forcer les commandes du noyau direct Exemple: Vous pouvez définir un usr/ Condition dans /etc/rc.local et avoir un service / tâche dans RinLevel 2 dépend de celui-ci à exécuter.
La prise en charge de base pour les niveaux de course est incluse dans Finit de V1.8. Par défaut, tous les services, tâches, commandes d'exécution et ttys répertoriés sans un ensemble de niveaux de course obtiennent un ensemble par défaut [234] . Le niveau de circulation par défaut après le démarrage est de 2.
Finit prend en charge les niveaux de course 0-9, et S, avec 0 réservé pour Halt, 6 Reboot et S pour les services à fonctionner uniquement sur Bootstrap. RunLevel 1 est le niveau utilisateur unique, où généralement aucun réseau n'est activé. Dans Finit, il s'agit davantage d'une politique à définir l'utilisateur. Normalement, seuls les niveaux de course 1 à 6 sont utilisés, et encore plus souvent, seul le niveau de course par défaut est utilisé.
Pour spécifier un ensemble autorisé de niveaux de course pour un service , run la commande, task ou tty , ajoutez [NNN] à votre /etc/finit.conf , comme ceci:
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
Dans cet exemple, Syslogd est d'abord démarré, en parallèle, puis ACPID est appelé à l'aide d'un script SYSV INIT conventionnel. Il s'appelle avec la commande RUN, ce qui signifie que la commande de tâche suivante pour démarrer le script KBD n'est pas appelée tant que le script init acid s'est complètement terminé. Ensuite, le script de configuration du clavier est appelé parallèle avec KLOGD en tant que service surveillé.
Encore une fois, les tâches et les services sont démarrés en parallèle, tandis que les commandes d'exécution sont appelées dans l'ordre indiqué et les commandes suivantes ne sont pas démarrées jusqu'à la fin d'une commande d'exécution. De plus, les commandes de tâche et d'exécution sont exécutées dans un shell, donc les tuyaux et les redirectes peuvent être utilisés.
Les exemples suivants l'illustrent. Les commandes de la tâche Bootstrap et de l'exécution sont également supprimées une fois terminées, initctl show ne les répertoriera pas.
task [S] echo "foo" | cat >/tmp/bar
run [S] echo "$HOME" >/tmp/secret
La commutation entre les niveaux de course peut être effectuée en appelant init avec un seul argument, par exemple init 5 , ou en utilisant initctl runlevel 5 , les deux passent à Runlevel 5. Lors de la modification du final RunLevels, recharge automatiquement tous les fichiers .conf dans le répertoire /etc/finit.d/ . Donc, si vous souhaitez définir une nouvelle configuration système, passez à RunLevel 1, modifiez tous les fichiers de configuration dans le système et touchez tous les fichiers .conf dans /etc/finit.d avant de revenir au niveau de course précédent - de cette façon, le finit peut à la fois arrêter les anciens services et en démarrer des nouveaux pour vous, sans redémarrer le système.
Traditionnellement, le redémarrage et l'arrêt d'un système UNIX se font en changeant son couloir. Finit est livré avec son propre outillage fourni: shutdown , reboot , poweroff et suspend , mais aussi l'outil initctl , détaillé dans la section suivante.
Pour des raisons de compatibilité, finit écoute le même ensemble de signaux que Busybox init. Ce n'est pas 100% compatible avec SYSV INIT, mais clairement la combinaison la plus courante pour le finit. Pour plus de détails, voir doc / signals.md.
Finit implémente également une API moderne pour interroger le statut et les services de démarrage / arrêt, appelés initctl . Contrairement à telinit l'outil initctl ne revient pas tant que la commande donnée s'est complètement terminée.
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
Pour les services qui ne prennent pas en charge SIGHUP la notation <!> Dans le fichier .conf doit être utilisée pour dire que Finit s'arrête et le démarrer sur les modifications reload et runlevel . Si <> détient plus de conditions, celles-ci affecteront également la façon dont un service est maintenu.
Remarque: Même s'il est possible de démarrer des services n'appartenant pas au niveau du rinallon actuel, ces services ne seront pas réapparus automatiquement par finit s'ils sortent (crash). Par conséquent, si le niveau du couloir est 2, le service SSH Dropbear ci-dessous ne sera pas redémarré s'il est tué ou sort.
La commande status est la valeur par défaut, il affiche un aperçu rapide de toutes les tâches / services surveillés. Ici, nous appelons initctl -p , adapté aux scripts et à la documentation:
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
Les variables d'environnement à chacun des services ci-dessus sont lues, dans le cas d'Alpine Linux, /etc/conf.d/ . D'autres distributions peuvent avoir d'autres répertoires, par exemple, Debian Use /etc/default/ .
La commande status prend un NAME:ID Argument. Ici, nous vérifions l'état de dropbear , qui n'a qu'une seule instance dans ce système:
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 est capable d'exécuter sur les deux systèmes de bureau / serveur avec des systèmes UDEV et intégrés qui sont généralement livrés avec BusyBox MDEV. Certains systèmes ont SystemD-UDEV ou EUDEV aujourd'hui au lieu de l'UDEV d'origine, des sondes finit pour chacun d'entre elles lors de l'exécution et s'attend à ce que /dev/ est un système de fichiers écrivatif utilisant devtmpfs . Il est également possible d'exécuter une configuration statiquement /dev si nécessaire. Ce n'est cependant pas une bonne idée que UDEV et MDEV soient installés en même temps, cela conduira à des résultats imprévisibles.
À Boot Finit appelle mdev ou udevd pour remplir /dev , ceci est fait légèrement différemment et sur les systèmes avec UDEV, vous voudrez peut-être ajouter la tâche unique suivante au début de votre /etc/finit.conf :
run [S] udevadm settle --timeout=120 -- Waiting for udev
Finit a un Getty intégré pour TTYS, mais nécessite un travail /bin/login ou /bin/sh , si aucun ttys n'est configuré dans /etc/finit.conf .
Pour un système /var entièrement opérationnel, /run et /tmp doit être configuré correctement dans /etc/fstab - qui est itéré au démarrage.
Ce projet est basé sur le finit d'origine de Claudio Matsuoka qui a été inversé à partir de systèmes de l'EEEPC Fastinit - "des lacunes remplies d'ADN de grenouille…"
Le finit est développé et maintenu par Joachim Wiberg chez Github. Veuillez déposer des rapports de bogues, le cloner ou envoyer des demandes de traction pour les corrections de bogues et les extensions proposées.
