☰

Como é responsável por exibir `Starting... [ok]`

tag-icon • tag-icon linux daemon
Como é responsável por exibir `Starting... [ok]`

Quando inicio um serviço como:

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

Posso ver um indicador de status: [ OK ]que é diferente daquele visível em /var/log/boot.log:

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

Ou até diferente de:

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

Nestes três exemplos qual processo é responsável por exibir e iniciar os daemons? Dito de outra forma , qual biblioteca é usada para exibir [ OK ]?[FAILED]

Responder1

Quando uma invocação manual serviceexecuta um script estilo SysV de /etc/init.d ou /etc/rc.d, toda a saída de status dependeinteiramente nesse roteiro.

Scripts init.d escritos corretamente usarão uma biblioteca de funções shell fornecida pela distribuição. Por exemplo, no Debian, a maioria dos scripts irá carregar (fonte) o arquivo /lib/lsb/init-functionse simplesmente chamar as funções fornecidas assim:

caso "$1" em
  começar)
    log_daemon_msg"Iniciando $DESC" "$NAME"
    do_start
    caso "$?" em
        0|1)log_end_msg0;;
        2) log_end_msg 1;;
    esac
    ;;
  [...]
esac

Aqui está olista de funções padrãodefinido pela LSB. (Observe que as distros podem forneceradicionalfunções além do padrão, como no exemplo acima. Observe também que, por exemplo, OpenRC ou Arch Linuxnão sãoCompatível com LSB e usa estilos totalmente diferentes.)

Na verdade, algumas distros também fornecerão esse código padrão centralmente, e tudo o que resta ao script init.d é implementar o do_start. (Veja OpenRC do Gentoo e Debian /lib/init/init-d-scriptcomo exemplos). No entanto, esse não é um recurso LSB “padrão” – os scripts que tentam ser compatíveis com LSB ainda precisam fazer isso manualmente.

Observação:Enfatizo 'Escrito corretamente' porque realmente não há nada que possaforçaum script init.d para usar essas funções, além da supervisão humana. Se o script quiser relatar o status via simples echo(ou via cowsay), ele sempre poderá fazer isso. Isto é especialmente um problema com software comercial distribuído fora dos canais normais: a sua saída de statusnuncaparece bastante correto (e, francamente, todo o script init.d nunca se comporta corretamente).

Enquanto isso, quando os scripts SysV são chamados durante oprocesso de inicialização, o resultado é ainda mais dependente da distribuição – às vezes você verá a saída diretamente dos próprios scripts, mas às vezes o sistema init "principal" fornecerá sua própria saída de status para todos os serviços que iniciar. (Exemplo:Os antigos scripts de inicialização do Arch Linux, ao iniciar um serviço em segundo plano.)

Mas o seu segundo exemplo é na verdadenãoum init no estilo SysV - é o systemd (que por acaso está iniciando um script init.d 'legado' no seu exemplo). Systemd é um gerenciador de serviços completo que usa configurações de serviço (não scripts) e, portanto,todosa saída do status de inicialização/desligamento é fornecida pelo próprio systemd. Isso também se aplica à maioria dos outros "gerenciadores de serviços", incluindo init-ng, SMF ou Upstart.

Responder2

Isso vem de scripts de inicialização dependentes de distribuição. Verifique o conteúdo do serviceprograma, provavelmente é algum script de shell que invoca scripts de gerenciamento subjacentes (o SysV é considerado obsoleto agora) ou binários (o systemd é o caminho a seguir). Este é um dos profissionais do systemd - você não obterá respostas "isso depende".

informação relacionada