Como criar serviço no Raspberry • Do bit Ao Byte
Como criar serviço no Raspberry
Djames Suhanko 31 de julho de 2016 5 min read
Criar serviço no Raspberry
Saudoso sysV
Criar serviço utilizando o systemd
Pid do script.sh
scriptCaller.sh
Habilitar o serviço
É o mesmo processo para sistemas Linux que utilizem o systemd, mas de qualquer modo, não é sabido por todos os makers e certamente em algum momento você quererá que um programa (seu ou do sistema) inicialize sozinho. Mas antes de mostrar como colocar um serviço no systemd, gostaria de falar do systemV, que foi o sistema utilizado para inicialização de serviço durante muitos, muitos anos antes mesmo do Linux existir.
Antigamente (mas nem tanto) absolutamente todos os sistemas Linux utilizavam o tradicional sysV, onde os scripts de inicialização de serviços eram os que você encontra em /etc/init.d. A diferença do upstart é que o simples e saudoso sysV executava toda a inicialização em série, ou seja, conforme o número do serviço com link em /etc/rcX.d. Para efeito de exclarecimento, dentro desse diretório você tinha (e ainda tem, mas o funcionamento é diferente) os links simbólicos para os serviços do nível de execução.
Não era apenas um link simbólico qualquer, haveria de ser a ordem de inicialização e a ordem de finalização. A finalização deveria ser feita no runlevel 0 e no runlevel 6 (shutdown e reboot), ou em qualquer outro nível selecionado em que o serviço não devesse ser inicializado. O runlevel de manutenção era o runlevel 2 e o runlevel padrão gráfico era o 5. Atualmente, o runlevel padrão para Ubuntu, Mint e afins é o runlevel 2 (que pode ser observado através do comando "runlevel" em qualquer terminal), portanto os serviços desse runlevel ficam em /etc/rc2.d e suas finalizações em /etc/rc0.d e /etc/rc6.d.
Para fazer o serviço em /etc/init.d utilizando o sysV o formato deve ser algo como:
# Provides:          scriptOuPrograma
# Required-Stop:     seForOcasoDeAlgumFinalizarPrimeiro
# Short-Description: executa meu programa
echo "executou em $(date)" >/tmp/meuScript
echo "nao tem restart"
echo "nao tem stop"
Após escrito, o script deve ficar alocado em /etc/init.d. Dá-se permissão de execução:
chmod 0750 /etc/init.d/seuScriptDoSystemV
E inclui-se ele na inicialização. Antigamente existia o ntsysv para incluir o serviço através de um menu em ncurses. Para esse script em sistemas que ainda funcionem assim, você pode utilizar o update-rc.d:
update-rc.d seuScriptDeInicializacao defaults
Bem, alguns dias antes desse post tive que incluir um serviço no Raspbian e por um acaso não funcionou utilizando o método descrito anteriormente, porque agora ele utiliza o systemd. Para criar um serviço com o systemd é simples e tem lá suas vantagens.
O systemd tem algumas características peculiares. Ele não desprende do script que chama, portanto deve-se criar o script A para chamar o script B. Suponhamos scriptCaller.sh e script.sh.
O processo necessita ter um arquivo de pid para que possa ser controlado. O lugar ideal é /var/run, mas por falta de permissão como usuário comum, você pode preparar previamente um diretório com permissão de escrita:
sudo mkdir /var/run/script
chown usuario.grupo /var/run/script
chmod 0770 /var/run/script
./etc/init.d/script.sh &
echo $$ > /var/run/script/script.pid
O script será o programa principal, que faz o que desejar. Monte-o como o exemplo do systemV lá em cima. Por fim, configuramos o systemd para gerenciar o script. Vou mostrar o exemplo real que utilizei no Raspberry Pi:
Description=LSB: USCA Manager
Before=runlevel3.target runlevel5.target shutdown.target
After=network-online.target remote-fs.target network-online.target
PIDFile=/var/run/usca/uscaMonitor.pid
ExecStart=/root/root/manager.py
A linha "Description=LSB" apenas faz uma descrição do processo.
A linha "Before=" indica os níveis de execução previos e "After" indica após quais processos inicializados ele deve ser executado.
A linha "Wants" imputa a obrigação de inicialização prévia da rede e "Conflicts", hum…
Na sessão "[Service]" estão as características padrão da inicialização, onde indica-se principalmente o pid e o script ou programa a executar. Por fim, o modo de instalação do serviço.
Acabaram-se as configurações, agora basta habilitar o serviço com 2 comandos:
#recarrega o daemon
#ativa o serviço
systemct enable scriptCaller.sh
O processo é bastante interessante e realmente trouxe vantagens sobre o sysV. E mesmo que não trouxesse, não resta outra opção que não seja se adaptar, afinal, o sistema continuará a evoluir, inclusive em sua estrutura. Além disso, o systemd tem outros recursos, leia o manual se tiver interesse, esse artigo apenas auxilia a por rapidamente um script para inicializar em seu sistema, mas você pode obter outras vantagens estudando um pouco mais.