O systemd-journal-flush.servicesolicita ao daemon do diário que descarregue todos os dados de log armazenados em /run/log/journal em /var/log/journal, se persistento armazenamento estiver ativado. Caso você já tenha (já) arquivos de log enormes, isso resultará em uma inicialização mais lenta. Além disso, o disco (com /var/log) deve ser montado em um modo gravável para fazer isso.

Para resumir: enormes arquivos de log antigos, que são verificados durante a inicialização e o acréscimo de novos dados de log resulta em um tempo de inicialização mais lento.

Para verificar o tipo de tamanho do log journalctl

journalctl --disk-usage

Para obter as informações de tempo e espaço em disco do processamento de liberação, digite o seguinte comando

journalctl -b --unit systemd-journald

A saída correspondente será semelhante a

-- Logs begin at Sat 2018-12-08 00:40:23 CET, end at Mon 2018-12-10 19:40:27 CET. --
Dec 10 12:51:38 ubuntu01 systemd-journald[479]: Journal started
Dec 10 12:51:38 ubuntu01 systemd-journald[479]: Runtime journal (/run/log/journal/265c93c062bf4c8da41abfe2ae793452) is 4.7M, max 38.3M, 33.5M free.
Dec 10 12:51:38 ubuntu01 systemd-journald[479]: Time spent on flushing to /var is 7.066904s for 132 entries.
Dec 10 12:51:38 ubuntu01 systemd-journald[479]: System journal (/var/log/journal/265c93c062bf4c8da41abfe2ae793452) is 128.0M, max 256.0M, 128M free.

Você também pode

• Desative o serviço (não recomendado)

Então é possível que nem todos os dados de log sejam gravados no disco; irritante ao depurar falhas de inicialização. O Journald é um serviço fundamental no systemd linux e muitos outros serviços dependem dele.

• Verifique o arquivo de diário quanto à consistência interna:

   journalctl --verify
  

Observe que todos os diários mostram PASS .

• Usar um journalctl --vacuumcomando

A partir dejournalctl -h

--vacuum-size=BYTES Reduz o uso do disco abaixo do tamanho especificado
--vacuum-files=INT Deixa apenas o número especificado de arquivos de diário
--vacuum-time=TIME Remove arquivos de diário anteriores ao tempo especificado

Daí faça um

    sudo journalctl --vacuum-size=1G --vacuum-time=5d --vacuum-files=5

• Alterar o tipo de armazenamento desystemd-journal-flush.service

Primeiro, verifique seu tipo de armazenamento com

     systemctl cat systemd-journal-flush.service  | grep -i storage

A partir deman journald.conf

Armazenamento=

Controla onde armazenar os dados do diário. Um de "volátil", "persistente", "automático" e "nenhum".

Se for " volátil ", os dados de log do diário serão armazenados apenas na memória, ou seja, abaixo da hierarquia /run/log/journal (que é criada se necessário).

Se " persistente ", os dados serão armazenados preferencialmente em disco, ou seja, abaixo da hierarquia /var/log/journal (que é criada se necessário), com um fallback para /run/log/journal (que é criado se necessário), durante inicialização antecipada e se o disco não for gravável.

" auto " é semelhante a "persistente", mas o diretório /var/log/journal não é criado se necessário, de modo que sua existência controla para onde vão os dados de log.

" nenhum " desliga todo o armazenamento, todos os dados de log recebidos serão descartados. No entanto, o encaminhamento para outros destinos, como o console, o buffer de log do kernel ou um soquete syslog, ainda funcionará. O padrão é "automático".

Edite o arquivo

    sudo nano /etc/systemd/journald.conf

Na seção do diário, descomente e altere:

    Storage=auto
    SystemMaxFileSize=1G
    SystemMaxFiles=5

Recomendação

Eu recomendo limitar o tamanho da chave SystemMaxFileSize a 20 MB -->

    SystemMaxFileSize=50M

Por fim, caso seu Ubuntu não esteja rodando em um servidor importante, sugiro alterar o armazenamento de dados para volátil:

    Storage=volatile

Se você executar a inicialização no modo de depuração e rastrear as chamadas do sistema (strace), poderá descobrir que a gravação de descarga tem um desempenho de i/o muito ruim. No meu caso, não ficou claro o porquê. Talvez algumas mensagens do kernel enviem spam para o arquivo de log (observe que, após 10.000 mensagens, a unidade é bloqueada por padrão, mas o journald precisa gerenciar isso, o que pode causar um desempenho ruim). Nesse caso, percorra as mensagens e procure por erros, que não foram necessariamente marcados como erros.

    journalctl -b --output short-monotonic

e

    journalctl -b -p 1..4 --output short-monotonic

O --output short-monotonicsinalizador imprime as etapas de tempo em contraste com o horário utc padrão.

Por fim, remova os arquivos de log antigos

    sudo rm -rf /var/log/journal

Salve e reinicie.

De acordo com esta postagem da página inicial do desenvolvedor do systemd , você pode corrigi-lo alterando o arquivo Unit .

Para fazer isso, abra /lib/systemd/system/systemd-journal-flush.service, por exemplo

sudo vim /lib/systemd/system/systemd-journal-flush.service

e altere a dependência Before de

 Before=systemd-user-sessions.service systemd-tmpfiles-setup.service

para

 Before=systemd-tmpfiles-setup.service

Esta correção será alterada automaticamente para versões systemd > v240.

Não se esqueça de salvar o arquivo.