systemd (Português)

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 unit
1
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ção
2
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 unit
3
systemctl reenable
unit
como root
ou seja, desabilita e habilita novamente
Mascarando um unit
Mascarar
uma unit para tonar impossível o seu início
4
systemctl mask
unit
como root
Desmascarar
uma unit
systemctl unmask}
unit
como root
Veja
systemd.unit(5) § UNIT FILE LOAD PATH
para os diretórios onde os arquivos das units disponíveis podem ser encontrados.
Isso não solicita às units alteradas que recarreguem suas próprias configurações (veja
Recarregar
).
Por exemplo, no caso de sua seção
[Install]
tenha mudado desde a última vez que foi habilitada.
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
:
systemd
vai 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
target
s são implementados herdando todos os serviços de outro
target
e adicionando serviços adicionais a ele. Há
target
s 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:
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
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
[
link quebrado
: seção inválida]
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
.