El systemd-journal-flush.service demande au démon de journal de vider toutes les données de journal stockées dans /run/log/journal dans /var/log/journal, si persistent le stockage est activé. Si vous avez (déjà) d'énormes fichiers journaux, cela entraînera un démarrage plus lent. En outre, le disque (avec /var/log ) doit être monté dans un mode d'écriture pour le faire.

Pour résumer, les anciens fichiers journaux volumineux, qui sont vérifiés lors du démarrage, et l'ajout de nouvelles données de journal entraînent un ralentissement du démarrage.

Pour vérifier la taille du journal journalctl, tapez

journalctl --disk-usage

Afin d'obtenir les informations sur le temps et l'espace disque du traitement de la chasse d'eau, entrez la commande suivante

journalctl -b --unit systemd-journald

La sortie correspondante ressemblera à

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

Vous pouvez soit

• Désactiver le service (non recommandé)

Il est alors possible que toutes les données du journal ne soient pas écrites sur le disque, ce qui est gênant pour le débogage des défauts de démarrage. Journald est un service fondamental dans systemd linux et de nombreux autres services en dépendent.

• Vérifier la cohérence interne du fichier journal :

   journalctl --verify

Veillez à ce que chaque journal apparaisse PASSER .

• Utilisez un journalctl --vacuum commande

Desde journalctl -h

--vacuum-size=BYTES Réduire l'utilisation du disque en dessous de la taille spécifiée
--vacuum-files=INT Ne laisser que le nombre spécifié de fichiers journaux
--vacuum-time=TIME Supprime les fichiers journaux plus anciens que le temps spécifié

Faites donc un

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

• Modifier le type de stockage de systemd-journal-flush.service

Vérifiez d'abord votre type de stockage avec

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

Desde man journald.conf

Stockage=

Contrôle l'endroit où sont stockées les données du journal. Parmi "volatile", "persistant", "auto" et "aucun".

Si " volatile ", les données du journal seront stockées uniquement en mémoire, c'est-à-dire en dessous de la hiérarchie /run/log/journal (qui est créée si nécessaire).

Si " persistant ", les données seront stockées de préférence sur le disque, c'est-à-dire en dessous de la hiérarchie /var/log/journal (qui est créée si nécessaire), avec un repli sur /run/log/journal (qui est créé si nécessaire), lors du démarrage anticipé et si le disque n'est pas accessible en écriture.

" auto "est similaire à "persistant" mais le répertoire /var/log/journal n'est pas créé si nécessaire, de sorte que son existence contrôle où vont les données du journal.

" aucun "Désactive tout le stockage, toutes les données de journal reçues seront abandonnées. Le transfert vers d'autres cibles, telles que la console, le tampon de journalisation du noyau ou une socket syslog, fonctionnera néanmoins. ou une socket syslog fonctionnera toujours. La valeur par défaut est "auto".

Modifier le fichier

    sudo nano /etc/systemd/journald.conf

Dans la section journal, décommentez et modifiez :

    Storage=auto
    SystemMaxFileSize=1G
    SystemMaxFiles=5

Recommandation

Je recommande de limiter la taille de la SystemMaxFileSize à 20MB -->

    SystemMaxFileSize=50M

Enfin, dans le cas où votre Ubuntu ne tourne pas sur un serveur important, je vous suggère de changer le stockage des données en volatile :

    Storage=volatile

Si vous exécutez le démarrage en mode débogage et que vous suivez les appels système (strace), vous découvrirez peut-être que l'écriture en flush a des performances d'entrée/sortie très faibles. Dans mon cas, la raison n'était pas claire. Peut-être que certains messages du noyau spamment le fichier journal (notez qu'après 10000 messages l'unité est bloquée par défaut, mais journald doit gérer cela, ce qui peut être la cause de la mauvaise performance). Dans ce cas, passez en revue les messages et recherchez les erreurs, qui n'ont pas nécessairement été marquées comme telles.

    journalctl -b --output short-monotonic

et

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

El --output short-monotonic imprime les pas de temps en contraste avec l'heure utc par défaut.

Enfin, supprimez les anciens fichiers journaux en

    sudo rm -rf /var/log/journal

Sauvegarder et redémarrer.