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 pode ser 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.
        
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.
        
          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.
        
          
            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.
          
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" substituem 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
          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.
        
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).
              
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).
          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.
          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.