Jump to content

# systemd (Português)

10 languages

- Deutsch
- English
- Español
- Suomi
- Français
- Magyar
- Italiano
- 日本語
- Русский
- 中文（简体）

From ArchWiki

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

Artigos relacionados

- systemd/User
- systemd/Timers
- systemd/Journal
- systemd FAQ
- init
- udev
- Melhorando o desempenho/Processo de inicialização
- Permitir desligamento por usuários

Da página web do projeto:

  systemd é um conjunto de softwares que fornecem blocos de construção básicos para um sistema Linux. Ele fornece um gerenciador de sistema e serviços que é executado como PID 1 e inicia o resto do sistema. systemd fornece capacidades agressivas de paralelização, usa a ativação de soquetes e D-Bus para iniciar serviços, oferece partida sob demanda de daemons, mantém o controle de processos usando grupos de controle Linux, mantém pontos de montagem e montagem automática e implementa uma elaborada lógica de controle de serviços baseada em dependência transacional. O systemd suporta scripts de inicialização 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 hostname, date, locale, mantem uma lista de usuários logados e rodando containers e máquinas virtuais, contas do sistema, diretórios e configurações de tempo de execução e daemons para gerenciar a configuração simples da rede, sincronização de tempo de rede, encaminhamento de log e resolução de nomes.

Historicamente o que systemd chama por "serviço", ou do inglês "service", era conhecido por se chamar daemon, tal qual o significado é: qualquer programa que esteja ativo no "plano de fundo" (background) como um processo (sem um terminal ou interface de usuário), normalmente aguardando a ocorrência de eventos e oferecendo serviços. Um bom exemplo é um servidor web que espera por um requerimento para entregar uma página, ou um servidor ssh a espera de alguém que tente logar. Enquanto que estas aplicações citadas são cheias de funcionalidades, existem daemons que o trabalho não é tão aparente. Daemons são para tarefas como escrever mensagens em um arquivo de log (por exemplo `syslog`, `metalog`) ou para manter o horário do sistema pontual (por exemplo ntpd). Para mais informações, veja daemon(7).

Nota: Para uma explicação detalhada do porquê Arch migrou para o systemd, consulte esta mensagem do fórum internacional.

## 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.

Dica:

- 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 systemdgenie como um frontend gráfico para systemctl. Após a instalação, o módulo será adicionado sob "Sistema".

### Usando units

As units geralmente incluem, mas não estão limitadas a, serviços (.service), pontos de montagem (.mount), dispositivos (.device) ou soquetes (.socket).

Ao utilizar systemctl, geralmente é necessário especificar o nome completo do arquivo unit, incluindo seu 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` e `netctl.service` são equivalentes.
- Os pontos de montagem serão automaticamente convertidos para a unit .mount adequada. Por exemplo, especificar `/home` equivale a `home.mount`.
- Similar aos pontos de montagem, dispositivos são automaticamente convertidos para a unit .device adequada, portanto, especificar `/dev/sda2` equivale a `dev-sda2.device`.

Veja systemd.unit(5) para detalhes.

Nota: Alguns nomes de unit contêm um sinal `@` (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 `name@.suffix`, o systemd procurará, na verdade, uma unit com o nome exato do arquivo `name@string.suffix`, embora por convenção tal "conflito" aconteça 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 geralmente falhará (exceto com certos comandos systemctl, como `cat`).

Os comandos da tabela abaixo operam sobre units do sistema, pois `--system` é o padrão implícito para systemctl. Em vez disso, para operar em units de usuário (para o usuário chamador), use systemctl --user sem privilégios de root. Veja também systemd/User#Basic setup para habilitar/desabilitar units de usuário para todos os usuários.

Dica:

- A maioria dos comandos também funcionam 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.

Ação | Comando | Nota
--- | --- | ---
Analisando o status do sistema
Mostrar status do sistema | `systemctl status` |
Lista units em execução | `systemctl` or `systemctl list-units` |
Lista units com falhas | `systemctl --failed` |
Listar arquivos de unit1 instalados | `systemctl list-unit-files` |
Mostra status do processo para um PID | `systemctl status pid` | parte dos grupos de controle ("cgroups"), memória e pais
Verificando o status unit
Mostra uma página do manual associada a uma unit | `systemctl help unit` | como suportado pela unit
Status de uma unit | `systemctl status unit` | incluindo se está em execução ou não
Checa se uma unit está habilitada | `systemctl is-enabled unit` |
Iniciando, reiniciando e recarregando um unit
Iniciar imediatamente uma unit | `systemctl start unit` como root |
Parar imediatamente uma unit | `systemctl stop unit` como root |
Reiniciar uma unit | `systemctl restart unit` como root |
Recarregar uma unit e sua configuração | `systemctl reload unit` como root |
Recarregar a configuração2 do gerenciador do systemd | `systemctl daemon-reload` como root | procura por units novas ou alteradas
Habilitando um unit
Habilitar uma unit para iniciá-la automaticamente no boot | `systemctl enable unit` como root |
Habilitar uma unit para iniciá-la automaticamente no boot e iniciá-la imediatamente | `systemctl enable --now unit` como root |
Desabilitar uma unit para não iniciar mais no boot | `systemctl disable unit` como root |
Reabilitar uma unit3 | `systemctl reenable unit` como root | ou seja, desabilita e habilita novamente
Mascarando um unit
Mascarar uma unit para tonar impossível o seu início4 | `systemctl mask unit` como root |
Desmascarar uma unit | `systemctl unmask} unit` como root |

1. Veja systemd.unit(5) § UNIT FILE LOAD PATH para os diretórios onde os arquivos das units disponíveis podem ser encontrados.
2. Isso não solicita às units alteradas que recarreguem suas próprias configurações (veja Recarregar).
3. Por exemplo, no caso de sua seção `[Install]` tenha mudado desde a última vez que foi habilitada.
4. Tanto manualmente quanto como dependência, o que torna o mascaramento perigoso. Verifique a existência de units mascarados com:

       $ systemctl list-unit-files --state=masked

### 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.

Ação | Comando
--- | ---
Desliga e reinicia o sistema | `systemctl reboot`
Desliga e encerra o sistema | `systemctl poweroff`
Suspende o sistema | `systemctl suspend`
Coloca o sistema em hibernação (escreve RAM para o disco) | `systemctl hibernate`
Coloca o sistema em um estado de suspensão híbrida (também chamado de "suspender para ambos", salva RAM para o disco e então suspende) | `systemctl hybrid-sleep`
Primeiro suspende o sistema, o acorda após um tempo determinado somente para hibernar o sistema | `systemctl suspend-then-hibernate`
Reinicia apenas o espaço de usuário com #Reinício suave | `systemctl soft-reboot`

#### Reinício suave

O reinício suave é uma forma especial de reiniciar somente o espaço de usuário, do qual não envolve o kernel. A função é implementada pelo systemd-soft-reboot.service(8) e pode ser invocada através de `systemctl soft-reboot`. Assim como kexec, ele pula a reinicialização do firmware, com a diferença adicional do sistema não passar pela reinicialização do kernel e pelo initramfs. Além disso, dispositivos criptografados que estejam destravados permanecem conectados.

Quando `/run/nextroot/` possui uma hierarquia de sistema de arquivos root válida (por exemplo se o root está montado em outra distribuição ou outro snapshot), soft-reboot pode trocar o sistema root para dentro de outros dispositivos, permitindo então a troca em outras instalações sem perder estados gerenciados pelo kernel, por exemplo a rede de internet.

Dica: `/run/nextroot/` não é necessariamente um ponto de montagem ou dependente de um dispositivo físico. Por exemplo, ele pode residir em `/run/` tmpfs. systemd irá transformar automaticamente `/run/nextroot/` em um ponto de montagem quando ocorrer um soft-reboot.
Nota: Não invoque `systemctl soft-reboot` depois de uma atualização de pacotes que possa acabar por regerar a imagem do kernel e o initramfs.

## 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 `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

Nota:

- 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 em systemd.service(5) § EXAMPLES.

Dica: Comentários prefixados com `#` 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.

systemd-analyze(1) pode ajudar a verificar o trabalho. Veja a página do manual e busque a seção `systemd-analyze verify FILE...`.

### 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 é quando a unit A requer 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` é obtido por qualquer serviço que configure suas 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 especificar `PIDFile=` 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 `RemainAfterExit=yes` também para que systemd ainda considere o serviço como ativo depois que o processo foi encerrado. Definindo `RemainAfterExit=yes` é apropriado para as units que mudam o estado do sistema (por exemplo, montar alguma partição). Veja também [1] para conhecer as diferenças entre simple e oneshot.
- `Type=notify`: idêntico ao `Type=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 o `BusName` 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 a `Type=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

Dica:

- 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.

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.

Nota: As units de substituição continuarão sendo usadas mesmo que o Pacman atualize as units originais no futuro. Esse método dificulta a manutenção do sistema e, portanto, a próxima abordagem é a preferível.

#### 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 --drop-in=nome_drop_in

Isso abre o arquivo `/etc/systemd/system/unit.d/nome_drop_in.conf` em seu editor de texto (criando-o, se necessário) e recarrega automaticamente a unit quando você finalizar a edição. Omitir a opção `--drop-in=` resultará na escolha do uso de nome de arquivo padrão `override.conf` pelo systemd.

Nota:

- A chave ainda deve ser colocada na seção apropriada no arquivo de substituição.
- Nem todas as chaves podem ser substituídas por arquivos drop-in. Por exemplo, para alterar `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`, crie o seguinte arquivo:

    /etc/systemd/system/unit.d/execpersonalizado

    [Service]
    ExecStart=
    ExecStart=novo comando

Note como `ExecStart` deve ser limpado antes de reatribuir [2]. 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 comuns do SystemVinit.

### 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 | poweroff.target | Interrrompe o sistema.
1, s, único | rescue.target | Modo de usuário único.
2, 4 | multi-user.target | Níveis de execução User-defined/Site-specific. Por padrão, idêntico ao 3.
3 | 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 | 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 | 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 escolhe o `default.target` conforme a ordem a seguir:

1. Parâmetro de kernel mostrado acima
2. Link simbólico de `/etc/systemd/system/default.target`
3. Link simbólico de `/usr/lib/systemd/system/default.target`

## Componentes do systemd

Alguns componentes (sendo uma lista não exaustiva, ou seja, um resumo do todo) do systemd são:

- kernel-install — Para automaticamente mover kernels e as respectivos imagens initramfs para a partição de boot;
- systemd-analyze(1) Pode ser usado para determinar o desempenho da inicialização, formar estatísticas, recuperar outro estado de boot, realizar buscas de informações e verificar a exatidão de arquivos unit. É também usado para acessar funções especiais, sendo útil para depurações avançadas;
- systemd-boot — simples gerenciador de boot UEFI;
- systemd-creds — Para armazenar com segurança e recuperar credenciais usadas por units do systemd;
- systemd-cryptenroll — Inscreve PKCS#11, FIDO2, token/dispositivos TPM2 para volumes criptografados com LUKS2;
- 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;
- systemd-run(1) / run0(1) — Temporariamente e interativamente adquire privilégios elevados ou diferenciados;
- systemd-stub(7) — um stub de boot UEFI usado para criar imagens de kernel unificadas.
- systemd-sysusers(8) — 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 `.service`, alternativa razoável ao cron.

### systemd.mount - 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 em `/etc/fstab` 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 `x-systemd.`, é detalhada em systemd.mount(5) § FSTAB.

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 sistemas inicializados por UEFI, se condições específicas forem atendidas, systemd-gpt-auto-generator(8) montará automaticamente as partições GPT seguindo a Especificação de Partições Detectáveis. Elas podem, portanto, ser omitidas do fstab, e se a partição root é auto-montavél, então `root=` pode ser omitido da linha de comando do kernel.

Os pré-requisitos são:

- O gerenciador/carregador de boot deve definir a variável EFI LoaderDevicePartUUID para que a partição do sistema EFI usada possa ser identificada. Isso é suportado pelo systemd-boot, systemd-stub(7), GRUB (com o `grub.cfg` gerado por grub-mkconfig, se for um `grub.cfg` customizado o mesmo requer que seja carregado o módulo bli e do gerenciador de boot rEFInd (não habilitado por padrão). Isso pode ser verificado executando `bootctl` e checando o status de `Boot loader sets ESP information` ou o status de `Stub sets ESP information` ao inicializar via imagens de kernel unificadas.
- A partição do root deve estar no mesmo disco físico que a partição do sistema EFI utilizado. Outras partições que serão montadas automaticamente devem estar no mesmo disco físico que a partição raiz. Isto significa basicamente que todas as partições montadas automaticamente devem compartilhar o mesmo disco físico com o ESP.
- O ponto de montagem `/efi` deve ser criado manualmente (se desejado), caso contrário `systemd-gpt-auto-generator` usará `/boot`.

Atenção: Tenha muito cuidado ao criar `/efi` em um sistema existente ao usar a montagem automática GPT. `/efi` será usado como ponto de montagem padrão no próximo boot, o que pode deixar seu sistema em um estado inconsistente com um diretório `/boot` vazio. Você provavelmente precisará reinstalar seu(s) kernel(s) e/ou microcode, regenerar seu initramfs, etc...
Dica: 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", veja Impedir a montagem automática da partição GPT.

##### /var

Para a montagem automática do `/var` funcionar, a PARTUUID deve corresponder ao hash SHA256 HMAC do tipo de partição UUID (`4d21b016-b534-45c2-a9fb-5c16e091fd2d`) codificado pelo ID da máquina. O PARTUUID necessário pode ser obtido usando:

    $ systemd-id128 -u --app-specific=4d21b016-b534-45c2-a9fb-5c16e091fd2d machine-id

Nota: systemd-id128(1) lê o ID da máquina de `/etc/machine-id`, isso torna impossível saber o PARTUUID necessário antes que o sistema seja instalado.

### systemd-sysvcompat

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

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 halt(8), poweroff(8), reboot(8) e shutdown(8). Cada um desses 4 comandos é um link simbólico para `systemctl`, 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 `init=` (consulte, por exemplo, [solved] /bin/init is in systemd-sysvcompat ?) e argumentos de comando do `systemctl`, 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 `/etc/tmpfiles.d/` e `/usr/lib/tmpfiles.d/` 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 `/usr/lib/tmpfiles.d/programa.conf`. Por exemplo, o daemon Samba espera que o diretório `/run/samba` exista e tenha as permissões corretas. Portanto, o pacote samba vem com esta 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 gravar valores em certos arquivos na inicialização. Por exemplo, se você usou `/etc/rc.local` para desativar a ativação de dispositivos USB com `echo USBE > /proc/acpi/wakeup`, você pode usar o seguinte arquivo tmp:

    /etc/tmpfiles.d/disable-usb-wake.conf

    #    Caminho               Modo UID  GID  Age Argumento
    w    /proc/acpi/wakeup     -    -    -    -   USBE

É possível escrever múltiplas linhas no mesmo arquivo, com `\n` no argumento ou usando o tipo `w+` em múltiplas linhas (incluindo a primeira) para acrescentar.

    /etc/tmpfiles.d/disable-usb-wake.conf

    #    Path                  Mode UID  GID  Age Argument

    w+   /proc/acpi/wakeup     -    -    -    -   USBE

    w+   /proc/acpi/wakeup     -    -    -    -   LID0

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

Nota: Este método pode não funcionar para definir opções em `/sys` uma vez que o serviço systemd-tmpfiles-setup pode ser executado antes que os módulos de dispositivo apropriados sejam carregados. Neste caso, você pode verificar se o módulo tem um parâmetro para a opção que você deseja definir com `modinfo módulo` e definir esta opção com um arquivo de configuração em /etc/modprobe.d. Caso contrário, você terá que escrever uma regra do udev para definir o atributo apropriado assim que o dispositivo aparecer.

### Arquivos de configuração drop-in

The factual accuracy of this article or section is disputed.

Reason: Esta página é sobre o PID 1 (init), e drop-ins de units já foram mencionados. Drop-in é um conceito genérico, além disso outros componentes do systemd tem suas próprias páginas dedicadas. Portanto, esta seção não parece que pertence aqui. (Discuss in Talk:systemd#YHNdnzj : Configuration files in conf.d / drop-in snippets: misplaced?)

Arquivos de configuração fornecidos por pacotes não devem ser diretamente editados para evitar conflitos com atualizações do pacman. Por conta disso, vários pacotes do systemd (mas não todos) dão uma forma de modificar a configuração sem tocar no arquivo original: pela criação de arquivos drop-in que fazem uma espécie de "recorte" (snippet) dessas definições. Verifique no manual do pacote se a configuração de arquivos drop-in é suportada.

Para criar um arquivo de configuração drop-in para o arquivo da unit `etc/systemd/unit.conf`, crie o diretório `/etc/systemd/unit.conf.d` e coloque arquivos .conf neste local para sobescrever ou adicionar novas opções. systemd irá validar e aplicar as definições desses arquivos e priorizá-los em relação à unit original.

Verifique a configuração geral:

    $ systemd-analyze cat-config systemd/unit.conf

O(s) arquivo(s) fragmentados (drop-in snippets) aplicados e o conteúdo dos mesmos serão listados no final. Reinicie o serviço para que as mudanças tenham efeito.

## Dicas e truques

### Ativação de sockets

Alguns pacotes fornecem uma unit .socket. Por exemplo, cups fornece a unit `cups.socket` [3]. Se `cups.socket` está habilitado (e `cups.service` permanece inativo), systemd não inicializará CUPS de forma imediata; apenas ficará escutando os sockets apropriados, e então, seja lá quando um programa tentar se conectar a um desses sockets do CUPS, o systemd irá iniciar `cups.service` e transferir, de forma vísivel e transparente, o controle dessas portas para o processo do CUPS.

### Ferramentas de configuração GUI

- systemadm — Navegador gráfico para as units do systemd. Ele pode mostrar a lista de units, possivelmente filtradas por tipo.

  https://cgit.freedesktop.org/systemd/systemd-ui/ || systemd-ui

- 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:

    /etc/systemd/system/foo.service

    [Unit]
    ...
    Wants=network-online.target
    After=network-online.target
    ...

O serviço de espera de rede do gerenciador de rede em uso também deve ser ativado para que `network-online.target` reflita adequadamente o status da rede.

- Se estiver usando o NetworkManager, o `NetworkManager-wait-online.service` deve ser habilitado junto com o `NetworkManager.service`. Verifque se neste caso com `systemctl is-enabled NetworkManager-wait-online.service`. Se ele não estiver habilitado, então reabilite `NetworkManager.service`.
- No caso do netctl, habilite o `netctl-wait-online.service` (a menos que esteja usando netctl-auto; veja FS#75836).
- Se estiver usando systemd-networkd, o `systemd-networkd-wait-online.service` deve ser habilitado junto com o `systemd-networkd.service`. Verifique se este é o caso com `systemctl is-enabled systemd-networkd-wait-online.service`. Se ele não estiver habilitado, então reabilite `systemd-networkd.service`.

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 `nss-lookup.target`:

    /etc/systemd/system/foo.service

    [Unit]
    ...
    Wants=network-online.target
    After=network-online.target nss-lookup.target
    ...

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

Para que `nss-lookup.target` tenha algum efeito, ele precisa de um serviço que o extraia via `Wants=nss-lookup.target` e se ordena antes dele com `Before=nss-lookup.target`. Normalmente, isso é feito por Resolvedores de DNS locais.

Verifique qual serviço ativo, se houver, está puxando `nss-lookup.target` com:

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

### 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.

Nota: Habilitar todas as units por padrão pode causar problemas com pacotes que contêm duas ou mais unidades mutuamente exclusivas. O systemctl preset é projetado para ser usado por distribuições ou administradores de sistema. No caso em que duas units conflitantes seriam habilitadas, você deve especificar explicitamente qual delas deve ser desabilitada em um arquivo de configuração predefinido, conforme especificado em systemd.preset(5).

### 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—systemd.exec(5).

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(1). 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 (capabilities(7)) que são permitidas ou negadas para uma unit. Veja systemd.exec(5) § CAPABILITIES.
  - A capacidade `CAP_SYS_ADM`, por exemplo, que deve ser um dos objetivos de um sandbox seguro: `CapabilityBoundingSet=~ CAP_SYS_ADM`

### Notificação sobre serviços com falha

Para notificar sobre falhas de serviço, uma diretiva `OnFailure=` precisa ser adicionada ao arquivo de serviço correspondente, por exemplo, usando um arquivo de configuração drop-in. A adição desta diretiva a cada unit de serviço pode ser obtido com um arquivo de configuração drop-in de nível superior. Para obter detalhes sobre drop-ins de nível superior, consulte systemd.unit(5).

Cria um drop-in de nível superior para serviços:

    /etc/systemd/system/service.d/toplevel-override.conf

    [Unit]
    OnFailure=failure-notification@%n

Isso adiciona `OnFailure=failure-notification@%n` a cada arquivo de serviço. Se some_service_unit falhar, o `failure-notification@some_service_unit` será iniciado para lidar com a entrega da notificação (ou qualquer tarefa para a qual ela esteja configurada).

Cria o modelo unit `failure-notification@`:

    /etc/systemd/system/failure-notification@.service

    [Unit]
    Description=Send a notification about a failed systemd unit
    After=network.target

    [Service]
    Type=simple
    ExecStart=/caminho/para/failure-notification.sh %i

Você pode criar o script `failure-notification.sh` e definir o que fazer ou como notificar (mail, gotify, xmpp, etc.). O `%i` será o nome da unit de serviço com falha e será passado como um argumento para o script.

Para evitar uma regressão para instâncias de `failure-notification@.service`, crie um arquivo de configuração drop-in vazio com o mesmo nome do drop-in de nível superior (o arquivo de configuração vazio drop-in de nível de serviço tem precedência sobre o drop-in de nível superior e substitui o último):

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

### Desliga automaticamente um HDD externo ao desligar

Se um HDD externo não for desligado corretamente no desligamento do sistema, pode ser desejável corrigir o problema. A maneira mais conveniente de fazer isso é usando udisks.

Habilite `udisks2.service`.

Um serviço para invocar nosso script pode ser assim:

    /etc/systemd/system/handle_external_hdds.service

    [Unit]
    Requires=udisks2.service
    Requires=graphical.target
    After=graphical.target

    [Service]
    Type=oneshot
    RemainAfterExit=yes
    ExecStop=/usr/local/bin/handle_external_hdds.sh

    [Install]
    WantedBy=graphical.target

Habilite `handle_external_hdds.service`

Faça um systemd daemon-reload para aplicar a nova configuração.

Reinicie o sistema ou reinice o `graphical.target` para verificar se funciona.

Um script de exemplo para lidar com uma quantidade arbitrária de partições em um único disco se parece com isso:

    /usr/local/bin/handle_external_hdds.sh

    #!/bin/bash -u

    declare -a uuids=(uuid_list)

    # Only proceed if the drive is present.
    if [[ ! -L "/dev/disk/by-uuid/${uuids[0]}" ]]; then
      exit 0
    fi

    for uuid in "${uuids[@]}"; do
      if findmnt "/dev/disk/by-uuid/$uuid"; then
        umount "/dev/disk/by-uuid/$uuid"
      fi
    done

    # udisksctl powers off proper drive even if its partition is supplied
    udisksctl power-off -b "/dev/disk/by-uuid/${uuids[0]}"

uuid_list é uma lista de UUIDs delimitadas por espaço correspondente às partições do dispositivo a ser verificado, por exemplo, `"uuid_1" "uuid_2"`.

## 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 demorar muito (ou parecer estar congelado), provavelmente um serviço que não foi encerrado é 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 a seção Shutdown completes eventually na documentação do systemd.

Um problema comum é um desligamento interrompido ou um processo de suspensão. Para verificar qual é o seu caso, você pode executar qualquer um desses comandos e verificar as saídas

    # systemctl poweroff

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

    # systemctl list-jobs

      JOB UNIT                    TYPE  STATE
    ...
    21593 systemd-suspend.service start running
    21592 suspend.target          start waiting
    ...

A solução para isso seria cancelar os trabalhos em execução

    # systemctl cancel
    # systemctl stop systemd-suspend.service

e, em seguida, tentar desligar ou reiniciar novamente.

### 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, executando `journalctl -b _PID=123` como root. 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

The factual accuracy of this article or section is disputed.

Reason: Os problemas do NetworkManager não são culpa do systemd, os supostos relatórios estão faltando. A lentidão do `systemctl status` ou do `journalctl` não afeta o tempo de inicialização. (Discuss in Talk:Systemd)

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 querer 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 da conexão à rede.

Para desativá-lo, mascare `emergency.service` e `emergency.target`.

## Veja também

- Wikipedia:pt:systemd
- Site oficial do systemd
  - Otimizações do systemd
  - FAQ do systemd
  - Dicas e truques do systemd
- systemd(1)
- Outras distribuições:
  - Gentoo:Systemd
  - Fedora:Systemd
  - Fedora:How to debug Systemd problems
  - Fedora:SysVinit to Systemd Cheatsheet
  - Debian:systemd
- História do blogue do Lennart, atualização 1, atualização 2, atualização 3, resumo
- Depurar Serviços Systemd
- systemd para administradores (PDF)
- Como usar o systemctl para gerenciar serviços e units do systemd
- Gerenciamento de sessão com systemd-logind
- Emacs#Syntax highlighting for systemd files
- Artigo introdutório em duas partes na revista The H Open.

Category:

- Init (Português)

Hidden category:

- Pages or sections flagged with Template:Accuracy