systemd (Português)
- Systemd é um sistema e gerenciador de serviços para Linux, compatível com os scripts de inicializações SysV e LS. Systemd fornece recursos de paralelização agressivos, usa socket e ativação D-Bus para iniciar serviços, oferece o início de daemons on-demand, mantém o registro de processos usando grupos de controle Linux, suporte snapshotting e restauração do estado do sistema, preserva pontos de montagens e automontagens e implementa uma lógica de controle elaborado transacional baseada em dependência de serviço. O systemd oferece suporte scripts de init SysV e LSB e funciona como um substituto para o sysvinit. Outras partes incluem um daemon de registro, utilitários para controlar a configuração básica do sistema como o nome do host, data, local, manter uma lista de usuários logados e executar contêineres e máquinas virtuais, contas do sistema, diretórios e configurações de tempo de execução e daemons para gerenciar configuração de redes simples, sincronização de tempo de rede, encaminhamento de log e resolução de nomes.
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 systemctl(1) para mais detalhes.
- Você pode usar todos os comandos de systemctl abaixo com a opção
-H usuário@host
para controlar uma instância de systemd em uma máquina remota. Isso usará SSH para se conectar uma instância remota systemd. - Usuários de Plasma podem instalar systemd-kcmAUR como um frontend gráfico para systemctl. Após a instalação, o módulo será adicionar sob Administração de sistema.
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 sshd.socket
. 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,
netctl
enetctl.service
são equivalentes. - Os pontos de montagem serão automaticamente convertidos para a unit .mount adequada. Por exemplo, especificar
/home
equivale ahome.mount
. - Similar aos pontos de montagem, dispositivos são automaticamente convertidos para a unit .device adequada, portanto, especificar
/dev/sda2
equivale adev-sda2.device
.
Veja systemd.unit(5) para detalhes.
@
(por exemplo, nome@string.service
): isso significa que eles são instâncias de uma unit modelo (em inglês, template), cujo nome real do arquivo não contém a parte string
(por exemplo, nome@.service
). string
é chamado de identificador de instância (em inglês, instance identifier) e é semelhante a um argumento que é passado para a unit modelo quando chamado com o comando systemctl: no arquivo unit, ele irá substituir o especificador %i
.
Para ser mais preciso, antes de tentar instanciar a unit modelo nome@.suffix
, o systemd vai, na verdade, procurar por uma unit com o nome de arquivo exato nome@string.sufixo
, embora por convenção tal "conflito" ocorra raramente, ou seja, a maioria dos arquivos unit contendo um sinal @
são destinados a serem um modelo. Além disso, se uma unit modelo for chamada sem um identificador de instância, ela falhará, pois o especificador %i
não conseguirá ser substituído.- 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 comenable
,disable
emask
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.
Inicia uma unit imediatamente:
# systemctl start unit
Para uma unit imediatamente:
# systemctl stop unit
Reinicia uma unit:
# systemctl restart unit
Pede a uma unit para recarregar sua configuração:
# systemctl reload unit
Mostra o status de uma unit, inclusive se estiver em execução ou não:
$ systemctl status unit
Verifica se a unit já está habilitada ou não:
$ systemctl is-enabled unit
Habilita uma unit para ser iniciada na inicialização:
# systemctl enable unit
Habilita uma unit para ser iniciada 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
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
Mostra a página de manual associado a uma unit (tem que haver suporte no arquivo da unit):
$ systemctl help unit
Recarrega gerenciador de configuração do systemd , procurando por units novas e modificadas:
reload
acima.# systemctl daemon-reload
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 é 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 systemctl show --property=UnitPath
), 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
- Os caminhos de carregamento são completamente diferentes quando se está executando systemd em modo usuário.
- Nomes de unit do systemd só podem conter caracteres alfanuméricos, sublinhados e pontos. Todos outros caracteres devem ser substituídos por escapes no estilo C "\x2d" ou deve-se empregar suas semânticas predefinidas ('@', '-'). Veja systemd.unit(5) e systemd-escape(1) para mais informações.
Veja as units instaladas por seus pacotes para exemplos, bem como a seção de exemplos comentados de systemd.service(5).
#
também podem ser usados em arquivos units, mas apenas em novas linhas. Não use comentários em fim de linha após parâmetros do systemd ou a unidade não conseguirá ativar.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 Requires=B
e After=B
para a seção [Unit]
de A. Se a dependência for opcional, então adicione Wants=B
e After=B
. Nota que Wants=
e Requires=
não implicam After=
, significando que se After=
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 network.target
é puxado por qualquer serviço que configure as interfaces de rede, portanto, ordenando a sua unit personalizada depois disso é o bastante desde que network.target
é 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 Type=
na seção [Service]
:
Type=simple
(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.Type=forking
: 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 especificarPIDFile=
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 definirRemainAfterExit=yes
também para que systemd ainda considere o serviço como ativo depois que o processo foi encerrado.Type=notify
: idêntico aoType=simple
, 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.Type=dbus
: o serviço é considerado pronto quando oBusName
especificado aparece no barramento do sistema do DBus.Type=idle
: systemdvai atrasar a execução do binário do serviço até todos os trabalhos serem despachados. Além desse comportamento, é muito similar aType=simple
.
Veja a página man systemd.service(5) § OPTIONS para uma explicação mais detalhada dos valores de Type
.
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 systemctl edit
(que recarrega o unit automaticamente) ou recarregando todos os units com:
# systemctl daemon-reload
- Você pode usar systemd-delta para ver quais arquivos units foram sobrepostos ou estendidos e o que exatamente foi alterado.
- Use
systemctl cat unit
para ver o conteúdo de um arquivo unit e todos os trechos drop-in associados.
Arquivos unit de substituição
Para substituir o arquivo unit /usr/lib/systemd/system/unit
, crie o arquivo /etc/systemd/system/unit
e reabilite o unit para atualizar os links simbólicos:
# systemctl reenable unit
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 /usr/lib/systemd/system/unit
, crie o diretório /etc/systemd/system/unit.d/
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 /etc/systemd/system/unit.d/override.conf
em seu editor de texto (criando-o, se necessário) e recarrega automaticamente a unit quando você finalizar a edição.
Conflicts=
um arquivo de substituição é necessário.Reverter para versão do vendor
Para reverter quaisquer alterações a uma unit feita usando systemctl edit
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:
/etc/systemd/system/unit.d/dependenciapesonalizada.conf
[Unit] Requires=nova dependência After=nova dependência
Como outro exemplo, para substituir a diretiva ExecStart
para uma unit que não é do tipo oneshot
, crie o seguinte arquivo:
/etc/systemd/system/unit.d/execpersonalizado
[Service] ExecStart= ExecStart=novo comando
Note como ExecStart
deve ser limpado antes de reatribuir [1]. O mesmo ocorre para todo item que pode ser especificado várias vezes, como OnCalendar
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 diferente. 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 telinit RUNLEVEL
.
Obter targets atuais
O comando deve ser no systemd em vez de executar runlevel
:
$ 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 /etc/systemd/system/seu target
que leva um dos níveis de execução existentes como base (você pode examinar /usr/lib/systemd/system/graphical.target
como um exemplo), crie um diretório /etc/systemd/system/seu target.wants
, 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 telinit 5
no Sysvinit.
Alterar target padrão para inicializar
O target padrão é default.target
, que é um link simbólico para graphical.target
. 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 default.target
. 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:
systemd.unit=multi-user.target
(que basicamente corresponde ao antigo nível de execução 3),systemd.unit=rescue.target
(que basicamente corresponde ao antigo nível de execução 1).
Ordem de target padrão
O systemd escolher o default.target
conforme a ordem a seguir:
- Parâmetro de kernel mostrado acima
- Link simbólico de
/etc/systemd/system/default.target
- Link simbólico de
/usr/lib/systemd/system/default.target
Arquivos temporários
"O systemd-tmpfiles cria, exclui e limpa arquivos e diretórios voláteis e temporários". Ele lê arquivos de configuração em /etc/tmpfiles.d/
e /usr/lib/tmpfiles.d/
para descobrir que ações devem ser realizadas. Os arquivos de configuração no primeiro diretório têm precedência sobre o segundo.
Os arquivos de configuração são geralmente fornecidos junto com arquivos de serviço e são nomeados no estilo de /usr/lib/tmpfiles.d/programa.conf
. Por exemplo, o daemon do Samba espera que o diretório /run/samba
exista e tenha as permissões corretas. Portanto, o pacote samba vem com essa configuração:
/usr/lib/tmpfiles.d/samba.conf
D /run/samba 0755 root root
Os arquivos de configuração também podem ser usados para escrever valores em determinados arquivos na inicialização. Por exemplo, se você usa /etc/rc.local
para desativar ativação de dispositivos USB com echo USBE > /proc/acpi/wakeup
, você pode usar o seguinte tmpfile:
/etc/tmpfiles.d/disable-usb-wake.conf
# Path Mode UID GID Age Argument w /proc/acpi/wakeup - - - - USBE
Veja as páginas man systemd-tmpfiles(8) e tmpfiles.d(5) para detalhes.
/sys
uma vez que o serviço systemd-tmpfiles-setup pode ser executado antes dos módulos de dispositivo apropriados serem carregados. Neste caso, você pode verificar se o módulo tem um parâmetro para a opção que pretende definir com modinfo módulo
e definir essa opção com um arquivo de configuração em /etc/modprobe.d. Caso contrário, você terá que escrever uma regra de udev para defeinir o atributo adequado logo que o dispositivo aparecer.Timers
Um timer (em português, temporizador) é um arquivo de configuração de unit cujo nome termina com .timer e codifica informações sobre um temporizador controlado e supervisionado por systemd, para ativação baseada em temporizador. Veja systemd (Português)/Timers (Português).
Montagem
O systemd é responsável pela montagem das partições e sistemas de arquivos especificados em /etc/fstab
. O systemd-fstab-generator(8) converte todas as entradas do /etc/fstab
em units de systemd, isso é executado no momento da inicialização e sempre que a configuração do gerenciador do sistema é recarregada.
O systemd estende os recursos habituais do fstab e oferece opções adicionais de montagem. Eles afetam as dependências da unit de montagem, elas podem, por exemplo, garantir que uma montagem seja executada somente quando a rede estiver ativa ou apenas quando outra partição for montada. A lista completa de opções específicas de montagem systemd, tipicamente prefixadas com x-systemd.
, é detalhada em systemd.mount(5) § FSTAB.
Um exemplo dessas opções de montagem no contexto de automontagem, que significa montar somente quando o recurso é necessário, e não automaticamente no momento da inicialização, é fornecido em fstab#Automontagem com systemd.
Automontagem de partição GPT
Em um disco particionado em GPT, systemd-gpt-auto-generator(8) vai montar partições seguindo a Discoverable Partitions Specification, de forma que elas podem ser omitidas do fstab
.
Automontagem de partição de sistema EFI requer que o gerenciador de boot configure a variável EFI LoaderDevicePartUUID. Apenas systemd-boot é conhecido por fazer isso.
Para que a automontagem de /var
e /var/tmp
funcione, o PARTUUID deve corresponder ao hash SHA256 HMAC do tipo de partição UUID obtido pelo ID da máquina. O PARTUUID necessário pode ser obtido usando:
$ systemd-id128 -u --app-specific=UUID-tipo-partição machine-id
Substitua UUID-tipo-partição
com o valor de UUID do tipo de partição apropriado da Discoverable Partitions Specification.
/etc/machine-id
, isso torna impossível saber o PARTUUID necessário antes do sistema ser instalado.A automontagem de uma partição pode ser desativada alterando o tipo da partição GUID ou configurando o bit 63 "do not automount" do atributo da partição, consulte gdisk#Prevent GPT partition automounting.
systemd-sysvcompat
A função principal de systemd-sysvcompat (necessário para base) é fornecer o executável init tradicional do Linux. Para os sistemas controlados por systemd, o init
é apenas um link simbólico para seu executável systemd
.
Além disso, ele também fornece 6 atalhos convenientes que usuários do SysVinit podem querer usar. Os atalhos convenientes são halt(8), poweroff(8), reboot(8), runlevel(8)[link inativo 2020-09-13], shutdown(8) e telinit(8)[link inativo 2020-09-13]. Cada um desses 6 comandos é um link simbólico para systemctl
e regulados pelo comportamento do systemd. Então, a discussão em #Gerenciamento de energia se aplica a halt
, poweroff
, reboot
e shutdown
. A discussão em #Mapeamento entre níveis do SysV e targets do systemd se aplica a runlevel
e telinit
.
Universos do systemd
Alguns blocos de construção (não exaustivos) do systemd são:
- systemd-boot — um gerenciador de boot UEFI simples;
- systemd-homed — contas de usuários (humanos) portáteis;
- systemd-logind — gerenciamento de sessão;
- systemd-networkd — gerenciamento de configuração de rede;
- systemd-nspawn — contêiner de espaço de nomes leves;
- systemd-resolved — resolução de nomes de rede;
- systemd-timesyncd — sincronização de tempo do sistema por toda a rede;
- systemd/Journal — regitros log de sistema;
- systemd/Timers — uma alternativa para o cron.
Dicas e truques
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:
/etc/systemd/system/foo.service
[Unit] ... Wants=network-online.target After=network-online.target ...
O serviço de espera de rede do aplicativo específico que gerencia a rede também deve ser ativado para que network-online.target
reflita adequadamente o status da rede.
- Se estiver usando NetworkManager,
NetworkManager-wait-online.service
está habilitado comNetworkManager.service
. Verifque se neste caso comsystemctl is-enabled NetworkManager-wait-online.service
. Se ele não estiver habilitado, então habilite novamenteNetworkManager.service
. - No caso de netctl, habilite o
netctl-wait-online.service
. - Se estiver usando systemd-networkd,
systemd-networkd-wait-online.service
é habilitado comsystemd-networkd.service
. Verifique se este é o caso comsystemctl is-enabled systemd-networkd-wait-online.service
.
Para explicações mais detalhadas, veja Running services after the network is up no wiki do systemd.
Habilitar units instaladas por padrão
O Arch Linux vem com /usr/lib/systemd/system-preset/99-default.preset
contendo disable *
. 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 /etc/systemd/system-preset/99-default.preset
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 systemd.preset(5) 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, listas brancas/negras 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 strace, stderr e facilidades de saída e registro de erro do journalctl. 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 sobre como fazer sandboxing como systemd pode ser implementado:
CapabilityBoundingSet
define uma lista branca definida de capacidades permitidas, mas também pode ser usado para inserir em lista negra uma capacidade específica para uma unit.- A capacidade
CAP_SYS_ADM
, por exemplo, que deve ser um dos objetivos de um sandbox seguro:CapabilityBoundingSet=~ CAP_SYS_ADM
- A capacidade
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 SYSTEMD_LOG_LEVEL
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 -f
/--follow
.
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 journalctl -u foounit
não mostra nenhuma saída para um serviço de curta duração, veja o PID em vez disso. Por exemplo, se systemd-modules-load.service
falha, e systemctl status systemd-modules-load
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 _SYSTEMD_UNIT
e _COMM
são coletados de forma assíncrona e invocam o diretório /proc
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 SCM_CREDENTIALS
. 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 systemd-analyse blame
, o NetworkManager está sendo relatado como tendo uma quantidade anormalmente grande de tempo para iniciar.
O problema para alguns usuários foi devido a /var/log/journal
se tornar muito grande. Isso pode ter outros impactos no desempenho, como systemctl status
ou journalctl
. 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, /usr/lib/tmpfiles.d/systemd.conf
especifica os atributos da ACL para os diretórios sob /var/log/journal
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 /var/log/journal
.
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.