systemd (Português)

Status de tradução: Esse artigo é uma tradução de Systemd. Data da última tradução: 2020-06-29. Você pode ajudar a sincronizar a tradução, se houver alterações na versão em inglês.

Uso básico do systemctl

O principal comando usado para introspecção e controle systemd é systemctl. Alguns de seus usos são examinando o estado do sistema e gerenciando o sistema e serviços. Consulte para mais detalhes.

Analisando o estado do sistema

Mostre status do sistema usando:

$ systemctl status

Liste units em execução:

$ systemctl

ou:

$ systemctl list-units

Liste units que falharam:

$ systemctl --failed

Os arquivos units disponíveis podem ser vistos em /usr/lib/systemd/system/ e /etc/systemd/system/ (este último tem precedência). Liste os arquivos unit instalados com:

$ systemctl list-unit-files

Mostre slice de cgroup, memória e pai de um PID:

$ systemctl status pid

Usando units

As units podem ser, por exemplo, serviços (.service), pontos de montagem (.mount), dispositivos (.device) ou soquetes (.socket).

Quando usa systemctl, você geralmente tem que especificar o nome completo do arquivo unit, incluindo o sufixo, por exemplo . No entanto, existem algumas formas curtas de especificar a unit nos seguintes comandos systemctl:

Se você não especificar o sufixo, systemctl presumirá .service. Por exemplo, e são equivalentes.
Os pontos de montagem serão automaticamente convertidos para a unit .mount adequada. Por exemplo, especificar equivale a .
Similar aos pontos de montagem, dispositivos são automaticamente convertidos para a unit .device adequada, portanto, especificar equivale a .

Veja systemd.unit(5) para detalhes.

Dica:

A maioria dos comandos a seguir também funciona se várias units forem especificadas; veja systemctl(1) para obter mais informações.
A opção --now pode ser usada em conjunto com enable, disable e mask para iniciar, parar ou mascarar, respectivamente, imediatamente a unit em vez de após reinicializar.
Um pacote pode oferecer units para diferentes finalidades. Se você acabou de instalar um pacote, pacman -Qql pacote | grep -Fe .service -e .socket pode ser usado para verificar e localizá-las.

Verificando status

Páginas de manual associadas a uma unit (conforme suportado pela unit):

$ systemctl help unit

Status de uma unit, incluindo se está em execução ou não:

$ systemctl status unit

Verifica se uma unit está habilitada ou não:

$ systemctl is-enabled unit

Iniciando, reiniciando, recarregando

Inicia uma unit imediatamente:

# systemctl start unit

Para uma unit imediatamente:

# systemctl stop unit

Reinicia uma unit:

# systemctl restart unit

Recarrega uma unit e sua configuração:

# systemctl reload unit

Recarrega a configuração do gerente do systemd, procurando por units novas ou alteradas:

# systemctl daemon-reload

Habilitando

Habilita uma unit para iniciar automaticamente na inicialização:

# systemctl enable unit

Habilita uma unit para iniciar automaticamente na inicialização e inicia-a imediatamente:

# systemctl enable --now unit

Desabilita uma unit para não ser iniciada durante a inicialização:

# systemctl disable unit

Reabilita (ou seja, desabilita e habilita novamente) uma unit; por exemplo, no caso de sua seção tenha mudado da última vez que foi habilitada:

# systemctl reenable unit

Mascarando

Mascara uma unit para tornar impossível iniciá-la (Tanto manualmente quanto como uma dependência, o que torna mascaragem perigoso):

# systemctl mask unit

Desmascara uma unit:

# systemctl unmask unit

Gerenciamento de energia

polkit é necessário para o gerenciamento de energia como um usuário sem privilégios. Se você está em uma sessão de usuário local systemd-logind e nenhuma outra sessão está ativa, os seguintes comandos funcionarão sem privilégios de root. Se não (por exemplo, porque outro usuário está conectado em um tty), systemd vai automaticamente pedir a senha de root.

Desliga e reinicia o sistema:

$ systemctl reboot

Desliga e encerra o sistema:

$ systemctl poweroff

Suspende o sistema:

$ systemctl suspend

Coloca o sistema em modo de hibernação:

$ systemctl hibernate

Coloca o sistema em modo de suspensão híbrida:

$ systemctl hybrid-sleep

Escrevendo arquivos unit

A sintaxe de arquivos unit do systemd (systemd.unit(5)) é inspirada nos arquivos .desktop da XDG Desktop Entry Specification , que por sua vez são inspirados nos arquivos .ini do Microsoft Windows. Os arquivos unit são carregados de vários localizações (para ver a lista completa, execute ), mas os principais são (listados da menor para a mais alta precedência):

/usr/lib/systemd/system/: units fornecidas por pacotes instalados
/etc/systemd/system/: units instaladas pelo administrador do sistema

Veja as units instaladas por seus pacotes para exemplos, bem como em .

Manuseando dependências

Com o systemd, dependências podem ser resolvidas através da concepção de arquivos unit corretamente. O caso mais típico é a unit A requerer a unit B para ser executada antes da A ser iniciada. Nesse caso, adicione e para a seção [Unit] de A. Se a dependência for opcional, então adicione e . Nota que Wants= e não implicam , significando que se não for especificado, as duas units serão iniciada em paralelo.

Dependências são normalmente colocadas em serviços e não em #Targets. Por exemplo, o é puxado por qualquer serviço que configure as interfaces de rede, portanto, ordenando a sua unit personalizada depois disso é o bastante desde que é iniciado de qualquer maneira.

Tipos de serviços

Há vários tipos de execução diferentes a considerar quando se escreve um arquivo de serviço personalizado. Isso é definido com o parâmetro na seção :

(padrão): systemd considera que o serviço seja iniciado imediatamente. O processo não deve fazer fork. Não use este tipo se outros serviços precisarem ser ordenados neste serviço, a menos que seja socket ativado.
: systemd considera que o serviço iniciou uma vez que o processo fez fork e o pai encerrou. Para daemons clássicos, use este tipo a menos que você saiba que ele não é necessário. Você deve especificar também, de forma que o systemd possa acompanhar o processo principal.
Type=oneshot: este é útil para os scripts que fazem um trabalho único e, em seguida, saem. Você pode querer definir também para que systemd ainda considere o serviço como ativo depois que o processo foi encerrado.
: idêntico ao , mas com a condição de que o servidor enviará um sinal para systemd quando estiver pronto. A implementação de referência para essa notificação é fornecida por libsystemd-daemon.so.
: o serviço é considerado pronto quando o BusName especificado aparece no barramento do sistema do DBus.
: systemdvai atrasar a execução do binário do serviço até todos os trabalhos serem despachados. Além desse comportamento, é muito similar a .

Veja a página man para uma explicação mais detalhada dos valores de .

Editando units fornecidas

Para evitar conflitos com o pacman, arquivos unit fornecidos por pacotes não devem ser editados diretamente. Há duas formas seguras de modificar um unit sem tocar no arquivo original: crie um novo arquivo unit que se sobreponha ao unit original ou crie trechos drop-in que são aplicados sobre o unit original. Para ambos métodos, você deve recarregar o unit em seguida para aplicar suas alterações. Isso pode ser feito editando o unit com (que recarrega o unit automaticamente) ou recarregando todos os units com:

# systemctl daemon-reload

Arquivos unit de substituição

Para substituir o arquivo unit , crie o arquivo /etc/systemd/system/unit e reabilite o unit para atualizar os links simbólicos.

Alternativamente, execute:

# systemctl edit --full unit

Isso abre /etc/systemd/system/unit em seu editor (copiando a versão instalada se ela não existir ainda) e automaticamente a recarrega quando você finaliza a edição.

Arquivos drop-in

Para criar arquivos drop-in para o arquivo de unidade , crie o diretório e coloque arquivos .conf para substituir ou adicionar novas opções. systemd analisará e aplicará esses arquivos sobre a unit original.

A forma mais fácil de fazer isso é executar:

# systemctl edit unit

Isso abre o arquivo em seu editor de texto (criando-o, se necessário) e recarrega automaticamente a unit quando você finalizar a edição.

Reverter para versão do vendor

Para reverter quaisquer alterações a uma unit feita usando faça:

# systemctl revert unit

Exemplos

Por exemplo, se você só quiser adicionar uma dependência adicional a uma unit, basta criar o seguinte arquivo:

Como outro exemplo, para substituir a diretiva ExecStart para uma unit que não é do tipo , crie o seguinte arquivo:

Note como ExecStart deve ser limpado antes de reatribuir . O mesmo ocorre para todo item que pode ser especificado várias vezes, como para timers.

Mais um exemplo para reiniciar automaticamente um serviço:

/etc/systemd/system/''unit''.d/reiniciar.conf

[Service]
Restart=always
RestartSec=30

Targets

O systemd usa targets para agrupar units por meio de dependências e como pontos de sincronização padronizada. Eles servem a um propósito semelhante, como níveis de execução, mas agem um pouco diferentemente. Cada target é nomeado em vez de numerado e destina-se a servir uma finalidade específica com a possibilidade de ter múltiplos ativos ao mesmo tempo. Alguns targets são implementados herdando todos os serviços de outro target e adicionando serviços adicionais a ele. Há targets do systemd que imitam os níveis de execução SystemVinit comuns para que possa mudar targets usando o comando familiar .

Obter targets atuais

O comando deve ser no systemd em vez de executar :

$ systemctl list-units --type=target

Criar target personalizado

Os níveis de execução que tinham um significado definido no sysvinit (ex.: 0, 1, 3, 5 e 6) têm um mapeamento 1:1 com um target de systemd específico. Infelizmente, não há nenhuma boa forma de fazer o mesmo com os níveis de execução definidos pelo usuário, como 2 e 4. Se você fizer uso deles é sugerido que você faça um target de systemd com um novo nome como que leva um dos níveis de execução existentes como base (você pode examinar como um exemplo), crie um diretório , e então faça um link simbólico dos serviços adicionais de /usr/lib/systemd/system/ que você deseja ativar.

Mapeamento entre níveis do SysV e targets do systemd

Nível de execução do SysV	Target do systemd	Notas
0	runlevel0.target, poweroff.target	Interrrompe o sistema.
1, s, único	runlevel1.target, rescue.target	Modo de usuário único.
2, 4	runlevel2.target, runlevel4.target, multi-user.target	Níveis de execução User-defined/Site-specific. Por padrão, idêntico ao 3.
3	runlevel3.target, multi-user.target	Multi-usuário, não-gráfico. Os usuários geralmente podem acessar através de múltiplos consoles ou via rede.
5	runlevel5.target, graphical.target	Multi-usuário, gráfico. Normalmente tem todos os serviços do nível de execução 3, mais um login gráfico.
6	runlevel6.target, reboot.target	Reiniciar
emergência	emergency.target	Shell de emergência

Alterar target atual

No systemd, targets são expostos via units de targets. Você pode alterá-los assim:

# systemctl isolate graphical.target

Isso só vai mudar o target atual, e não tem nenhum efeito na próxima inicialização. É equivalente aos comandos como telinit 3 ou no Sysvinit.

Alterar target padrão para inicializar

O target padrão é , que é um link simbólico para . Basicamente, ele corresponde ao antigo nível de execução 5.

Para verificar o target atual com systemctl:

$ systemctl get-default

Para alterar o target padrão a ser inicializado, altere o link simbólico . Com systemctl:

# systemctl set-default multi-user.target

Removed /etc/systemd/system/default.target.
Created symlink /etc/systemd/system/default.target -> /usr/lib/systemd/system/multi-user.target.

Alternativamente, acrescente um dos seguintes parâmetros do kernel a seu gerenciador de boot:

(que basicamente corresponde ao antigo nível de execução 3),
(que basicamente corresponde ao antigo nível de execução 1).

Ordem de target padrão

O systemd escolher o conforme a ordem a seguir:

Parâmetro de kernel mostrado acima
Link simbólico de
Link simbólico de

Componentes do systemd

Alguns componentes (não exaustivos) do systemd são:

systemd-boot — simples gerenciador de boot UEFI;
systemd-firstboot — inicialização da configuração básica do sistema antes da primeira inicialização;
systemd-homed — contas portáteis de usuário humano;
systemd-logind — gerenciamento de sessão;
systemd-networkd — gerenciamento de configuração de rede;
systemd-nspawn — contêiner de namespace leve;
systemd-resolved — resolução de nome de rede;
— cria usuários e grupos do sistema e adiciona usuários a grupos na instalação do pacote ou na inicialização;
systemd-timesyncd — sincronização da hora do sistema na rede;
systemd/Journal — registro do sistema;
systemd/Timers — cronômetros monotônicos ou em tempo real para controlar arquivos ou eventos , alternativa razoável ao cron.

systemd.mount - montagem

O systemd é responsável pela montagem das partições e sistemas de arquivos especificados em . O systemd-fstab-generator(8) converte todas as entradas em em unidades do systemd, isso é executado no momento da inicialização e sempre que a configuração do gerenciador de sistema é recarregada.

O systemd estende as capacidades usuais do fstab e oferece opções adicionais de montagem. Eles afetam as dependências da unidade de montagem, eles podem, por exemplo, garantir que uma montagem seja realizada apenas quando a rede estiver ativa ou apenas quando outra partição for montada. A lista completa de opções de montagem específicas do systemd, normalmente prefixadas com , É detalhada em .

Um exemplo dessas opções de montagem no contexto de montagem automática, que significa montagem apenas quando o recurso é necessário, em vez de automaticamente no momento da inicialização, é fornecido em fstab (Português)#Automontagem com systemd.

Montagem automática de partição GPT

Em um disco particionado GPT, o montará partições seguindo a Especificação de partições detectáveis, portanto, podem ser omitidas de fstab.

A montagem automática de partição do sistema EFI requer que o carregador de inicialização defina a variável EFI LoaderDevicePartUUID. Apenas systemd-boot é conhecido por fazer isso.

Para que a montagem automática de e funcione, o PARTUUID deve corresponder ao hash SHA256 HMAC do tipo de partição UUID codificado pela ID da máquina. O PARTUUID necessário pode ser obtido usando:

$ systemd-id128 -u --app-specific=partição-tipo-UUID id-da-máquina

Substitua pelo valor de UUID do tipo de partição apropriado da Especificação de Partições Detectáveis.

A montagem automática de uma partição pode ser desabilitada alterando o tipo GUID da partição ou definindo o atributo de partição bit 63 "não montar automaticamente", consulte gdisk#Prevent GPT partition automounting.

systemd-sysvcompat

A função principal do (requerido por ) é fornecer o binário tradicional do linux init. Para sistemas controlados pelo systemd, init é apenas um link simbólico para seu executável .

Além disso, ele também fornece 4 atalhos de conveniência aos quais os usuários do SysVinit podem estar acostumados. Os atalhos de conveniência são , , e shutdown(8). Cada um desses 4 comandos é um link simbólico para , e governado pelo comportamento do systemd. Portanto, a discussão em #Gerenciamento de energia se aplica.

Os sistemas baseados em Systemd podem desistir dos métodos de compatibilidade do System V usando o parâmetro de boot (consulte, por exemplo, [solved] /bin/init is in systemd-sysvcompat ?) e argumentos de comando do , nativo do systemd .

systemd-tmpfiles - arquivos temporários

O "systemd-tmpfiles cria, apaga e limpa arquivos e diretórios temporários e voláteis." Ele lê os arquivos de configuração em e para descobrir quais ações executar. Os arquivos de configuração do diretório anterior têm precedência sobre os do diretório anterior.

Os arquivos de configuração geralmente são fornecidos junto com os arquivos de serviço e são nomeados no estilo de . Por exemplo, o daemon Samba espera que o diretório /run/samba exista e tenha as permissões corretas. Portanto, o pacote vem com esta configuração:

Os arquivos de configuração também podem ser usados para gravar valores em certos arquivos na inicialização. Por exemplo, se você usou para desativar a ativação de dispositivos USB com , você pode usar o seguinte arquivo tmp:

Veja as páginas do manual systemd-tmpfiles(8) e para detalhes.

Dicas e truques

Ferramentas de configuração GUI

SystemdGenie — Utilitário de gerenciamento systemd baseado em tecnologias KDE.

https://invent.kde.org/system/systemdgenie || systemdgenie

Executando serviços após a rede estar ativa

Para atrasar um serviço até depois que a rede está ativa, inclua as seguintes dependências no arquivo .service:

O serviço de espera de rede do aplicativo específico que gerencia a rede também deve ser ativado para que reflita adequadamente o status da rede.

Se estiver usando NetworkManager, está habilitado com . Verifque se neste caso com . Se ele não estiver habilitado, então reabilite .
No caso de netctl, habilite o .
Se estiver usando systemd-networkd, systemd-networkd-wait-online.service é habilitado com . Verifique se este é o caso com . Se ele não estiver habilitado, então reabilite .

Para explicações mais detalhadas, veja Network configuration synchronization points.

Se um serviço precisar realizar consultas DNS, ele também deve ser solicitado após :

Veja systemd.special(7) § Special Passive System Units.

Para que tenha algum efeito, ele precisa de um serviço que o extraia via e se ordena antes dele com . Normalmente, isso é feito por Resolvedores de DNS locais.

Verifique qual serviço ativo, se houver, está puxando com:

$ systemctl list-dependencies --reverse nss-lookup.target

Habilitar units instaladas por padrão

O Arch Linux vem com contendo . Isso faz com que o systemctl preset desabilite todas as unidades por padrão, de forma que quando um novo pacote é instalado, o usuário deve habilitar manualmente a unit.

Se este comportamento não for desejado, basta criar um link simbólico de para /dev/null para sobrescrever o arquivo de configuração. Isso fará com que o systemctl preset habilite todas as units que forem instaladas – independentemente do tipo de unit – a menos que especificado em outro arquivo em um dos diretórios de configuração do systemctl preset. Units de usuário não são afetadas. Veja para mais informações.

Usando ambientes de aplicativos em sandbox

Um arquivo de unit pode ser criado como uma sandbox para isolar aplicativos e seus processos em um ambiente virtual reforçado. O systemd alavanca espaços de nomes, lista de permitidos/negados de capacidades e grupos de controle ("cgroups") para processos contêineres através de uma extensa configuração do ambiente de execução—.

O aprimoramento de um arquivo existente de unit do systemd com um aplicativo de sandboxing normalmente requer testes de tentativa e erro acompanhados pelo uso generoso de , stderr e facilidades de saída e registro de erro do . Você pode querer pesquisar primeiro a documentação original para testes já feitos para basear os testes. Para obter um ponto de partida para as possível opções de segurança, execute

$ systemd-analyze security unit

Alguns exemplos de como o sandboxing com systemd pode ser implementado:

CapabilityBoundingSet define uma lista de capacidades () que são permitidas ou negadas para uma unit. Veja .
- A capacidade , por exemplo, que deve ser um dos objetivos de um sandbox seguro:

Notificação sobre serviços com falha

In order to notify about service failures, a directive needs to be added to the according service file, for example by using a drop-in configuration file}. Adding this directive to every service unit can be achieved with a top-level drop-in configuration file. For details about top-level drop-ins, see systemd.unit(5).

Create a top-level drop-in for services:

This adds to every service file. If some_service_unit fails, will be started to handle the notification delivery (or whatever task it is configured to perform).

Create the template unit:

You can create the failure-notification.sh script and define what to do or how to notify (mail, gotify, xmpp, etc.). The will be the name of the failed service unit and will be passed as argument to the script.

In order to prevent a regression for instances of , create an empty drop-in configuration file with the same name as the top-level drop-in (the empty service-level drop-in configuration file takes precedence over the top-level drop-in and overrides the latter one):

# mkdir -p /etc/systemd/system/failure-notification@.service.d # touch /etc/systemd/system/failure-notification@.service.d/toplevel-override.conf

Solução de problemas

Investigar serviços que falharam

Para encontrar os serviços systemd que falharam em iniciar:

$ systemctl --state=failed

Para encontrar o porquê de eles terem falhado, examine a saída do log. Consulte systemd/Journal#Filtrando saída para detalhes.

Diagnosticar problemas de inicialização

O systemd tem várias opções para diagnosticar problemas com o processo de inicialização. Veja Depuração de inicialização para instruções mais gerais e opções para capturar mensagens de inicialização antes que o systemd assuma o processo de inicialização. Veja também a documentação de depuração do systemd.

Diagnosticar um serviço

Se algum serviço do systemd se comportar mal ou você quiser obter mais informações sobre o que está acontecendo, defina a variável de ambiente com debug. Por exemplo, para executar o daemon systemd-networkd no modo de depuração:

Adicione um arquivo drop-in para o serviço adicionando as duas linhas:

[Service] Environment=SYSTEMD_LOG_LEVEL=debug

Ou, de forma equivalente, defina a variável de ambiente manualmente:

# SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd

então, reinicie systemd-networkd e monitore o journal para o serviço com a opção /.

Desligamento/reinicialização demora demais

Se o processo de desligamento leva um tempo muito longo (ou parece estar congelado) muito provavelmente um serviço que não se encerra é o responsável. O systemd espera um tempo para cada serviço encerrar antes de tentar matá-lo. Para descobrir se você foi afetado, veja esse artigo.

Processos de curta duração não parecem registrar qualquer saída

Se não mostra nenhuma saída para um serviço de curta duração, veja o PID em vez disso. Por exemplo, se falha, e mostra que executou com PID 123, então você talvez possa ver uma saída no journal por esse PID, ou seja, journalctl -b _PID=123. Campos de metadados para o journal como e são coletados de forma assíncrona e invocam o diretório para o processo existente. A solução deste problema requer fixar o kernel para fornecer esses dados através de uma conexão de socket, semelhante ao . Em resumo, é um erro. Tenha em mente que os serviços imediatamente falhos podem não imprimir nada para o journal conforme o design do systemd.

Tempo de inicialização aumentando com o tempo

Depois de usar o systemd-analyze, vários usuários notaram que o tempo de inicialização aumentou significativamente em comparação com o que costumava ser. Depois de usar , o NetworkManager está sendo relatado como tendo uma quantidade anormalmente grande de tempo para iniciar.

O problema para alguns usuários foi devido a se tornar muito grande. Isso pode ter outros impactos no desempenho, como ou . Como tal, a solução é remover todos os arquivos dentro da pasta (idealmente fazendo um backup em algum lugar, pelo menos temporariamente) e, em seguida, definindo um limite de tamanho de arquivo de diário conforme descrito em systemd/Journal (Português)#Limite no tamanho do journal.

systemd-tmpfiles-setup.service não inicia na inicialização do sistema

A partir do systemd 219, especifica os atributos da ACL para os diretórios sob e, portanto, requer que o suporte da ACL seja ativada para o sistema de arquivos em que o journal reside.

Veja Listas de Controle de Acesso#Habilitar ACL para instruções sobre como habilitar ACL no sistema de arquivos que hospeda .

Desabilitar modo de emergência em máquina remota

Você pode desabilitar o modo de emergência em uma máquina remota, por exemplo, uma máquina virtual hospedada no Azure ou no Google Cloud. É porque se o modo de emergência for acionado, a máquina será bloqueada de se conectar à rede.

# systemctl mask emergency.service # systemctl mask emergency.target

Veja também

Wikipedia:pt:systemd
Site oficial do systemd
Páginas man
Outras distribuições:
História do blogue do Lennart, atualização 1, atualização 2, atualização 3, resumo
systemd para administradores (PDF)
Como usar o systemctl para gerenciar serviços e units do systemd
Gerenciamento de sessão com systemd-logind
Realce de sintaxe do Emacs para arquivos do systemd
Artigo introdutório em duas partes na revista The H Open.

This article is issued from Archlinux. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.