Introdução aos fundamentos do systemd

A primeira seção encontrada na maioria dos arquivos de unidade é [Unit]. Essa seção é usada para definir os metadados do arquivo de unidade e configurar o relacionamento dele com outros arquivos de unidade. Normalmente, essa seção é posicionada sobre as demais porque apresenta uma visão geral do arquivo de unidade.

Seções que contêm diretivas específicas ao respectivo tipo. Consulte a Seção 4, “Tipos de arquivo de unidade” para ver uma lista dos tipos disponíveis. Observe que os tipos device, target, snapshot e scope não têm uma seção específica ao tipo.

Geralmente, ela é a última seção no arquivo de unidade e é opcional. Essa seção é usada para definir o comportamento de um arquivo de unidade quando ele está habilitado ou desabilitado. Quando você habilita um arquivo de unidade, ele é iniciado automaticamente no momento da inicialização. Com base na unidade específica, pode haver uma dependência em outras unidades relacionadas para que funcione apropriadamente. Por exemplo, chrony requer as diretivas After, Wants e Before, que são todas dependências com as quais o chrony trabalha.

Descreve como gerenciar um serviço ou aplicativo. Essa descrição inclui como iniciar ou parar o serviço, recarregar seu arquivo de configuração (se aplicável), em que condições o serviço é iniciado automaticamente e as informações de dependência ou de hierarquia para arquivos de unidade relacionados.

Esse arquivo de unidade é criado automaticamente pelo systemd com base nas informações recebidas da interface D-Bus e é usado para gerenciar conjuntos de processos do sistema que são criados externamente.

Define um caminho para a ativação baseada em caminho. Por padrão, um arquivo de unidade .service com o mesmo nome de base é ativado. inotify é uma API de kernel usada por programas que desejam ser notificados sobre mudanças em arquivos.

O comando systemctl snapshot cria automaticamente um arquivo de unidade .snapshot. Esse comando cria instantâneos temporários do estado atual do sistema. Você pode modificar o estado atual do sistema após fazer mudanças. Os instantâneos são usados para reverter estados temporários.

Define um temporizador gerenciado pelo systemd. Isso é semelhante a uma tarefa cron para ativação atrasada ou programada. Um arquivo de unidade com o mesmo nome, mas com a extensão .service, é iniciado quando o temporizador é atingido.

Associe nós do Grupo de Controle do Linux, que permitem atribuir ou restringir recursos a qualquer processo associado à seção. O nome indica a hierarquia na árvore de grupos de controle. As unidades são colocadas em seções por padrão, dependendo do respectivo tipo.

Efetua a sincronização com outras unidades durante uma inicialização ou uma mudança no estado, ou coloca o sistema em um novo estado. Outras unidades especificam sua relação com os destinos para sincronização com as operações do destino.

Descreve uma rede, um soquete IPC ou um buffer PEPS que o systemd usa para ativação baseada em soquete. Há um arquivo .service associado que é iniciado quando uma atividade é vista no soquete definido por essa unidade.

Define um dispositivo que foi designado para gerenciamento do systemd pelo sistema de arquivos udev ou sysfs. Nem todos os dispositivos têm o arquivo .device. Esse arquivo de unidade é obrigatório para solicitar, montar ou acessar um dispositivo.

Define o espaço de troca (swap) no sistema. O nome do arquivo de unidade deve refletir o dispositivo ou o caminho de arquivo do espaço.

Define um ponto de montagem no sistema que será gerenciado pelo systemd. O nome desse arquivo é baseado no caminho de montagem, com traços no lugar das barras. As entradas em /etc/fstab podem ter as unidades criadas automaticamente.

Define um ponto de montagem que é montado automaticamente. Nomeie o arquivo de acordo com o ponto de montagem ao qual ele se refere. Um arquivo de unidade .mount correspondente é necessário para definir as especificações da montagem.

Por exemplo, se a unidade A tem Wants=unit B, quando a unidade A é executada, a unidade B também é executada. No entanto, se a unidade B é ou não iniciada com êxito, isso não influencia a execução bem-sucedida da unidade A.

Se a unidade A tem Requires=unit B, as duas unidades são executadas; mas, se a unidade B não é executada com êxito, a unidade A é desativada. Não importa se os processos da unidade A teriam sido executados com êxito.

Por exemplo, se a unidade A tem Before=unit B, quando as duas unidades são executadas, a unidade A é executada na íntegra antes da unidade B.

Se a unidade A tem After=unit B, quando as duas unidades são executadas, a unidade B é executada na íntegra antes da unidade A.

Inicializado por padrão. O arquivo default.target é um link simbólico para o verdadeiro arquivo de destino, como graphical.target para uma estação de trabalho desktop. Para um servidor, ele costuma ser graphical.target.

Encerra e desliga o sistema.

Unidade de destino que extrai o sistema base e inicia uma sessão de shell de recuperação.

Configura um sistema multiusuário não gráfico (console).

Usa um sistema multiusuário gráfico com serviços de rede.

Encerra e reinicializa o sistema.

Antes de iniciar ou habilitar um serviço do systemd, verifique a sintaxe do arquivo de unidade para garantir que não haja erros. Por exemplo:

> sudo systemd-analyze verify /etc/systemd/system/my-custom-service.service

O comando analisa o arquivo de unidade e relata erros de sintaxe, arquivos ausentes ou outros problemas. Você deve corrigir quaisquer problemas relatados antes de habilitar e iniciar o serviço.

Se você tiver qualquer problema com um serviço do systemd, consulte o registro do serviço. Por exemplo:

> sudo  journalctl -u my-custom-service.service

O comando exibe os registros do serviço especificado, incluindo mensagens de erro, avisos ou outras informações relevantes. Você pode usar esses registros para identificar e corrigir problemas com o serviço.

Se um serviço estiver causando problemas durante o processo de boot, você poderá usar systemd-analyze plot command para visualizar o processo de boot e identificar os problemas. Por exemplo:

> sudo systemd-analyze plot > boot-plot.svg

O comando cria um arquivo SVG chamado boot-plot.svg que contém uma representação gráfica do processo de boot e dos possíveis problemas. Isso inclui o horário de início e de término de cada serviço. Você pode abrir esse arquivo em um visualizador de imagens compatível com SVG ou em um browser da Web para analisar os serviços que estão causando problemas durante o processo de inicialização.

Para descobrir quais serviços falharam e inspecionar a saída do registro:

> sudo systemctl --state=failed

Para descobrir o status de runtime atual de um serviço:

> sudo systemctl status SERVICE

Se o encerramento ou a reinicialização for demorado, a causa pode ser um serviço que não está sendo encerrado. O systemd aguarda algum tempo até que cada serviço seja encerrado antes de tentar terminá-lo. Um problema comum é um serviço suspenso ou um encerramento travado. Para descobrir isso, execute o seguinte comando:

> sudo systemctl poweroff
  Failed to power off system via logind: There's already a shutdown or sleep operation in progress

> sudo systemctl list-jobs

Você pode cancelar as tarefas em execução e em espera e encerrar ou reinicializar novamente:

> sudo systemctl cancel

> sudo systemctl stop systemd-suspend.service

Para descobrir o status de runtime atual de um serviço:

> sudo systemctl status SERVICE

Use um caminho absoluto para arquivos executáveis e necessários, como arquivos de configuração ou scripts, em seu arquivo de unidade do systemd. O systemd não depende das variáveis de ambiente do usuário, como $PATH, para localizar arquivos.

Use a diretiva ExecReload na seção [SERVICE] para definir um comando específico que deve ser executado quando você recarregar um serviço com o comando systemctl reload. Esse procedimento é útil para serviços que podem recarregar suas configurações dinamicamente, sem reinicialização.

[Service]
ExecStart=PATH_TO_EXECUTABLE
ExecReload=PATH_TO_RELOAD_SCRIPT

Use a diretiva RestartSec na seção [SERVICE] para definir um atraso (em segundos) antes de reiniciar serviço após uma falha. Esse procedimento é útil para serviços que exigem um tempo especificado para liberar recursos ou evitar loops de reinicialização rápida que podem causar alta carga do sistema.

[Service]
ExecStart=PATH_TO_EXECUTABLE
Restart=on-failure
RestartSec=5

Você pode desabilitar o modo de emergência em uma máquina remota, por exemplo, uma máquina virtual hospedada no Google Cloud. Se esse modo estiver habilitado, a máquina não poderá se conectar à rede. Por exemplo:

> sudo systemctl mask emergency.service

> sudo systemctl mask emergency.target