Capítulo 3. Gerenciamento de serviços com systemd

3.1. Introdução ao sistemad

Systemd é um gerente de sistemas e serviços para sistemas operacionais Linux. Ele foi projetado para ser retrocompatível com scripts de inicialização SysV e fornece uma série de recursos, tais como inicialização paralela de serviços de sistema no momento da inicialização, ativação de daemons sob demanda, ou lógica de controle de serviços baseada em dependência. Começando com o Red Hat Enterprise Linux 7, systemd substituiu Upstart como o sistema init padrão.

Systemd introduz o conceito de systemd units. Estas unidades são representadas por arquivos de configuração de unidades localizados em um dos diretórios listados na tabela a seguir.

Tabela 3.1. Localização dos arquivos da unidade Systemd

DiretórioDescrição

/usr/lib/systemd/system/

Arquivos da unidade Systemd distribuídos com pacotes de RPM instalados.

/run/systemd/system/

Arquivos da unidade Systemd criados em tempo de execução. Este diretório tem precedência sobre o diretório com os arquivos das unidades de serviço instaladas.

/etc/systemd/system/

Arquivos de unidades do sistema criados por systemctl enable, bem como arquivos de unidades adicionados para ampliar um serviço. Este diretório tem precedência sobre o diretório com arquivos unitários de tempo de execução.

As unidades encapsulam informações sobre:

  • Serviços de sistema
  • Tomadas de escuta
  • Outros objetos que são relevantes para o sistema init

Para uma lista completa dos tipos de unidades do sistema disponíveis, consulte a tabela a seguir.

Tabela 3.2. Tipos de unidades do sistema disponíveis

Tipo de unidadeExtensão do arquivoDescrição

Unidade de serviço

.service

Um serviço de sistema.

Unidade alvo

.target

Um grupo de unidades do sistema.

Unidade de montagem automática

.automount

Um ponto de montagem automática do sistema de arquivo.

Unidade do dispositivo

.device

Um arquivo de dispositivo reconhecido pelo kernel.

Unidade de montagem

.mount

Um ponto de montagem do sistema de arquivo.

Unidade de caminho

.path

Um arquivo ou diretório em um sistema de arquivos.

Unidade de escopo

.scope

Um processo criado externamente.

Unidade de fatias

.slice

Um grupo de unidades hierarquicamente organizadas que gerenciam os processos do sistema.

Unidade de soquetes

.socket

Uma tomada de comunicação inter-processo.

Unidade de troca

.swap

Um dispositivo swap ou um arquivo swap.

Unidade do temporizador

.timer

Um temporizador do sistema.

Substituindo a configuração padrão do systemd usando system.conf

A configuração padrão de systemd é definido durante a compilação e pode ser encontrado no arquivo de configuração do sistema em /etc/systemd/system.conf. Use este arquivo se você quiser se desviar desses valores padrão e substituir os valores padrão selecionados para unidades systemd globalmente.

Por exemplo, para anular o valor padrão do limite de tempo limite, que está definido para 90 segundos, use o parâmetro DefaultTimeoutStartSec para inserir o valor requerido em segundos.

DefaultTimeoutStartSec=required value

Para maiores informações, ver Exemplo 3.11, “Alteração do limite de tempo limite”.

3.1.1. Principais características

O sistema e o gerente de serviços do sistema fornecem as seguintes características principais:

  • Socket-based activation - No momento da inicialização, systemd cria tomadas de escuta para todos os serviços do sistema que suportam este tipo de ativação, e passa as tomadas para estes serviços assim que são iniciadas. Isto não só permite systemd para iniciar serviços em paralelo, mas também possibilita reiniciar um serviço sem perder nenhuma mensagem enviada a ele enquanto ele não estiver disponível: o soquete correspondente permanece acessível e todas as mensagens são enfileiradas.

    Systemd usa socket units para ativação baseada em soquete.

  • Bus-based activation - Os serviços de sistema que utilizam o D-Bus para comunicação entre processos podem ser iniciados sob demanda na primeira vez que uma aplicação do cliente tenta se comunicar com eles Systemd usa D-Bus service files para ativação baseada em ônibus.
  • Device-based activation - Os serviços de sistema que suportam a ativação baseada em dispositivos podem ser iniciados sob demanda quando um determinado tipo de hardware é conectado ou fica disponível Systemd usa device units para a ativação baseada em dispositivo.
  • Path-based activation - Os serviços de sistema que suportam ativação baseada em caminho podem ser iniciados sob demanda quando um determinado arquivo ou diretório muda seu estado Systemd usa path units para ativação baseada em caminho.
  • Mount and automount point management - Systemd monitora e gerencia os pontos de montagem e montagem automática Systemd usa mount units para pontos de montagem e automount units para pontos de montagem automática.
  • Aggressive parallelization - Por causa do uso de ativação baseada em soquetes, systemd pode iniciar os serviços do sistema em paralelo assim que todas as tomadas de escuta estiverem prontas. Em combinação com os serviços de sistema que suportam a ativação sob demanda, a ativação paralela reduz significativamente o tempo necessário para inicializar o sistema.
  • Transactional unit activation logic - Antes de ativar ou desativar uma unidade, systemd calcula suas dependências, cria uma transação temporária e verifica se esta transação é consistente. Se uma transação for inconsistente, systemd automaticamente tenta corrigi-lo e remover trabalhos não essenciais dele antes de relatar um erro.
  • Backwards compatibility with SysV init - Systemd suporta scripts de inicialização SysV, conforme descrito no Linux Standard Base Core Specificationque facilita o caminho de atualização para as unidades de serviço do sistema.

3.1.2. Mudanças de compatibilidade

O sistema de sistema e o gerente de serviços foi projetado para ser na maior parte compatível com o SysV init e Upstart. A seguir estão as alterações de compatibilidade mais notáveis com relação ao sistema Red Hat Enterprise Linux 6 que usou o SysV init:

  • Systemd tem apenas um apoio limitado para os níveis de execução. Ele fornece um número de unidades-alvo que podem ser mapeadas diretamente para esses níveis de execução e, por razões de compatibilidade, também é distribuído com o comando runlevel anterior. Nem todos os alvos do sistema podem ser mapeados diretamente para runlevels e, como conseqüência, este comando pode retornar N para indicar um runlevel desconhecido. Recomenda-se evitar o uso do comando runlevel, se possível. Para mais informações sobre alvos do sistema e sua comparação com runlevels, veja Seção 3.3, “Trabalhando com metas do sistema”.
  • O utilitário systemctl não suporta comandos personalizados. Além dos comandos padrão como start, stop e status, os autores de scripts de inicialização SysV poderiam implementar suporte para qualquer número de comandos arbitrários a fim de fornecer funcionalidade adicional. Por exemplo, o script de inicialização para iptables poderia ser executado com o comando panic, que imediatamente ativou o modo de pânico e reconfigurou o sistema para começar a descartar todos os pacotes de entrada e de saída. Isto não é suportado em systemd e o systemctl só aceita comandos documentados.

    Para mais informações sobre o utilitário systemctl e sua comparação com o anterior service, ver Tabela 3.3, “Comparação da utilidade do serviço com o systemctl”.

  • O serviço systemctl não se comunica com serviços que não tenham sido iniciados por systemd. Quando systemd inicia um serviço de sistema, ele armazena a identificação de seu processo principal, a fim de acompanhar o andamento do mesmo. O utilitário systemctl então usa este PID para consultar e gerenciar o serviço. Conseqüentemente, se um usuário inicia um determinado daemon diretamente na linha de comando, systemctl é incapaz de determinar seu status atual ou pará-lo.
  • Systemd deixa de executar apenas serviços. Anteriormente, quando a seqüência de desligamento foi iniciada, o Red Hat Enterprise Linux 6 e versões anteriores do sistema usavam links simbólicos localizados no diretório /etc/rc0.d/ para parar todos os serviços de sistema disponíveis, independentemente de seu status. Com systemd Só os serviços em funcionamento são interrompidos ao serem encerrados.
  • Os serviços do sistema não conseguem ler a partir do fluxo de entrada padrão. Quando systemd inicia um serviço, ele conecta sua entrada padrão a /dev/null para evitar qualquer interação com o usuário.
  • Os serviços de sistema não herdam nenhum contexto (como as variáveis de ambiente HOME e PATH ) do usuário invocador e sua sessão. Cada serviço é executado em um contexto de execução limpa.
  • Ao carregar um roteiro de inicialização do SysV, systemd lê as informações de dependência codificadas no cabeçalho da Base Padrão Linux (LSB) e as interpreta em tempo de execução.
  • Todas as operações em unidades de serviço estão sujeitas a um timeout padrão de 5 minutos para evitar que um mau funcionamento do serviço congele o sistema. Este valor é codificado para serviços que são gerados a partir de initscripts e não podem ser alterados. Entretanto, arquivos de configuração individuais podem ser usados para especificar um valor de timeout mais longo por serviço, veja Exemplo 3.11, “Alteração do limite de tempo limite”.

Para uma lista detalhada das mudanças de compatibilidade introduzidas com systemdVeja o Guia de Planejamento de Migração para o Red Hat Enterprise Linux 7.