Como criar e executar novas unidades de serviço no Systemd

Há alguns dias, me deparei com uma distro Centos 8 de 32 bits e senti vontade de testá-la em uma máquina antiga de 32 bits. Após a inicialização percebi que havia um bug e estava perdendo a conexão de rede, que eu tinha que “ativar” manualmente todas as vezes após a inicialização. Então, a questão era como eu poderia definir um script para fazer esse trabalho, rodando toda vez que eu inicializasse minha máquina?

Bem, isso é muito simples e vou mostrar o caminho do sistema usando unidades de serviço. Mas primeiro uma pequena introdução às unidades de serviço.

Neste artigo, vou explicar o que é uma “unidade de serviço” no systemd e como é fácil criar e executar uma. Tentarei simplificar o que são “alvos”, por que os chamamos de “coleções de unidades” e quais são seus “desejos”. Por fim, aproveitamos uma unidade de serviço para executar nosso próprio script após o procedimento de boot.

É óbvio que o seu computador é útil pelos serviços que oferece e para ter esta funcionalidade é necessário chamar muitos serviços à medida que o computador inicializa e atinge diferentes níveis.

Outros serviços são chamados para serem executados quando o computador atinge, por exemplo, o nível de resgate (runlevel 0) e outros quando atinge o nível multiusuário (runlevel 3) . Você pode imaginar esses níveis como metas.

De forma simples, target é uma coleção de unidades de serviço. Se você quiser dar uma olhada nas unidades de serviço em execução no seu nível graphical.target, digite:

systemctl --type=service

Como você pode ver, alguns serviços estão ativos e “em execução” o tempo todo, enquanto outros são executados uma vez e encerrados (encerrado).

Se quiser verificar o status de um serviço, você pode usar o comando systemctl conforme mostrado.

systemctl status firewalld.service

Como você pode ver, verifiquei o status de firewalld.service (dica: você pode usar o preenchimento automático para o nome do serviço ). Ele me informa que o serviço firewalld está em execução o tempo todo e está habilitado.

Ativado e desativado significa que o serviço será carregado permanentemente ou não, durante a próxima inicialização, respectivamente. Por outro lado, iniciar e parar um serviço tem a limitação da sessão atual e não é permanente.

Por exemplo, se você digitar:

systemctl stop firewalld.service
systemctl status firewalld.service

Você pode ver que o firewalld.service está inativo (morto), mas ainda está habilitado, o que significa que durante a próxima inicialização ele será carregado. Portanto, se quisermos que um serviço seja carregado durante a inicialização no futuro, devemos habilitá-lo. Que ótima conclusão! Vamos criar um, é fácil.

Se você for para a pasta:

cd /etc/systemd/system
ls -l

Você pode ver alguns arquivos de links de serviços unitários e alguns diretórios dos “desejos” de um alvo. Por exemplo, o que o destino multiusuário deseja que seja carregado quando o procedimento de inicialização atingir seu nível está listado no diretório com o nome /etc/systemd/system/multi-user.target.wants/ .

ls multi-user.target.wants/

Como você pode ver, ele não contém apenas serviços, mas também outros alvos que também são coleções de serviços.

Vamos fazer uma unidade de serviço com o nome connection.service.

vim connection.service

e digite o seguinte (pressione “i ” para o modo de inserção), salve-o e saia (com “esc ” e “:wq! ” ):

[Unit]
Description = making network connection up
After = network.target

[Service]
ExecStart = /root/scripts/conup.sh

[Install]
WantedBy = multi-user.target

Para explicar o que foi dito acima: criamos uma unidade do tipo serviço (você também pode criar unidades do tipo alvo) e configuramos ela para ser carregada após o network.target (você pode entender que o O procedimento de inicialização atinge os alvos com uma ordem definida) e queremos que toda vez que o serviço for iniciado execute um script bash com o nome conup.sh que iremos criar.

A diversão começa com a última parte [instalar]. Diz que será desejado por “multi-user.target ”. Portanto, se habilitarmos nosso serviço, um link simbólico para esse serviço será criado dentro da pasta multi-user.target.wants! Entendi? E se o desativarmos, esse link será excluído. Tão simples.

Basta ativá-lo e verificar:

systemctl enable connection.service

Informa que o link simbólico na pasta multi-user.target.wants foi criado. Você pode confirmar executando o comando ls conforme mostrado.

ls multi-user.target.wants/

Como você pode ver, “connection.service ” está pronto para a próxima inicialização, mas primeiro devemos criar o arquivo de script.

cd /root
mkdir scripts
cd scripts
vim conup.sh

Adicione a seguinte linha dentro do Vim e salve-a:

#!/bin/bash
nmcli connection up enp0s3

O comando nmcli para ativar a conexão de rede para a interface enp0s3.

Claro, se você quiser que seu script execute outra coisa, você pode digitar o que quiser em vez da segunda linha.

Por exemplo,

#!/bin/bash
touch /tmp/testbootfile

isso criaria um arquivo dentro da pasta /tmp (apenas para verificar se seu serviço está funcionando).

Também devemos tornar o script executável executando o comando chmod conforme mostrado.

chmod +x conup.sh

Agora estamos prontos. Se você não quiser esperar até a próxima inicialização (já está habilitado), podemos iniciar o serviço para a sessão atual digitando:

systemctl start connection.service

Voilá! Minha conexão está ativa e funcionando!

Se você optou por escrever o comando “touch /tmp/testbootfile ” dentro do script, apenas para verificar sua funcionalidade, você verá este arquivo criado dentro da pasta /tmp .

Eu realmente espero ajudá-lo a descobrir quais são os serviços, desejos, alvos e execução de scripts durante a inicialização.