finit
v4.8
Init rápido para sistemas Linux. Reverse projetado do EeepC Fastinit de Claudio Matsuoka - "Lacunas cheias de DNA de sapo ..."
Figura 1: Captura de tela do Finit Booting Alpine Linux (Howto).
Os recursos incluem:
/etc/rc.local Suporte/etc/network/interfacesinitctl topsulogin agrupada para casca de manutenção protegidasyslogd , consulte o projeto SyskLogd recomendado para integração completa de registro e como fazer login no buffer de anel do kernel dos scripts usando loggerO foco está em sistemas pequenos e incorporados, embora o Finit também seja totalmente utilizável nos sistemas de servidor e desktop. Para exemplos de trabalho, consulte a seção contribuinte/ com tutoriais para as seguintes distribuições Linux:
Nota: O suporte para várias distribuições Linux não significa que o Finit instale facilmente em todas as arquiteturas. Os scripts de instalação agrupados são exemplos para instalações padrão, testadas nos sistemas AMD64 (x86_64). As configurações personalizadas, por exemplo, para sistemas incorporadas, podem ser encontradas em qualquer um dos seguintes exemplos baseados em Buildroot: MyLinux, Infix ou o D-Demo Br2-Finit.
Este exemplo /etc/finit.conf também pode ser dividido em vários arquivos .conf em /etc/finit.d . Disponível, mas ainda não ativado, os serviços podem ser colocados em /etc/finit.d/available e ativado por um operador usando a ferramenta initctl. Veja as distribuições Linux acima mencionadas, ou MyLinux.
NOTA: A partir do Finit v4.4, as linhas .conf podem ser divididas usando o caractere de continuação do Unix padrão (
), também os comentários à direita são suportados. Este último significa que você precisa escapar de todos os hashes usados nas diretrizes e descrições (#). Para saber mais sobre isso e exemplos, consulte o Manual 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 A estrofe service , assim como task , run e outros são descritos na íntegra em doc/config.md. Aqui está uma rápida visão geral de alguns dos componentes mais comuns necessários para iniciar um daemon do 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
Alguns componentes são opcionais: runlevel (s), condição (s) e descrição, facilitando a criação de scripts de início simples e ainda possíveis para usos mais avançados também:
service /usr/sbin/sshd -D
As dependências são tratadas usando condições. Uma das condições mais comuns é esperar que a rede básica esteja disponível:
service <net/route/default> nginx -- High performance HTTP server
Aqui está outro exemplo em que instruímos a Finit a não começar a BusyBox ntpd até que syslogd tenha começado corretamente. A Finit aguarda que syslogd crie seu arquivo PID, por padrão /var/run/syslogd.pid .
service [2345] log <!pid/syslogd> ntpd -n -N -p pool.ntp.org
service [S12345] syslogd -n -- Syslog daemon
Observe a palavra -chave log , o BusyBox ntpd usa stderr para registro quando executado em primeiro plano. Com log finit redireciona stdout + stderr para o doemon log do sistema usando a ferramenta logger(1) .
Um serviço, ou tarefa, pode ter várias dependências listadas. Aqui, esperamos que ambos syslogd tenham começado e a rede básica de trabalho:
service [2345] log <pid/syslogd,net/route/default> ntpd -n -N -p pool.ntp.org
Se uma das condições falharem, por exemplo, perda de rede, ntpd será interrompido e assim que voltar a voltar ntpd será reiniciado automaticamente.
Nota: Verifique se os daemons não gargalham e se destacam do TTY controlador, geralmente um sinalizador -n ou -f ou -D como no caso do OpenSSH acima. Se se destacar, o Finit não pode monitá -lo e tentará reiniciá -lo.
Supervisão do processo
Iniciar, monitorar e reiniciar os serviços, caso falhem.
Getty
A Finit suporta Getty externa, mas também vem com um getty embutido limitado, útil para sistemas realmente pequenos. Um Getty configura o TTY e aguarda a entrada do usuário antes de entregar o /bin/login , responsável por lidar com a autenticação real.
tty [12345] /dev/tty1 nowait linux
tty [12345] /dev/ttyAMA0 noclear vt100
tty [12345] /sbin/getty -L /dev/ttyAMA0 vt100
Os usuários de sistemas incorporados podem querer ativar o console serial automático com o dispositivo especial @console . Isso funciona, independentemente do tempo, o sistema usa ttyS0 , ttyAMA0 , ttyMXC0 ou qualquer outra coisa. Finit descobre isso consultando sysfs: /sys/class/tty/console/active .
tty [12345] @console linux noclear
Observe as bandeiras opcionais noclear , nowait e nologin . Este último é para pular o processo de login completamente. Para mais informações, consulte Doc/Config.MD.
Níveis de execução
O suporte aos níveis de execução do estilo SYSV está disponível, no mesmo estilo mínimo de tudo o mais em Finit. A sintaxe [2345] pode ser aplicada ao serviço, tarefa, execução e estrofes TTY.
Os níveis de execução reservados são 0 e 6, param e reiniciam, respectivamente, assim como o SYSV INIT. O RunLevel 1 pode ser configurado livremente, mas é recomendável ser mantido como o nível de execução do sistema único, pois o Finit não iniciará a rede aqui. O runlevel NUM DE /etc/finit.conf configurado é o que o Finit muda após o bootstrap, a menos que 'single' (ou 's') seja fornecido no Kernel CMDline, nesse caso o RunLevel 1 é iniciado.
Todos os serviços no Runlevel S) são iniciados primeiro, seguidos pelo nível de execução desejado. Executar tarefas no RUNLEVEL S pode ser iniciado em sequência usando run [S] cmd . A alteração dos níveis de execução no tempo de execução é feita como qualquer outro init, por exemplo, init 4 , mas também usando a ferramenta intictl mais avançada.
Condições
Como mencionado anteriormente, o FINIT possui um sistema de dependência avançado para lidar com a sincronização, denominada condições. Pode ser usado de várias maneiras; depender de outro serviço, disponibilidade de rede, etc.
Um exemplo muito legal útil para sistemas incorporados é executar certos scripts se uma placa tiver um determinado recurso codificado em sua árvore de dispositivos. No Bootstrap, executamos o seguinte script ident :
#! /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 Desde que exista o nó da árvore do dispositivo e seja uma string, podemos usar a condição <hw/model/foo> ao iniciar outros scripts. Aqui está um exemplo:
run [S] /path/to/ident --
task [2] <hw/model/foo> /path/to/foo-init -- Initializing Foo board
Observe o truque com uma descrição vazia para ocultar a chamada para
identna saída de progresso finit.
Plugins
Os plug -ins podem estender a funcionalidade do Finit e o conectar nos diferentes estágios do processo de inicialização e no tempo de execução. Os plugins são gravados em C e compilados em uma biblioteca dinâmica carregada automaticamente pela Finit na inicialização. Um conjunto básico de plugins é interrompido no plugins/ diretório.
Recursos:
Extensões e funcionalidade não puramente relacionadas ao que um /sbin/init precisa iniciar um sistema está disponível como um conjunto de plugins que se conectam ao processo de inicialização ou respondem a várias E/S.
Para mais informações, consulte Doc/Plugins.MD.
Recarregar automático
Por padrão, o finit monitores /etc/finit.d/ e /etc/finit.d/enabled/ registrando quaisquer alterações nos arquivos .conf . Para ativar uma alteração, o usuário deve ligar para initctl reload , que recarrega todos os arquivos modificados, interrompe qualquer serviço removido, inicia novos e reinicia os modificados. Se os argumentos da linha de comando de um serviço foram alterados, o processo será encerrado e depois iniciado novamente com os argumentos atualizados. Se os argumentos não tiverem sido modificados e o processo suporta suspiro, o processo receberá um suspiro em vez de ser encerrado e iniciado.
Para alguns casos de uso, a etapa extra de chamar initctl reload cria uma sobrecarga desnecessária, que pode ser removida no tempo de construção usando:
configure --enable-auto-reload
CGROUPS
A Finit suporta o CGROUPS V2 e vem com os seguintes grupos padrão nos quais os serviços e as sessões de usuário são colocados:
/sys/fs/cgroup
|-- init/ # cpu.weight:100
|-- system/ # cpu.weight:9800
`-- user/ # cpu.weight:100
O próprio Finit e seus scripts e serviços auxiliares são colocados no grupo de folhas de nível superior init/ , que também é reservado .
Todos os processos de execução/tarefa/serviço/sysv são colocados em seu próprio subgrupo no system/ . O nome de cada subgrupo é retirado do respectivo arquivo .conf de /etc/finit.d .
Todos os processos getty/ tty são colocados em seu próprio subgrupo no user/ . O nome de cada subgrupo é retirado do nome de usuário.
Um quarto grupo também existe, o grupo root . Também é reservado e destinado principalmente a tarefas de RT. Se você tiver tarefas de RT, eles precisam ser declarados como tal em sua estrofe de serviço assim:
service [...] <...> cgroup.root /path/to/foo args -- description
ou
cgroup.root
service [...] <...> /path/to/foo args -- description
service [...] <...> /path/to/bar args -- description
Consulte Doc/config.md para obter mais informações, por exemplo, como configurar limites por grupo.
A ferramenta initctl possui três comandos para ajudar a depurar e otimizar a configuração e o monitoramento dos cgroups. Consulte os comandos ps , top e cgroup para obter detalhes.
NOTA: Os sistemas que não suportam CGROUPs, especificamente a versão 2, são detectados automaticamente. Nesses sistemas, a funcionalidade acima é desativada no início da inicialização.
No final da inicialização, quando todas as tarefas e serviços S bootstrap foram iniciados, mas não a rede, a Finit chama seu comando interno de partidas internas (8) em qualquer diretório runparts <DIR> configurado. Isso acontece pouco antes de mudar para o nível de execução configurado (padrão 2). (A rede é ativada pouco antes de mudar do modo de usuário único.)
runparts /etc/rc.d/ Logo após a mudança de nível de execução quando todos os serviços começaram corretamente, /etc/rc.local é chamado.
Nenhuma estrofe de configuração em /etc/finit.conf é necessária para rc.local . Se existir e for um script de shell executável que o Finit o chama no final da inicialização, antes de ligar para o HOOK_SYSTEM_UP . Veja mais em ganchos em doc/plugins.md.
Não é possível ligar para o Finit via sinais ou usar initctl em qualquer script RunParts ou /etc/rc.local . Isso porque o Finit é um único rosqueado e está chamando esses scripts de uma maneira bloqueadora no final do Runlevel S, momento em que o loop do evento ainda não foi iniciado.
O loop de eventos é a coisa toda que o Finit é construído, exceto o Runlevel S, que continua sendo uma procissão lenta através de muitas configurações, com alguns ganchos e bloqueando as chamadas para scripts externos.
No entanto, nem todos os comandos initctl são proibidos. Comandos suportados:
inictl cond : apenas opere arquivos em /run/finit/condinitctl enable/disable : ativado/tarefa/serviço é ativado na mudança de nível de runção de s para 2initctl touch/show/create/delete/list : create , desde que o modo não interativo seja usado, novamente as alterações entram em vigor na mudança de nível runal diretamente após o bootstrapinitctl -f reboot/poweroff/halt : desde que a bandeira -f seja usada para forçar os comandos do kernel direto Exemplo: você pode definir um usr/ condição em /etc/rc.local e ter um serviço/tarefa no RunLevel 2 depende dele para executar.
O suporte básico para níveis de execução está incluído no Finit da v1.8. Por padrão, todos os serviços, tarefas, comandos de execução e TTYs listados sem um conjunto de níveis de execução recebem um conjunto padrão [234] atribuído. O nível de execução padrão após a inicialização é 2.
A Finit suporta o RunLevels 0-9, e S, com 0 Reservado para Halt, 6 reinicialização e S para serviços para executar apenas no bootstrap. O RUNLEVEL 1 é o nível único do usuário, onde geralmente nenhuma rede está ativada. Na Finit, isso é mais uma política para o usuário definir. Normalmente, apenas os níveis 1-6 são usados e, ainda mais comumente, apenas o nível de execução padrão é usado.
Para especificar um conjunto permitido de níveis de execução para um service , run , task ou tty , adicione [NNN] ao seu /etc/finit.conf , como este:
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
Neste exemplo, o syslogd é iniciado pela primeira vez, em paralelo, e depois o ACPID é chamado usando um script SYSV Init convencional. É chamado com o comando RUN, o que significa que o seguinte comando de tarefa para iniciar o script KBD não é chamado até que o script ACPID Init esteja totalmente concluído. Em seguida, o script de configuração do teclado é chamado em paralelo com o KLOGD como um serviço monitorado.
Novamente, tarefas e serviços são iniciados em paralelo, enquanto os comandos executados são chamados no pedido listado e os comandos subsequentes não serão iniciados até que um comando de execução seja concluído. Além disso, os comandos de tarefas e execução são executados em um shell, para que tubos e redirecionamentos possam ser usados.
Os exemplos a seguir ilustram isso. A tarefa de bootstrap e os comandos de execução também são removidos quando concluídos, initctl show não os listará.
task [S] echo "foo" | cat >/tmp/bar
run [S] echo "$HOME" >/tmp/secret
A alternância entre os níveis de execução pode ser feita ligando para o init com um único argumento, por exemplo, init 5 ou usando initctl runlevel 5 , mude para o RunLevel 5. Ao alterar o Runlevels Finit também recarrega automaticamente todos os arquivos .conf no diretório /etc/finit.d/ . Portanto, se você deseja definir uma nova configuração do sistema, mude para o RunLevel 1, altere todos os arquivos de configuração no sistema e toque em todos os arquivos .conf em /etc/finit.d antes de voltar ao nível anterior de RunLevel - dessa maneira Finit pode interromper os serviços antigos e iniciar nenhum novo para você, sem renotar o sistema.
Tradicionalmente, a reinicialização e a interrupção de um sistema UNIX é feita alterando seu nível de execução. A Finit vem com suas próprias ferramentas que fornecem: shutdown , reboot , poweroff e suspend , mas também a ferramenta initctl , detalhada na próxima seção.
Por razões de compatibilidade, Finit ouve o mesmo conjunto de sinais que o BusyBox Init. Isso não é 100% compatível com o SYSV Init, mas claramente a combinação mais comum para o FINIT. Para mais detalhes, consulte Doc/Signals.MD.
A Finit também implementa uma API moderna para consultar o status e iniciar/parar os serviços, chamado initctl . Ao contrário telinit a ferramenta initctl não retorna até que o comando fornecido esteja totalmente concluído.
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
Para serviços que não suportam SIGHUP a notação <!> No arquivo .conf deve ser usada para dizer ao Finit para parar e iniciá -lo em alterações reload e runlevel . Se <> tiver mais condições, elas também afetarão como um serviço é mantido.
Nota: mesmo que seja possível iniciar serviços que não pertencem ao nível atual, esses serviços não serão reaparecidos automaticamente pela Finit se eles sair (falhas). Portanto, se o nível de execução for 2, o serviço SSH abaixo do DropBear não será reiniciado se for morto ou saídas.
O comando status é o padrão, ele exibe uma visão geral rápida de todos os monitorados Run/Task/Services. Aqui chamamos initctl -p , adequado para scripts e documentação:
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
As variáveis de ambiente para cada um dos serviços acima são lidas, no caso do alpino Linux, /etc/conf.d/ . Outras distribuições podem ter outros diretórios, por exemplo, uso do Debian /etc/default/ .
O comando status leva um NAME:ID . Aqui, verificamos o status do dropbear , que possui apenas uma instância neste sistema:
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
A Finit é capaz de executar os sistemas de desktop/servidor com sistemas Udev e incorporados que geralmente vêm com o BusyBox MDEV. Alguns sistemas possuem o SystemD-MUDEV ou o EUDEV hoje, em vez das sondas Udev original, finit para todas elas em tempo de execução e espera que /dev/ sejam um sistema de arquivos gravável usando devtmpfs . Também é possível executar em uma configuração estaticamente /dev se necessário. No entanto, não é uma boa ideia ter o UDEV e o MDEV instalados ao mesmo tempo, isso levará a resultados imprevisíveis.
Na Boot Finit chama mdev ou udevd para preencher /dev , isso é feito de maneira um pouco diferente e, em sistemas com o UDEV Você pode querer adicionar a seguinte tarefa de uma vez no início de seu /etc/finit.conf :
run [S] udevadm settle --timeout=120 -- Waiting for udev
O Finit possui um getty embutido para ttys, mas requer um trabalho /bin/login ou /bin/sh , se nenhum TTYS estiver configurado em /etc/finit.conf .
Para um sistema totalmente operacional /var , /run e /tmp deve ser configurado corretamente em /etc/fstab - que é iterado na inicialização.
Este projeto é baseado no Finit original de Claudio Matsuoka, que foi projetado em syscalls do EeePC Fastinit - "Lacunas cheias de DNA de sapo ..."
Finit é desenvolvido e mantido por Joachim Wiberg no Github. Por favor, registre relatórios de bug, clone ou envie solicitações de puxar para correções de bugs e extensões propostas.
