Como criar unidade de serviço Systemd no Linux

Embora o Systemd tenha sido objeto de muitas controvérsias, a ponto de algumas distribuições serem bifurcadas apenas para se livrar dele (ver Devuan, um garfo de Debian que, por padrão, substitui o Systemd por Sysvinit), no final se tornou o De-Facto Standard Init System no mundo Linux.

Neste tutorial, veremos como um serviço Systemd está estruturado, e aprenderemos a criar um.

Neste tutorial, você aprenderá:

• O que é uma unidade de serviço…
• Quais são as seções de uma unidade de serviço.
• Quais são as opções mais comuns que podem ser usadas em cada seção.
• Quais são os diferentes tipos de serviço que podem ser definidos.

Requisitos de software e convenções usadas

O sistema Systemd init

Todas as principais distribuições, como Rhel, Centos, Fedora, Ubuntu, Debian e Archlinux, adotaram o Systemd como seu sistema init. Systemd, na verdade, é mais do que apenas um sistema init, e essa é uma das razões pelas quais algumas pessoas são fortemente contra seu design, que vai contra o lema Unix bem estabelecido: “Faça uma coisa e faça bem”. Onde outros sistemas inits usam script simples para gerenciar serviços, o Systemd usa seu próprio .serviço arquivos (unidades com o .Sufixo de serviço): Neste tutorial, veremos como eles estão estruturados e como criar e instalar um.

Anatomia de uma unidade de serviço

O que é uma unidade de serviço? Um arquivo com o .serviço O sufixo contém informações sobre um processo que é gerenciado pelo Systemd. É composto por três seções principais:

• [Unidade]: Esta seção contém informações não especificamente relacionadas ao tipo de unidade, como a descrição do serviço
• [Serviço]: contém informações sobre o tipo específico da unidade, um serviço neste caso
• [Instalação]: Esta seção contém informações sobre a instalação da unidade

Vamos analisar cada um deles em detalhes.

A seção [unidade]

O [Unidade] seção de a .serviço O arquivo contém a descrição da própria unidade, e informações sobre seu comportamento e suas dependências: (para trabalhar corretamente um serviço pode depender de outra). Aqui discutimos algumas das opções mais relevantes que podem ser usadas nesta seção

A opção "Descrição"

Primeiro de tudo, temos o Descrição opção. Ao usar esta opção, podemos fornecer uma descrição da unidade. A descrição aparecerá então, por exemplo, ao ligar para o SystemCtl Comando, que retorna uma visão geral do status do Systemd. Aqui está, como exemplo, como a descrição de httpd O serviço é definido em um sistema de Fedora:

[Unidade] Descrição = O servidor HTTP Apache 

A opção "depois"

Usando o Depois Opção, podemos afirmar que nossa unidade deve ser iniciada após as unidades que fornecemos na forma de uma lista separada por espaço. Por exemplo, observando novamente o arquivo de serviço em que o serviço da Web Apache é definido, podemos ver o seguinte:

Depois = rede.alvo remoto-fs.Target NSS-Lookup.Alvo HTTPD-Init.serviço

A linha acima instrui o Systemd a iniciar a unidade de serviço httpd.serviço Somente depois do rede, Remover-fs, NSS-Lookup alvos e o Serviço Httpd-Init.

Especificando dependências duras com "requer"

Como mencionamos brevemente acima, uma unidade (um serviço no nosso caso) pode depender de outras unidades (não necessariamente "unidades de serviço") para funcionar corretamente: essas dependências podem ser declaradas usando o Requer opção.

Se alguma das unidades nas quais um serviço depende não dependências difíceis. Nesta linha, extraído do arquivo de serviço do Avahi-Daemon, podemos ver como é declarado como dependente do Avahi-Daemon.unidade de soquete:

Requer = avahi-daemon.soquete

Declarando dependências "suaves" com "desejos"

Acabamos de ver como declarar as chamadas dependências "difíceis" para o serviço usando o Requer opção; Também podemos listar dependências "suaves" usando o Quer opção.

Qual é a diferença? Como dissemos acima, se alguma dependência "dura" falhar, o serviço falhará; Uma falha de qualquer dependência "suave", no entanto, não influencia o que acontece com a unidade dependente. No exemplo fornecido, podemos ver como o Docker.serviço A unidade tem uma dependência suave do Docker-Storage-setup.serviço um:

[Unidade] Wants = Docker-Storage-setup.serviço 

A seção [Serviço]

No [Serviço] seção de a serviço unidade, podemos especificar as coisas como o comando a ser executado quando o serviço é iniciado, ou o tipo do próprio serviço. Vamos dar uma olhada em alguns deles.

Iniciando, parando e recarregando um serviço

Um serviço pode ser iniciado, parado, reiniciado ou recarregado. Os comandos a serem executados ao executar cada uma dessas ações podem ser especificados usando as opções relacionadas no [Serviço] seção.

O comando a ser executado quando um serviço é iniciado, é declarado usando o Exectart opção. O argumento passou para a opção também pode ser o caminho para um script. Opcionalmente, podemos declarar comandos a serem executados antes e após o início do serviço, usando o Execstartpre e ExecStartPost opções respectivamente. Aqui está o comando usado para iniciar o serviço NetworkManager:

[Service] ExecStart =/usr/sbin/NetworkManager-Não-daemon 

De maneira semelhante, podemos especificar o comando a ser executado quando um serviço é recarregado ou parado, usando o Execstop e Execreload opções. Da mesma forma que o que acontece com ExecStartPost, Um comando ou vários comandos a serem lançados após a parada de um processo, pode ser especificado com o ExecstopPost opção.

O tipo de serviço

Systemd define e distingue entre alguns tipos diferentes de serviços, dependendo do comportamento esperado. O tipo de serviço pode ser definido usando o Tipo opção, fornecendo um desses valores:

• simples
• bifurcação
• um disparo
• dbus
• notificar

O tipo padrão de um serviço, se o Tipo e BusName As opções não são definidas, mas um comando é fornecido através do Exectart opção, é simples. Quando esse tipo de serviço é definido, o comando declarado em Exectart é considerado o principal processo/serviço.

O bifurcação Tipo funciona de maneira diferente: o comando fornecido com Exectart Espera -se que bifurque e inicie um processo infantil, que se tornará o principal processo/serviço. O processo pai que se espera morrer quando o processo de inicialização terminar.

O um disparo Tipo é usado como padrão se o Tipo e Exectart As opções não são definidas. Funciona muito como simples: A diferença é que o processo deve terminar seu trabalho antes que outras unidades sejam lançadas. A unidade, no entanto, ainda é considerada como "ativa" mesmo após o comando sair, se o Permanecefterexit a opção está definida como "sim" (o padrão é "não").

O próximo tipo de serviço é dbus. Se esse tipo de serviço for usado, espera -se que o daemon obtenha um nome Dbus, conforme especificado no BusName opção, que neste caso se torna obrigatória. Pelo resto, funciona como o simples tipo. As unidades consequentes, no entanto, são lançadas somente após o nome do DBUS ser adquirido.

Outro processo funciona de maneira semelhante a simples, e isso é notificar: A diferença é que o daemon deve enviar uma notificação através do sd_notify função. Somente uma vez que essa notificação é enviada, as unidades consequentes são lançadas.

Defina o tempo limite do processo

Ao usar opções específicas, é possível definir alguns tempos limite para o serviço. Vamos começar com Reiniciar: Usando esta opção, podemos configurar a quantidade de tempo (por padrão em segundos) Systemd deve esperar antes de reiniciar um serviço. Um tempo de tempo também pode ser usado como um valor para esta opção, pois "5min 20s". O padrão é 100ms.

O TimeoutstartSec e TimeoutStopsec As opções podem ser usadas para especificar, respectivamente, o tempo limite para uma startup de serviço e parar, em segundos. No primeiro caso, se após o tempo limite especificado o processo de inicialização daemon, ele não estiver concluído, será considerado falhado.

No segundo caso, se um serviço for interrompido, mas não for encerrado após o tempo limite especificado, primeiro um Sigterm E então, após a mesma quantidade de tempo, um Sigkill o sinal é enviado para ele. Ambas as opções aceitam também um Timespan como um valor e podem ser configuradas de uma só vez, com um atalho: TimeoutSec. Se infinidade é fornecido como um valor, os tempos limite são desativados.

Finalmente, podemos configurar o limite para a quantidade de tempo que um serviço pode ser executado, usando o RunTimemaxSec. Se um serviço exceder esse tempo limite, ele é encerrado e considerado falhado.

A seção [Instalação]

No [instalar] Seção, podemos usar opções relacionadas à instalação do serviço. Por exemplo, usando o Alias Opção, podemos especificar uma lista separada por espaço de aliases a serem usados ​​para o serviço ao usar os comandos SystemCTL (exceto habilitar).

Da mesma forma que o que acontece com o Requer e Quer opções no [Unidade] seção, para estabelecer dependências, no [instalar] seção, podemos usar Solicitado por e Procurado. Nos dois casos, declaramos uma lista de unidades que dependem da que estamos configurando: com a opção anterior, eles dependem disso, com o último, eles serão considerados apenas como dependentes fracos. Por exemplo:

[Install] wantedby = multiususer.alvo 

Com a linha acima, declaramos que o multi usuário O alvo tem uma dependência suave de nossa unidade. Na terminologia de Systemd, unidades terminando com o .alvo sufixo, pode ser associado ao que foi chamado Runtimes em outros sistemas init como Sysvinit. No nosso caso, então, o alvo multiusuário, quando alcançado, deve incluir nosso serviço.

Criando e instalando uma unidade de serviço

Existem basicamente dois lugares no sistema de arquivos onde as unidades de serviço do Systemd são instaladas: /usr/lib/systemd/sistema e /etc/Systemd/System. O caminho anterior é usado para serviços fornecidos pelos pacotes instalados, enquanto este pode ser usado pelo administrador do sistema por seus próprios serviços, o que pode substituir os padrão.

Vamos criar um exemplo de serviço personalizado. Suponha que queremos criar um serviço que desative o recurso Wake-on-LAN em uma interface Ethernet específica (ENS5F5 no nosso caso) quando é iniciada e reencontra-a quando for interrompida. Podemos usar o Ethtool comando para realizar a tarefa principal. Aqui está como nosso arquivo de serviço poderia ser:

[Unidade] Descrição = Força Ens5F5 Ethernet Interface para 100Mbps requer = Rede.Target After = Network.Target [Service] Type = ONESHOT REALMAFTEREXIT = SIM EXECSTART =/USR/SBIN/ETHTOOL -S ENS5F5 WOL D EXECSTOP =/usr/sbin/ethtool -s Ens5f5 Wol g [install] wanted = multi -user.alvo 

Definimos uma descrição simples da unidade e declaramos que o serviço depende do rede.alvo unidade e deve ser lançada após ser alcançada. No [Serviço] Seção, definimos o tipo de serviço como um disparo, e instruiu o Systemd a considerar o serviço como ativo após a execução do comando, usando o Permanecefterexit opção. Também definimos os comandos a serem executados quando o serviço é iniciado e parado. Finalmente, no [Instalar] Seção, basicamente declaramos que nosso serviço deve ser incluído no multi usuário alvo.

Para instalar o serviço, copiaremos o arquivo no /etc/Systemd/System diretório como Wol.serviço, do que vamos começar:

$ sudo cp wol.serviço/etc/systemd/system && sudo systemctl start wol.serviço

Podemos verificar se o serviço está ativo, com o seguinte comando:

$ Systemctl Is Active Wol.serviço ativo 

A saída do comando, como esperado, é ativo. Agora para verificar se "Wake on Lan" foi definido como d, E agora está desativado, podemos executar:

$ sudo ethtool Ens5f5 | Suporte a acordamento Grep Wake-on: PG Wake-On: D 

Agora, interromper o serviço deve produzir o resultado inverso e reativar o WOL:

$ sudo systemctl stop wol.Service && sudo ethtool Ens5f5 | Grep wake-on suportes wake-on: pg wake-on: g 

Conclusões

Neste tutorial, vimos como um arquivo de serviço Systemd é composto, quais são suas seções e algumas das opções que podem ser usadas em cada uma delas. Aprendemos a configurar uma descrição do serviço, definir suas dependências e declarar os comandos que devem ser executados quando for iniciada, parada ou recarregada.

Como o Systemd, goste ou não, tornou -se o sistema init padrão no mundo Linux, é importante se familiarizar com sua maneira de fazer as coisas. A documentação oficial de serviços do Systemd pode ser encontrada no site Freedesktop. Você também pode estar interessado em ler nosso artigo sobre como gerenciar serviços com o Systemd.

Tutoriais do Linux relacionados:

• Coisas para instalar no Ubuntu 20.04
• Coisas para fazer depois de instalar o Ubuntu 20.04 fossa focal linux
• Como travar o Linux
• Mint 20: Melhor que o Ubuntu e o Microsoft Windows?
• Download do Linux
• Sistema Linux Hung? Como escapar para a linha de comando e…
• Coisas para fazer depois de instalar o Ubuntu 22.04 Jellyfish…
• Uma introdução à automação, ferramentas e técnicas do Linux
• Comandos Linux: os 20 comandos mais importantes que você precisa para…
• Comandos básicos do Linux