systemd (Português)

From ArchWiki
Revision as of 20:31, 19 June 2018 by Josephgbr (talk | contribs) (Criar target personalizada: Sync and translate)
Jump to: navigation, search

Tango-preferences-desktop-locale.pngEsse artigo ou seção precisa de tradução.Tango-preferences-desktop-locale.png

Notas: Este artigo está desatualizado, não havendo aqui algumas informações do artigo original (Discuta na Talk:Systemd (Português)#)

De página web do projeto:

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.
Nota: Para uma explicação detalhada do porquê Arch migrou para o systemd, consulte esta mensagem do fórum internacional.

Contents

Uso básico 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 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 sustema 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

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

Dica:
  • A maioria dos comandos a seguir também funciona se várias units forem especificadas; veja systemctl(1) para obter mais informações.
  • A opção --now pode ser usada em conjunto com enable, disable e mask para iniciar, parar ou mascarar, respectivamente, imediatamente a unit em vez de após na próxima inicialização.
  • 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 o systemd, procurando por units novas e modificadas:

# 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
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 a seção de exemplos comentados de systemd.service(5).

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.

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 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.
  • 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) para uma explicação mais detalhada dos valores de Type.

Editando units fornecidos

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.
  • O realce de sintaxe padrão para arquivos unit do systemd no Vim é o mesmo para arquivos INI. Porém, se você quiser algo mais específico do systemd, instale vim-systemd.

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.

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

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.

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

Modo de execução SysV systemd Target 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 estão expostas via target units. Você pode alterá-las assim:

# systemctl isolate graphical.target

Isso só vai mudar a 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

A target padrão é default.target, que tem alias por padrão para graphical.target (que corresponde ao antigo nível de execução 5).Para alterar o destino padrão na hora da inicialização, adicione um dos seguintes parâmetros kernel para o seu gerenciador de boot:

Dica: A extensão .target pode ser deixada de fora.
  • systemd.unit=multi-user.target (que corresponde ao antigo nível de execução 3),
  • systemd.unit=rescue.target (que corresponde ao antigo nível de execução 1).

Alternativamente, você pode deixar o gerenciador de boot sozinho e alterar default.target. Pode ser feito usando o systemctl:

# systemctl enable multi-user.target

O efeito desse comando é emitido pelo systemctl; um symlink para a nova target padrão é feita em /etc/systemd/system/default.target. Isso funciona se, e somente se:

[Install]
Alias=default.target

está no arquivo de configuração da target. Atualmente, multi-user.target e graphical.target ambos têm isso.

Ordem de target padrão

Systemd chooses the default.target according to the following order:

  1. Kernel parameter shown above
  2. Symlink of /etc/systemd/system/default.target
  3. Symlink of /usr/lib/systemd/system/default.target

Arquivos temporários

systemd-tmpfiles usa arquivos de configuração em /usr/lib/tmpfiles.d/ e /etc/tmpfiles.d/ para descrever a criação, limpeza e remoção de arquivos e diretórios voláteis e temporários que normalmente residem em diretórios como /run ou /tmp. Cada arquivo de configuração é chamado no estilo /etc/tmpfiles.d/program.conf. Isso também irá substituir todos os arquivos em /usr/lib/tmpfiles.d/ com o mesmo nome.

tmpfiles normalmente são fornecidos em conjunto com arquivos de serviços para criar diretórios que deverão existir por certas daemons. Por exemplo a daemon Samba espera que o diretório /run/samba exista e tenha as permissões corretas. Assim, o pacote samba vem com esta configuração:

/usr/lib/tmpfiles.d/samba.conf
D /run/samba 0755 root root

tmpfiles também pode ser usado para escrever os 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
w /proc/acpi/wakeup - - - - USBE

Consulte tmpfiles.d(5) para detalhes.

Nota: Este método pode não funcionar para definir as opções em /sys uma vez que o serviço systemd-tmpfiles-setup pode ser executado antes dos módulos de dispositivo apropriado for carregado. Neste caso, você pode verificar se o módulo tem um parâmetro para a opção que pretende definir com modinfo module e ajustar essa opção com um arquivo de configuração em /etc/modprobe.d[broken link: invalid section]. Caso contrário, você terá que escrever uma regra udev para ajustar o atributo adequado logo que o dispositivo aparecer.

Timers

A timer is a unit configuration file whose name ends with .timer and encodes information about a timer controlled and supervised by systemd, for timer-based activation. See systemd/Timers.

Note: Timers can replace cron functionality to a great extent. See systemd/Timers#As a cron replacement.

Montagem

systemd is in charge of mounting the partitions and filesystems specified in /etc/fstab. The systemd-fstab-generator(8) translates all the entries in /etc/fstab into systemd units, this is performed at boot time and whenever the configuration of the system manager is reloaded.

systemd extends the usual fstab capabilities and offers additional mount options. These affect the dependencies of the mount unit, they can for example ensure that a mount is performed only once the network is up or only once another partition is mounted. The full list of specific systemd mount options, typically prefixed with x-systemd., is detailed in systemd.mount(5).

An example of these mount options in the context of automounting, which means mounting only when the resource is required rather than automatically at boot time, is provided in fstab#Automount with systemd.

Journal

systemd tem o seu próprio sistema de registro chamado de o journal e, portanto, a execução de uma daemon syslog não é mais necessário. Para ler o registro, utilize:

# journalctl

Por padrão (quando Storage= é definido para auto em /etc/systemd/journald.conf), o journal escreve para /var/log/journal/. O diretório /var/log/journal/ faz parte do pacote systemd. Se você ou algum programa excluir esse diretório, systemd não irá recriá-lo automaticamente; no entanto, ele será recriado durante a próxima atualização do pacote systemd. Até então, os registros serão gravados em /run/systemd/journal, e os registros se perderão na reinicialização.

Dica: Se /var/log/journal/ reside em um sistema de arquivo btrfs você deve considerar a desativação Copy-on-Write do diretório:
# chattr +C /var/log/journal

Nível de prioridade

A syslog severity code (in systemd called priority) is used to mark the importance of a message RFC 5424 Section 6.2.1.

Value Severity Keyword Description Examples
0 Emergency emerg System is unusable Severe Kernel BUG, systemd dumped core.
This level should not be used by applications.
1 Alert alert Should be corrected immediately Vital subsystem goes out of work. Data loss.
kernel: BUG: unable to handle kernel paging request at ffffc90403238ffc.
2 Critical crit Critical conditions Crashes, coredumps. Like familiar flash:
systemd-coredump[25319]: Process 25310 (plugin-containe) of user 1000 dumped core
Failure in the system primary application, like X11.
3 Error err Error conditions Not severe error reported:
kernel: usb 1-3: 3:1: cannot get freq at ep 0x84,
systemd[1]: Failed unmounting /var.,
libvirtd[1720]: internal error: Failed to initialize a valid firewall backend).
4 Warning warning May indicate that an error will occur if action is not taken. A non-root file system has only 1GB free.
org.freedesktop. Notifications[1860]: (process:5999): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale.
5 Notice notice Events that are unusual, but not error conditions. systemd[1]: var.mount: Directory /var to mount over is not empty, mounting anyway. gcr-prompter[4997]: Gtk: GtkDialog mapped without a transient parent. This is discouraged.
6 Informational info Normal operational messages that require no action. lvm[585]: 7 logical volume(s) in volume group "archvg" now active.
7 Debug debug Information useful to developers for debugging the application. kdeinit5[1900]: powerdevil: Scheduling inhibition from ":1.14" "firefox" with cookie 13 and reason "screen".

If you cannot find a message on the expected priority level, also search a couple of levels above and below: these rules are recommendations, and the developer of the affected application may have a different perception of the issue's importance from yours.

Facilidade

A syslog facility code is used to specify the type of program that is logging the message RFC 5424 Section 6.2.1.

Facility code Keyword Description Info
0 kern kernel messages
1 user user-level messages
2 mail mail system Archaic POSIX still supported and sometimes used (for more mail(1))
3 daemon system daemons All daemons, including systemd and its subsystems
4 auth security/authorization messages Also watch for different facility 10
5 syslog messages generated internally by syslogd As it standartized for syslogd, not used by systemd (see facility 3)
6 lpr line printer subsystem (archaic subsystem)
7 news network news subsystem (archaic subsystem)
8 uucp UUCP subsystem (archaic subsystem)
9 clock daemon systemd-timesyncd
10 authpriv security/authorization messages Also watch for different facility 4
11 ftp FTP daemon
12 - NTP subsystem
13 - log audit
14 - log alert
15 cron scheduling daemon
16 local0 local use 0 (local0)
17 local1 local use 1 (local1)
18 local2 local use 2 (local2)
19 local3 local use 3 (local3)
20 local4 local use 4 (local4)
21 local5 local use 5 (local5)
22 local6 local use 6 (local6)
23 local7 local use 7 (local7)

So, useful facilities to watch: 0,1,3,4,9,10,15.

Filtrando saída

journalctl permite filtrar a saída por campos específicos.

Exemplos:

Mostra todas as mensagens desta inicialização:

# journalctl -b

No entanto, muitas vezes alguém está interessado em mensagens não do atual, mas do boot anterior (por exemplo, se uma falha irrecuperável do sistema aconteceu). Atualmente, este recurso não está implementado, embora foi uma discussão em systemd-devel@lists.freedesktop.org (Setembro/Outubro 2012).

Como alternativa você pode usar no momento:

# journalctl --since=today | tac | sed -n '/-- Reboot --/{n;:r;/-- Reboot --/q;p;n;b r}' | tac

desde que a inicialização anterior aconteceu hoje. Esteja ciente que, se houver muitas mensagens para o dia atual, a saída deste comando pode ser atrasada por um tempo.

Nota: Isso precisa ser corrigido uma vez que 206 regiões. journalctl -b agora assume argumentos como -0 para a última inicialização ou uma ID de inicialização. Ex. journalctl -b -3 vai mostrar todas as mensagens da quarta para a última inicialização.

Acompanhe as novas mensagens:

# journalctl -f

Mostra todas as mensagens por um executável específico:

# journalctl /usr/lib/systemd/systemd

Mostra todas as mensagens através de um processo específico:

# journalctl _PID=1

Mostra todas as mensagens de uma unit específica:

# journalctl -u netcfg

Consulte journalctl(1), systemd.journal-fields(7), ou mensagem do blog de Lennert para detalhes.

Tamanho limite do journal

Se o journal é persistente (não volátil), seu tamanho limite é definido para um valor padrão de 10% do tamanho do respectivo sistema de arquivos. Por exemplo, com o /var/log/journal localizado em uma partição root de 50 GiB isso levaria a 5 GiB de dados do journal. O tamanho máximo do journal persistente pode ser controlado pelo SystemMaxUse em /etc/systemd/journald.conf, então para limitá-lo, por exemplo, a 50 MiB descomente e edite a linha correspondente a:

SystemMaxUse=50M

Consulte journald.conf(5) para mais informações.

Limpar arquivos de journal manualmente

Journal files can be globally removed from /var/log/journal/ using e.g. rm, or can be trimmed according to various criteria using journalctl. Examples:

  • Remove archived journal files until the disk space they use falls below 100M:
    # journalctl --vacuum-size=100M
  • Make all journal files contain no data older than 2 weeks.
    # journalctl --vacuum-time=2weeks

See journalctl(1) for more info.

Journald em conjunto com o syslog

Compatibilidade com implementações do syslog clássico é fornecida através da socket /run/systemd/journal/syslog, para o qual todas as mensagens são encaminhadas. Para fazer funcionar a daemon syslog com o journal, tem de vincular a este socket em vez de /dev/log (official announcement). O pacote syslog-ng nos repositórios fornece automaticamente a configuração necessária.

# systemctl enable syslog-ng

Um bom tutorial journalctl está aqui.

Encaminhar journald para /dev/tty12

Create a drop-in directory /etc/systemd/journald.conf.d and create a fw-tty12.conf file in it:

/etc/systemd/journald.conf.d/fw-tty12.conf
[Journal]
ForwardToConsole=yes
TTYPath=/dev/tty12
MaxLevelConsole=info

Then restart systemd-journald.service.

Especificar um journal diferente para ver

There may be a need to check the logs of another system that is dead in the water, like booting from a live system to recover a production system. In such case, one can mount the disk in e.g. /mnt, and specify the journal path via -D/--directory, like so:

$ journalctl -D /mnt/var/log/journal -xe

Dicas e truques

Executando serviços após a rede estar ativa

To delay a service after the network is up, include the following dependencies in the .service file:

/etc/systemd/system/foo.service
[Unit]
...
Wants=network-online.target
After=network-online.target
...

The network wait service of the particular application that manages the network, must also be enabled so that network-online.target properly reflects the network status.

  • For the ones using NetworkManager, enable NetworkManager-wait-online.service.
  • If using systemd-networkd, systemd-networkd-wait-online.service is by default enabled automatically whenever systemd-networkd.service has been enabled; check this is the case with systemctl is-enabled systemd-networkd-wait-online.service, there is no other action needed.

For more detailed explanations see Running services after the network is up in the systemd wiki.

Habilitar units instaladas por padrão

Tango-view-fullscreen.pngThis article or section needs expansion.Tango-view-fullscreen.png

Reason: How does it work with instantiated units? (Discuss in Talk:Systemd (Português)#)

Arch Linux ships with /usr/lib/systemd/system-preset/99-default.preset containing disable *. This causes systemctl preset to disable all units by default, such that when a new package is installed, the user must manually enable the unit.

If this behavior is not desired, simply create a symlink from /etc/systemd/system-preset/99-default.preset to /dev/null in order to override the configuration file. This will cause systemctl preset to enable all units that get installed—regardless of unit type—unless specified in another file in one systemctl preset's configuration directories. User units are not affected. See systemd.preset(5) for more information.

Note: Enabling all units by default may cause problems with packages that contain two or more mutually exclusive units. systemctl preset is designed to be used by distributions and spins or system administrators. In the case where two conflicting units would be enabled, you should explicitly specify which one is to be disabled in a preset configuration file as specified in the manpage for systemd.preset.

Usando ambientes de aplicativos em sandbox

A unit file can be created as a sandbox to isolate applications and their processes within a hardened virtual environment. systemd leverages namespaces, white-/blacklisting of Capabilities, and control groups to container processes through an extensive execution environment configuration.

The enhancement of an existing systemd unit file with application sandboxing typically requires trial-and-error tests accompanied by the generous use of strace, stderr and journalctl error logging and output facilities. You may want to first search upstream documentation for already done tests to base trials on.

Some examples on how sandboxing with systemd can be deployed:

  • CapabilityBoundingSet defines a whitelisted set of allowed capabilities, but may also be used to blacklist a specific capability for a unit.
    • The CAP_SYS_ADM capability, for example, which should be one of the goals of a secure sandbox: CapabilityBoundingSet=~ CAP_SYS_ADM

Solução de problemas

Investigar erros no systemd

As an example, we will investigate an error with systemd-modules-load service:

1. Lets find the systemd services which fail to start at boot time:

$ systemctl --state=failed
systemd-modules-load.service   loaded failed failed  Load Kernel Modules

Another way is to live log systemd messages:

$ journalctl -fp err

2. Ok, we found a problem with systemd-modules-load service. We want to know more:

$ systemctl status systemd-modules-load
systemd-modules-load.service - Load Kernel Modules
   Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static)
   Active: failed (Result: exit-code) since So 2013-08-25 11:48:13 CEST; 32s ago
     Docs: man:systemd-modules-load.service(8).
           man:modules-load.d(5)
  Process: 15630 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=1/FAILURE)

If the Process ID is not listed, just restart the failed service with systemctl restart systemd-modules-load

3. Now we have the process id (PID) to investigate this error in depth. Enter the following command with the current Process ID (here: 15630):

$ journalctl _PID=15630
-- Logs begin at Sa 2013-05-25 10:31:12 CEST, end at So 2013-08-25 11:51:17 CEST. --
Aug 25 11:48:13 mypc systemd-modules-load[15630]: Failed to find module 'blacklist usblp'
Aug 25 11:48:13 mypc systemd-modules-load[15630]: Failed to find module 'install usblp /bin/false'

4. We see that some of the kernel module configs have wrong settings. Therefore we have a look at these settings in /etc/modules-load.d/:

$ ls -Al /etc/modules-load.d/
...
-rw-r--r--   1 root root    79  1. Dez 2012  blacklist.conf
-rw-r--r--   1 root root     1  2. Mär 14:30 encrypt.conf
-rw-r--r--   1 root root     3  5. Dez 2012  printing.conf
-rw-r--r--   1 root root     6 14. Jul 11:01 realtek.conf
-rw-r--r--   1 root root    65  2. Jun 23:01 virtualbox.conf
...

5. The Failed to find module 'blacklist usblp' error message might be related to a wrong setting inside of blacklist.conf. Lets deactivate it with inserting a trailing # before each option we found via step 3:

/etc/modules-load.d/blacklist.conf
# blacklist usblp
# install usblp /bin/false

6. Now, try to start systemd-modules-load:

$ systemctl start systemd-modules-load

If it was successful, this should not prompt anything. If you see any error, go back to step 3 and use the new PID for solving the errors left.

If everything is ok, you can verify that the service was started successfully with:

$ systemctl status systemd-modules-load
systemd-modules-load.service - Load Kernel Modules
   Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static)
   Active: active (exited) since So 2013-08-25 12:22:31 CEST; 34s ago
     Docs: man:systemd-modules-load.service(8)
           man:modules-load.d(5)
 Process: 19005 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=0/SUCCESS)
Aug 25 12:22:31 mypc systemd[1]: Started Load Kernel Modules.

Diagnosticar problemas de inicialização

Inicialização desses parâmetros na linha de comando do kernel: systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M

More Debugging Information

Diagnosticar um serviço

If some systemd service misbehaves or you want to get more information about what is happening, set the SYSTEMD_LOG_LEVEL environment variable to debug. For example, to run the systemd-networkd daemon in debug mode:

Add a #Drop-in files for the service adding the two lines:

[Service]
Environment=SYSTEMD_LOG_LEVEL=debug

Or equivalently, set the environment variable manually:

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

then restart systemd-networkd and watch the journal for the service with the --follow option.

Desligamento/reinicialização demora demais

Se o processo de encerramento tem um tempo muito longo (ou parece congelar) mais provavelmente um serviço que não encerra é o responsável. Systemd espera um tempo para cada serviço terminar antes de tentar matá-lo. Para descobrir se você foi afetado, consulte this article.

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.

Tempo de inicialização aumentando com o tempo

After using systemd-analyze a number of users have noticed that their boot time has increased significantly in comparison with what it used to be. After using systemd-analyze blame NetworkManager is being reported as taking an unusually large amount of time to start.

The problem for some users has been due to /var/log/journal becoming too large. This may have other impacts on performance, such as for systemctl status or journalctl. As such the solution is to remove every file within the folder (ideally making a backup of it somewhere, at least temporarily) and then setting a journal file size limit as described in #Journal size limit.

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

Starting with systemd 219, /usr/lib/tmpfiles.d/systemd.conf specifies ACL attributes for directories under /var/log/journal and, therefore, requires ACL support to be enabled for the filesystem the journal resides on.

See Access Control Lists#Enabling ACL for instructions on how to enable ACL on the filesystem that houses /var/log/journal.

A versão impressa do systemd na inicialização não é a mesma da versão do pacote instalado

You need to regenerate your initramfs and the versions should match.

Tip: A pacman hook can be used to automatically regenerate the initramfs every time systemd is upgraded. See this forum thread and Pacman#Hooks.

Desabilitar modo de emergência em máquina remota

You may want to disable emergency mode on a remote machine, for example, a virtual machine hosted at Azure or Google Cloud. It is because if emergency mode is triggered, the machine will be blocked from connecting to network.

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

Veja também