Como é responsável por exibir 'Starting… [ok]'

Question

Quando inicio um serviço como:

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

Eu posso ver um indicador de status: [ OK ] , que é diferente do visível em /var/log/boot.log :

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

Ou mesmo 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 forma diferente, qual biblioteca é usada para exibir [ OK ] , [FAILED] ?

    

Answer 1

Quando uma invocação manual de service executa um script de estilo SysV de /etc/init.d ou /etc/rc.d, toda a saída de status depende inteiramente desse script.

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

case "$1" in
  start)
    log_daemon_msg "Starting $DESC" "$NAME"
    do_start
    case "$?" in
        0|1) log_end_msg 0 ;;
        2) log_end_msg 1 ;;
    esac
    ;;
  [...]
esac

Aqui está a lista de funções padrão definida pela LSB. (Observe que as distribuições podem fornecer funções adicionais além do padrão, como no exemplo acima. Observe também que, por exemplo, OpenRC ou Arch Linux não são compatíveis com LSB e usam estilos totalmente diferentes .)

Na verdade, algumas distros também fornecem esse código clichê centralmente, e tudo o que resta no script init.d é implementar do_start . (Veja o OpenRC do Gentoo e /lib/init/init-d-script do Debian como exemplos). No entanto, isso não é um recurso "padrão" do LSB - os scripts que tentam ser compatíveis com o LSB ainda precisam ser feitos manualmente.

Nota: eu enfatizo 'Properly written' porque realmente não há nada que force um script init.d para usar essas funções, além da supervisão humana. Se o script quiser relatar o status via echo (ou via cowsay ), é sempre capaz de fazer isso. Isso é especialmente um problema com software comercial distribuído fora dos canais normais: sua saída de status never parece bastante correta (e francamente, todo o script init.d nunca se comporta muito bem).

Enquanto isso, quando os scripts SysV são chamados durante o processo 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 init "principal" o sistema fornecerá sua própria saída de status para todos os serviços iniciados. ( Exemplo: os initscripts antigos do Arch Linux, ao iniciar um serviço em segundo plano.)

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

    

Answer 2

Isso vem de scripts de inicialização dependentes de distribuição. Verifique o conteúdo do programa service , isso é provavelmente algum script de shell invocando scripts de gerenciamento subjacentes (SysV são considerados obsoletos agora) ou binários (systemd é o caminho a ser seguido). Este é um dos profissionais do systemd - você não terá respostas "depende".