Na semana passada eu ministrei uma palestra sobre o Upstart, novo inicializador do sistema, substitudo do SysV init, introduzido pela Canonical para o Ubuntu. O Upstart vem sendo adotado ou pretendido por várias outras distribuições, como Debian, Fedora e Chrome OS. Pos isso, agora transformo a palestra em artigo, objetivando mostrar o que muda nas nossas tarefas diárias de administração de sistemas com esse novo recurso.

SysV init e os Run Levels

O SysV init tem sido o inicializador do sistema padrão no Linux desde o início de sua fase adulta. Ele foi introduzido pelo Unix System V, da AT&T, a partir de 1983 e seu modelo serviu de inspiração para o Linux. O modelo estabelecido pelo SysV init só é completo com o uso dos Run Levels.

Quando o sistema é inicializado, depois que o kernel termina de carregar, o init é chamado recebendo como parâmetro o runlevel que ele deve executar. De acordo com o runlevel, o SysV init inicia os scripts correspondentes ao nível de execução desejado. Pela Linux Standard Base 4.0, temos os seguintes runlevels…

Para cada Run Level temos um diretório no sistema que contém os scripts (ou links para eles) que devem ser inicializados ou parados. Por exemplo, em um servidor RHEL5, podemos achar os seguintes scripts no diretório correspondente ao Run Level 3:

root@server:~# ls /etc/rc3.d/
S10rsyslog  S16ssh     S21fam   S99rc.local
S12acpid    S20cprint  S24hal   S99rmnologin
S12dbus     S20cups    S89cron  S99stop-bootlogd

Perceabam que no nome do script há ainda um S, indicando que o script receberá “start” como parâmetro (seria K, de Kill, para o script receber o parâmetro stop), e um número que indica a ordem que ele deve ser executado.

Nem todas as distribuições seguem a risca esse padrão de Run Levels. No caso do Debian e derivados, os níveis de 2 a 5 são idênticos. Nesse caso, a interface gráfica é sempre iniciada caso esteja instalada.

Upstart

Pela definição da Canonical, o “Upstart é um substituto do daemon /sbin/init baseado em eventos que inicia serviços durante o boot, para-os durante o desligamento e supervisiona-os enquanto o sistema está em funcionamento.”

O Upstart resolve 2 problemas existentes no modo de funcionamento do SysV init. O primeiro, que julgo o menos importante, é que o Upstart executa os scripts de inicialização de forma paralela, dependendo apenas que os eventos estabelecidos como pré-requisitos ocorram, reduzindo drasticamente o tempo de boot. O segundo, importantíssimo pra mim, é que o Upstart tem a capacidade de monitorar um serviço e, em caso de interrupção abrupta, inicializa-lo novamente. O fato de os eventos determinarem quando um serviço é inicializado ou parado traz vantagens para o sistema, já que os eventos podem ser gerados por qualquer processo.

Como forma de manter a compatibilidade com o SysV init, propiciando uma migração suave, existe um script de Upstart que chama o SysV init passando o run level desejado.

Para criar um script upstart, acesse o diretório dos scripts já existentes. Na versão 10.04 do Ubuntu, o diretório é o “/etc/init”. Em versões passadas, os scripts ficavam em “/etc/event.d”. Os scripts tem a extensão “.conf” e possuem três sessões principais:

• Condições para inicializar ou parar o serviço.
• Ações a serem tomadas antes de inicializar e depois de parar o serviço.
• Comando ou script que inicializa o serviço.

Criaremos então um arquivo chamado “/etc/init/meuservico.conf”

1 – Condições para inicializar ou parar o serviço: aqui iremos definir os eventos esperados para executar ou parar o serviço. Por exemplo:

start on filesystem and net-device-up IFACE=lo

Onde “filesystem” é um evento gerado pelo sistema quando as partições estiverem montadas e “net-device-up IFACE=lo” é um evento gerado pelo sistema quando a interface de loopback estiver “up”.

Da mesma forma, devemos ter o evento que para o serviço:

stop on runlevel [016]

Onde “runlevel [016]” é um evento gerado pelo sistema quando o computador for desligado, ligado ou alternado para monousuário ou reinicializado, respectivamente.

2 – As ações a serem tomadas antes de inicializar e depois de parar o serviço são definidas pelos parâmetros a seguir:

pre-start script
 mkdir /tmp/meuservico
end script

post-stop script
 rm -rf /tmp/meuservico
end script

3 – E, por último, o comando ou script que inicializa o serviço:

exec /usr/bin/meuservico.sh

Onde meuservico.sh pode ser um script ou binário, em qualquer linguagem, inclusive recebendo parâmetros, caso se aplique.

Para gerenciar o serviço criado, usamos os comandos:

start meuservico
stop meuservico
status meuservico

Podemos também emitir eventos personalizados, usando o seguinte comando:

initctl emit evento1

Esse evento pode ser usado como condição de start ou stop do meu serviço.

Pra encerrar, podemos usar o parâmetro “respaw” para que o Upstart monitore e inicie-o novamente em caso de parada abrupta no funcionamento do serviço (tenta dar um kill no processo…).

O arquivo “/etc/init/meuservico.conf” completo ficaria assim:

start on filesystem and net-device-up IFACE=lo
stop on runlevel [016]

respawn

pre-start script
 mkdir /tmp/meuservico
end script

post-stop script
 rm -rf /tmp/meuservico
end script

exec /usr/bin/meuservico.sh

Essa foi um breve introdução ao gerenciamento de serviços Upstart. Para mais informações visite:

http://upstart.ubuntu.com/wiki/

Deixe seu comentário!

:wq