9.10. Uso e Configuração do Systemd

9.10.1. Configuração Básica

O arquivo /etc/systemd/system.conf contém um conjunto de opções para controlar as operações básicas do systemd. O arquivo padrão tem todas as entradas comentadas com as configurações padrão indicadas. Esse arquivo é onde o nível de registro possivelmente seja mudado, bem como algumas configurações básicas de registro. Veja-se a página de manual systemd-system.conf(5) para detalhes a respeito de cada opção de configuração.

9.10.2. Desabilitando a Limpeza da Tela em Tempo de Inicialização

O comportamento normal para o systemd é o de limpar a tela ao final da sequência de inicialização. Se desejado, esse comportamento possivelmente seja mudado executando o seguinte comando:

mkdir -pv /etc/systemd/system/getty@tty1.service.d

cat > /etc/systemd/system/getty@tty1.service.d/noclear.conf << EOF
[Service]
TTYVTDisallocate=no
EOF

As mensagens de inicialização sempre podem ser revistas usando-se o comando journalctl -b como o(a) usuário(a) root.

9.10.3. Desabilitando tmpfs para /tmp

Por padrão, /tmp é criado como um tmpfs. Se isso não for desejado, [então] ele pode ser sobreposto executando-se o seguinte comando:

ln -sfv /dev/null /etc/systemd/system/tmp.mount

Alternativamente, se uma partição separada para /tmp for desejada, [então] especifique essa partição em uma entrada do /etc/fstab.

[Atenção]

Atenção

Não crie o link simbólico acima se uma partição separada for usada para o /tmp. Isso impedirá o sistema de arquivos raiz (/) de ser remontado leitura/escrita e tornará o sistema inutilizável quando inicializado.

9.10.4. Configurando a Criação e Deleção Automática de Arquivo

Existem vários serviços que criam ou deletam arquivos ou diretórios:

  • systemd-tmpfiles-clean.service

  • systemd-tmpfiles-setup-dev.service

  • systemd-tmpfiles-setup.service

O local de sistema para os arquivos de configuração é /usr/lib/tmpfiles.d/*.conf. Os arquivos locais de configuração estão em /etc/tmpfiles.d. Os arquivos em /etc/tmpfiles.d sobrepõem os arquivos com o mesmo nome em /usr/lib/tmpfiles.d. Veja-se a página de manual tmpfiles.d(5) para detalhes do formato do arquivo.

Observe que a sintaxe para os arquivos /usr/lib/tmpfiles.d/*.conf pode ser confusa. Por exemplo, a deleção padrão de arquivos no diretório /tmp está localizada em /usr/lib/tmpfiles.d/tmp.conf com a linha:

q /tmp 1777 root root 10d

O campo tipo, q, discute criar um sub-volume com cotas, o qual realmente é aplicável somente para sistemas de arquivos btrfs. Ele referencia tipo v, o qual sequencialmente referencia tipo d (diretório). Isso então cria o diretório especificado se ele não estiver presente e ajusta as permissões e propriedade como especificado. O conteúdo do diretório estará sujeito a limpeza baseada em hora se o argumento idade for especificado.

Se os parâmetros padrão não forem desejados, então o arquivo deveria ser copiado para /etc/tmpfiles.d e editado conforme desejado. Por exemplo:

mkdir -p /etc/tmpfiles.d
cp /usr/lib/tmpfiles.d/tmp.conf /etc/tmpfiles.d

9.10.5. Sobrepondo o Comportamento Padrão de Serviços

Os parâmetros de uma unidade podem ser sobrepostos criando-se um diretório e um arquivo de configuração em /etc/systemd/system. Por exemplo:

mkdir -pv /etc/systemd/system/foobar.service.d

cat > /etc/systemd/system/foobar.service.d/foobar.conf << EOF
[Service]
Restart=always
RestartSec=30
EOF

Veja-se a página de manual systemd.unit(5) para mais informação. Depois de criar o arquivo de configuração, execute systemctl daemon-reload e systemctl restart foobar para ativar as mudanças para um serviço.

9.10.6. Depurando a Sequência de Inicialização

Em vez de scripts planos de shell usados nos sistemas de inicialização estilo SysVinit ou BSD, o systemd usa um formato unificado para tipos diferentes dos arquivos de inicialização (ou unidades). O comando systemctl é usado para habilitar; desabilitar; controlar estado; e obter a situação dos arquivos de unidade. Aqui estão alguns exemplos dos comandos frequentemente usados:

  • systemctl list-units -t <serviço> [--all]: lista os arquivos carregados de unidade do tipo serviço.

  • systemctl list-units -t <alvo> [--all]: lista os arquivos carregados de unidade do tipo alvo.

  • systemctl show -p Wants <multi-user.target>: mostra todas as unidades que dependem do alvo multi-user. Alvos são arquivos especiais de unidade que são análogos a níveis de execução sob o SysVinit.

  • systemctl status <nome_serviço.service>: mostra a situação do serviço nome_serviço. A extensão .service pode ser omitida se não existirem outros arquivos de unidade com o mesmo nome, tais como arquivos .socket (os quais criam um soquete de escuta que fornece funcionalidade similar ao inetd/xinetd).

9.10.7. Trabalhando com o Diário do Systemd

O registro em um sistema inicializado com o systemd é manuseado com o systemd-journald (por padrão), em vez de um processo de segundo plano típico do Unix syslog. Você também pode adicionar um processo de segundo plano normal syslog e ter ambos operando lado a lado se desejado. O aplicativo systemd-journald armazena entradas de diário em um formato binário, em vez de um arquivo plano de registro de texto. Para auxiliar na análise do arquivo, o comando journalctl é fornecido. Aqui estão alguns exemplos dos comandos frequentemente usados:

  • journalctl -r: mostra todo o conteúdo do diário em ordem cronológica reversa.

  • journalctl -u UNIDADE: mostra as entradas de diário associadas com o arquivo especificado de UNIDADE.

  • journalctl -b[=ID] -r: mostra as entradas de diário desde a mais recente inicialização bem sucedida (ou para a ID de inicialização) em ordem cronológica reversa.

  • journalctl -f: fornece funcionalidade similar ao tail -f (seguir).

9.10.8. Trabalhando com Despejos de Núcleo

Despejos de núcleo são úteis para depurar aplicativos quebrados, especialmente quando um processo de aplicativo de segundo plano quebra. Em sistemas inicializados do systemd, o despejamento de núcleo é manuseado pelo systemd-coredump. Ele registrará o despejo de núcleo no diário e armazenará o próprio despejo de núcleo em /var/lib/systemd/coredump. Para recuperar e processar despejos de núcleo, a ferramenta coredumpctl é fornecida. Aqui estão alguns exemplos de comandos frequentemente usados:

  • coredumpctl -r: lista todos os despejos de núcleo em ordem cronológica reversa.

  • coredumpctl -1 info: mostra a informação a partir do mais recente despejo de núcleo.

  • coredumpctl -1 debug: carrega o mais recente despejo de núcleo no GDB.

Despejos de núcleo possivelmente usem um monte de espaço em disco. O espaço máximo em disco usado por despejos de núcleo pode ser limitado criando-se um arquivo de configuração em /etc/systemd/coredump.conf.d. Por exemplo:

mkdir -pv /etc/systemd/coredump.conf.d

cat > /etc/systemd/coredump.conf.d/maxuse.conf << EOF
[Coredump]
MaxUse=5G
EOF

Vejam-se as páginas de manual systemd-coredump(8); coredumpctl(1); e coredump.conf.d(5) para mais informação.

9.10.9. Processos de Execução Longa

Iniciando com o systemd-230, todos os processos de usuário(a) são finalizados quando uma sessão de usuário(a) for terminada, mesmo se nohup for usado ou o processo usar as funções daemon() ou setsid(). Isso é uma mudança deliberada de um ambiente historicamente permissivo para um mais restritivo. O novo comportamento possivelmente cause problemas se você depender de aplicativos de execução longa (por exemplo, screen ou tmux) para continuarem ativos depois de terminar sua sessão de usuário(a). Existem três maneiras de habilitar processos persistentes para continuarem depois que uma sessão de usuário(a) for terminada.

  • Habilitar persistência de processo somente para usuários(as) selecionados(as): Usuários(as) normais tem permissão para habilitar persistência de processo com o comando loginctl enable-linger para os(as) próprios(as) usuários(as) deles(as). Administradores(as) do sistema podem usar o mesmo comando com um argumento user ao habilitar para um(a) usuário(a). Esse(a) usuário(a) consegue então usar o comando systemd-run para iniciar processos de execução longa. Por exemplo: systemd-run --scope --user /usr/bin/screen. Se você habilitar a persistência para seu(ua) usuário(a), [então] a user@.service continuará, mesmo depois que todas as sessões de login forem fechadas e automaticamente iniciará na inicialização do sistema. Isso tem a vantagem de explicitamente permitir e proibir processos para execução depois que a sessão de usuário(a) tenha terminado, porém quebra retrocompatibilidade com ferramentas como nohup e utilitários que usam daemon().

  • Habilitar persistência de processo abrangente ao sistema: Você pode configurar KillUserProcesses=no em /etc/systemd/logind.conf para habilitar a persistência de processo globalmente para todos(as) os(as) usuários(as). Isso tem o benefício de deixar o método antigo disponível para todos(as) os(as) usuários(as) à custa do controle explícito.

  • Desabilitar em tempo de construção: Você pode desabilitar a persistência por padrão enquanto construir o systemd adicionando a chave -Ddefault-kill-user-processes=false ao comando meson para o systemd. Isso desabilita completamente a habilidade do systemd para finalizar processos de usuário(a) ao fim da sessão.