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ório Descriçã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 unidade Extensão do arquivo Descrição
Unidade de serviço .service Um serviço de sistema.
Unidade alvo .target Um grupo de unidades do
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.
Tipo de unidade Extensão do arquivo Descrição
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 Specification que 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.
3.2. GERENCIAMENTO DE SERVIÇOS DE SISTEMA
As versões anteriores do Red Hat Enterprise Linux, que eram distribuídas com SysV init ou Upstart, usavam init scripts localizado no diretório /etc/rc.d/init.d/. Estes scripts init eram tipicamente escritos em Bash, e permitiam ao administrador de sistemas controlar o estado dos serviços e daemons em seu sistema. Começando com o Red Hat Enterprise Linux 7, estes scripts de inicialização foram substituídos por service units.
As unidades de serviço terminam com a extensão do arquivo .service e servem a um propósito similar ao dos scripts de inicialização. Para visualizar, iniciar, parar, reiniciar, ativar ou desativar serviços de sistema, use o comando systemctl como descrito em Comparação do utilitário de serviço com
systemctl, Comparação do utilitário chkconfig com systemctl, e mais adiante nesta seção. Os comandos service e chkconfig ainda estão disponíveis no sistema e funcionam como esperado, mas só estão incluídos por razões de compatibilidade e devem ser evitados.
serviço systemctl Descrição service name start systemctl start name.service Inicia um serviço.
service name stop systemctl stop name.service Interrompe um serviço.
service name restart systemctl restart
name.service Recomeça um serviço.
service name condrestart systemctl try-restart name.service
Reinicia um serviço somente se ele estiver em funcionamento.
service name reload systemctl reload name.service
Recarregar a configuração.
service name status systemctl status name.service systemctl is-active name.service
Verifica se um serviço está funcionando.
service --status-all systemctl list-units --type
service --all Exibe o status de todos osserviços.
Tabela 3.4. Comparação do utilitário chkconfig com o systemctl
chkconfig systemctl Descrição
chkconfig name on systemctl enable name.service
Possibilita um serviço.
chkconfig name off systemctl disable name.service
Desabilita um serviço.
chkconfig --list name systemctl status name.service
systemctl is-enabled name.service
Verifica se um serviço está habilitado.
chkconfig --list systemctl list-unit-files --
type service Relaciona todos os serviços everifica se eles estão habilitados.
chkconfig --list systemctl list-dependencies
--after Lista os serviços que sãoordenados para começar antes da unidade especificada.
chkconfig --list systemctl list-dependencies
--before Lista os serviços que sãoencomendados para começar após a unidade especificada.
chkconfig systemctl Descrição