Réponses:
Le 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 le persistent
stockage est activé. Si vous avez (déjà) d'énormes fichiers journaux, cela entraînera un démarrage plus lent. De plus, le disque (avec /var/log
) doit être monté dans un mode inscriptible pour ce faire.
Pour résumer: d'énormes anciens fichiers journaux, qui sont vérifiés au démarrage et l'ajout de nouvelles données de journal entraîne un temps de démarrage plus lent.
Pour vérifier le type de taille de journal journalctl
journalctl --disk-usage
Afin d'obtenir les informations de temps et d'espace disque du traitement de vidage, 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.
Désactiver le service (non recommandé)
Il est alors possible que toutes les données du journal ne soient pas écrites sur le disque; ennuyeux lors du débogage des erreurs de démarrage.
Utilisez une journalctl --vacuum
commande
De 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 Supprimer les fichiers journaux plus anciens que l'heure spécifiée
D'où 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
De man journald.conf
Stockage =
Contrôle où stocker les données du journal. Un parmi «volatile», «persistant», «auto» et «aucun».
Si elles sont " volatiles ", les données du journal de 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 elles sont " persistantes ", les données seront stockées de préférence sur 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), pendant démarrage précoce 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.
" none " désactive tout le stockage, toutes les données de journal reçues seront supprimées. Cependant, le transfert vers d'autres cibles, telles que la console, le tampon de journal du noyau ou une socket syslog, fonctionnera toujours. Par défaut, "auto".
Modifier le fichier
sudo nano /etc/systemd/journald.conf
Dans la section du journal, décommentez et modifiez:
Storage=auto
SystemMaxFileSize=1G
SystemMaxFiles=5
Enregistrez et redémarrez.
Selon cet article de la page d'accueil du développeur systemd , vous pouvez le corriger en modifiant le fichier Unit .
Pour ce faire, ouvrez /lib/systemd/system/systemd-journal-flush.service
, par exemple
sudo vim /lib/systemd/system/systemd-journal-flush.service
et changez la dépendance Before de
Before=systemd-user-sessions.service systemd-tmpfiles-setup.service
 à
 Before=systemd-tmpfiles-setup.service

Ce correctif sera automatiquement modifié pour les versions systemd>  v240.
N'oubliez pas d'enregistrer le fichier.