La détermination des problèmes peut être autant un art qu'une science, et parfois, il semble même qu'un peu de magie puisse être utile. Tout le monde a rencontré des situations où une panne signalée ne pouvait pas être reproduite, ce qui est toujours frustrant pour l'utilisateur et l'administrateur système. Même les appareils électroménagers et les automobiles peuvent être obstinés et refuser de tomber en panne lorsque le technicien de service se présente.
Mis à part l'anthropomorphisme, les administrateurs système disposent d'outils capables de montrer ce qui s'est passé sur leurs ordinateurs Linux avec différents degrés de granularité. Il existe des outils, comme top, htop, regards, sar, iotop, tcpdump, traceroute, mtr, iptraf-ng, df, du, et bien d'autres, qui peuvent tous afficher l'état actuel d'un hôte, et dont plusieurs peuvent produire des journaux de différents niveaux de détail.
Bien que ces outils puissent être utilisés pour trouver des problèmes en cours, ils ne sont pas particulièrement utiles pour les problèmes transitoires ou ceux qui ne présentent aucun symptôme directement observable - pas observable, du moins, jusqu'à ce qu'un problème majeur et éventuellement catastrophique se produise.
Un outil important que j'utilise pour la détermination des problèmes est les journaux système - et avec systemd, les journaux système. Le journal systemd est toujours l'un des premiers outils vers lesquels je me tourne pour résoudre un problème, en particulier les problèmes qui ne semblent pas se produire lorsque je regarde. Il m'a fallu beaucoup de temps au début de ma carrière d'administrateur système pour réaliser la richesse des informations contenues dans les fichiers journaux, et cette découverte a grandement amélioré ma rapidité à résoudre les problèmes.
Vous avez déjà vu quelques utilisations du journalctl commande dans de nombreux articles précédents de cette série. Dans cet article, j'explorerai quelques détails sur le journal systemd, son fonctionnement et les façons d'utiliser journalctl pour localiser et identifier les problèmes.
À propos des revues
Le but de tout journal ou journal est de conserver un historique chronologique des activités normales des services et des programmes qui s'exécutent sur un hôte et d'enregistrer les erreurs ou les messages d'avertissement qui se produisent. Les messages du journal étaient conservés dans des fichiers séparés dans /var/log , généralement un fichier pour le noyau et des fichiers séparés pour la plupart des services exécutés sur l'hôte. Malheureusement, le grand nombre de fichiers journaux peut diffuser les informations nécessaires et retarder la découverte de la cause première d'un problème. Cela peut prendre beaucoup de temps lorsque vous essayez de déterminer ce qui se passait dans un système lorsqu'une erreur s'est produite.
L'ancien /var/log/dmesg était généralement utilisé pour le noyau, mais ce fichier a été abandonné il y a plusieurs années au profit de l'utilisation de dmesg commande pour afficher les mêmes informations et intégrer ces messages (et plus) dans le /var/log/messages dossier. Cette fusion d'autres journaux dans les messages aidait à accélérer la détermination des problèmes en conservant une grande partie des données dans un seul fichier, mais il y avait encore de nombreux services dont les journaux n'étaient pas intégrés dans les messages plus centraux fichier.
Le journal systemd est conçu pour collecter tous les messages dans une structure unique et unifiée qui peut montrer une image complète de tout ce qui s'est passé dans un système à et autour d'un moment ou d'un événement spécifique. Étant donné que les événements, quelle que soit leur source, se déroulent en un seul endroit et dans une séquence temporelle, il est possible de voir d'un coup d'œil tout ce qui se passe à un moment ou à une plage de temps spécifique. À mon avis, c'est l'un des principaux avantages de la journalisation systemd.
À propos du journal systemd
Le service de journalisation systemd est implémenté par le systemd-journald démon. Selon le systemd-journald page de manuel :
systemd-journaldest un service système qui collecte et stocke les données de journalisation. Il crée et maintient des journaux structurés et indexés basés sur les informations de journalisation reçues de diverses sources :
- Messages du journal du noyau, via
kmsg- Des messages de journal système simples, via la
libc syslog(3)appeler- Messages de journal système structurés via l'API Journal native, voir
sd_journal_print(3)- Sortie standard et erreur standard des unités de service. Pour plus de détails, voir ci-dessous.
- Enregistrements d'audit, provenant du sous-système d'audit du noyau
Le démon collectera implicitement de nombreux champs de métadonnées pour chaque message de journal de manière sécurisée et infalsifiable. Voir
systemd.journal-fields(7)pour plus d'informations sur les métadonnées collectées.Les données de journal collectées par le journal sont principalement basées sur du texte, mais peuvent également inclure des données binaires si nécessaire. Les champs individuels constituant un enregistrement de journal stocké dans le journal peuvent avoir une taille maximale de 2^64-1 octets.
Modifications de configuration
Plus de ressources Linux
- Aide-mémoire des commandes Linux
- Aide-mémoire des commandes Linux avancées
- Cours en ligne gratuit :Présentation technique de RHEL
- Aide-mémoire sur le réseau Linux
- Aide-mémoire SELinux
- Aide-mémoire sur les commandes courantes de Linux
- Que sont les conteneurs Linux ?
- Nos derniers articles Linux
Le démon de journal systemd peut être configuré à l'aide de /etc/systemd/journald.conf dossier. Pour de nombreux hôtes, ce fichier ne nécessite aucune modification car les valeurs par défaut sont tout à fait raisonnables. Regardez votre journald.conf déposer maintenant, si vous ne l'avez pas déjà fait.
Les modifications de configuration les plus courantes que vous pourriez envisager de spécifier la taille maximale du fichier journal, le nombre de fichiers journaux plus anciens et les durées maximales de conservation des fichiers. La principale raison d'apporter ces modifications serait de réduire l'espace de stockage utilisé par le journal si vous disposez d'un petit périphérique de stockage. Dans un environnement critique, vous souhaiterez peut-être également réduire le délai entre la synchronisation des données de journal stockées dans la mémoire RAM et le périphérique de stockage.
Le journald.conf la page de manuel contient plus de détails.
Controverses sur le format des données
L'une des controverses entourant systemd est le format binaire dans lequel le contenu du journal est stocké. Certains arguments contre systemd sont basés sur le fait que le journal systemd est stocké dans un format binaire. Cela semblerait contraire à la philosophie Unix/Linux d'utiliser le texte ASCII pour les données, qui est un argument que les gens utilisent pour justifier leur aversion pour systemd. Par exemple, Doug McIlroy, l'inventeur des tuyaux, a déclaré :
"C'est la philosophie d'Unix :écrivez des programmes qui font bien une chose. Écrivez des programmes pour qu'ils fonctionnent ensemble. Écrivez des programmes pour gérer les flux de texte, car il s'agit d'une interface universelle." —Doug McIlroy, cité dans le livre d'Eric S. Raymond The Art of Unix Programming
Cependant, ces arguments semblent être basés sur au moins une idée fausse partielle car la page de manuel indique clairement que les données "sont principalement basées sur du texte", bien qu'elle autorise les formes de données binaires. Le créateur du noyau Linux, Linus Torvalds, qui est toujours clair sur ses sentiments, a déclaré :
"Je n'ai pas vraiment d'opinions particulièrement fortes sur systemd lui-même. J'ai eu des problèmes avec certains des principaux développeurs qui, à mon avis, sont beaucoup trop cavaliers sur les bogues et la compatibilité, et je pense que certains détails de conception sont insensés (je n'aiment pas les journaux binaires, par exemple), mais ce sont des détails, pas de gros problèmes." —Linus Torvalds, cité dans "Linus Torvalds and other on Linux's systemd" de ZDNet en 2014
Les fichiers journaux systemd sont stockés dans un ou plusieurs sous-répertoires de /var/log/journal . Connectez-vous à un système de test où vous avez un accès root et créez /var/log/journal le répertoire de travail actuel (PWD). Listez les sous-répertoires, choisissez-en un et faites-en le PWD. Vous pouvez consulter ces fichiers de plusieurs manières. J'ai commencé avec la stat commande (notez que les noms des fichiers journaux sur votre hôte seront différents des miens) :
[root @ testvm1 3bccd1140fca488187f8a1439c832f07] # stat system@7ed846aadf1743139083681ec4042037-0000000000000001-0005a99c0280fd5f.journal
Fichier:system@7ed846aadf1743139083681ec4042037-0000000000000001-0005a99c0280fd5f.journal
Taille:8.388.608 blocs:16392 IO Bloc:4096 régulier fichier
Appareil :fd04h/64772d Inode :524384 Liens :1
Accès :(0640/-rw-r-----) Uid :( 0/ root) Gid :( 190/systemd-journal ). 33:52.916001110 -0400
Naissance :-
[root@testvm1 3bccd1140fca488187f8a1439c832f07]#
Le fichier journal est identifié comme un fichier "normal", ce qui n'est pas particulièrement utile. Le fichier la commande l'identifie comme un fichier "journal", mais vous le savez déjà. Regardez à l'intérieur du fichier avec le dd commande. La commande suivante envoie le flux de données de sortie à STDOUT ; vous voudrez peut-être le diriger à travers le less téléavertisseur :
[root@testvm1 3bccd1140fca488187f8a1439c832f07]# dd if=system@7ed846aadf1743139083681ec4042037-0000000000000001-0005a99c0280fd5f.journal | less
9�P1�8��9_SOURCE_MONOTONIC_TIMESTAMP=191726���/��P����9MESSAGE=Entrées de table de hachage d'inode-cache :1048576 (ordre :11 8388608 octets , linéaire)�hx
9�P1�p�9��/��P�b������9��9_SOURCE_MONOTONIC_TIMESTAMP=191825�pdXY�7p�9��9MESSAGE=mem auto-init :stack:off, heap alloc:off, heap free:off�i��
��(n�O���@Y� �����Zս���82���7X�8 �������8��DZR������8<~B�4�<� �8tM˞8$����8��Ö��h9�&������9 �����`@�9�pdXY�7b�ͺ��WV��9��9_SOURCE_MONOTONIC_TIM
ESTAMP=234745����4�h@�9��9MESSAGE=Mémoire :12598028K/12963384K disponible (code noyau 14339K, 2406K rwdata, 8164K rodata, 2468K init, 5072K b
ss, 365356K réservé, 0K cma-réservé)�j����(n�O���@Y� ��� �]��m�82���7X�8�������8��DZR�����8<~B�4�<� �8tM˞8$����8�� Ö��h9�&������9�ͺ��WV��9���
4�hbB���a��^��9��9_SOURCE_MONOTONIC_TIMESTAMP=234758��3�� ���9��9MESSAGE=aléatoire :get_random_u64 appelé depuis __kmem_cache_create+0x3e/0x610 avec
ème crng_init=0�k���(n�O���@Y� ����j��� ���82���7X��8C�X�Y"��8��������8��DZR�����8<~B�4�<� �8tM˞8$� ���8� �Ö�à�9B���a���9�3���b�8�ȭ�����9h�9_SO�9h�9MESSAGE=SLUB :HWalign=64, Order=0-3, MinObjects =0, UC=4, nœuds=1�l����(n�O���@Y� ������z��X�82���7X�8������ �8��DZR�����8<~B�4�<� �8tM˞
b�(+I)�x�9�9_SOURCE_MONOTONIC_TIMESTAMP=235444r�%/p��9�9MESSAGE =Isolation des tables de pages noyau/utilisateur :activée�m����(n�O���@Y� ����k��B0��8
2���7X�8��� ����8��DZR�����8<~B�4�<� �8tM˞8$����8��Ö��h9�&����8�9�(+ I)Ҡ�9� %/pb8O{ W���8�9��9_SOURCE_MONOTONIC_TIMESTAMP=235464u�N`�FP M��9
��9MESSAGE=ftrace :attribution de 41361 entrées sur 162 pages�n ����(n�O���@Y�
Même cette petite partie du flux de données du dd La commande montre un mélange intéressant de texte ASCII et de données binaires. Un autre outil utile est les strings commande, qui affiche simplement toutes les chaînes de texte ASCII contenues dans un fichier et ignore les données binaires :
[rootv @ testvm1 3bccd1140fca488187f8a1439c832f07] # Système Strings@7ed846AADF174313908368143139083681431390fd5A99C0280FD5F.JOURNAL
Message =Linux version 5.7.6-201.fc32.x86_64 ([email protected] .fedoraproject.org) (gcc version 10.1.1 20200507 (Red Hat 10.1.1-1) (GC
C), GNU ld version 2.34-3.fc32) #1 SMP Lundi 29 juin 15:15:52 UTC 2020
MESSAGE
_BOOT_ID=6e944f99ebd9405984090f829a927fa4
_BOOT_ID
_MACHINE_ID=3bccd1140fca488187f8a1439c832f07
_MACHINE_ID
_HOSTNAME=thtestvm1.bo
_HOSTNAME=thtestvm1.bo>PRIORITY=6
MESSAGE=Ligne de commande :BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.7.6-201.fc32.x86_64 root=/dev/mapper/VG01-root ro resume=/dev/mapper/ VG01-swap rd.lv
m.lv=VG01/root rd.lvm.lv=VG01/swap rd.lvm.lv=VG01/usr selinux=0
MESSAGE=x86/fpu :Prise en charge de XSAVE fonctionnalité 0x001 :'x87 registres à virgule flottante'
MESSAGE=x86/fpu :prise en charge de la fonctionnalité XSAVE 0x002 :'registres SSE'
MESSAGE=x86/fpu :prise en charge de la fonctionnalité XSAVE 0x00 4 :'AVX registers'
Z_g3 ;
MESSAGE=x86/fpu :xstate_offset[2] : 576, xstate_sizes[2] : 256
Z_g3 ;
MESSAGE=x86/fpu :Fonctionnalités xstate activées 0x7, la taille du contexte est de 832 octets, en utilisant le format "standard".
MESSAGE=Carte RAM physique fournie par le BIOS :
`k2X
MESSAGE=BIOS-e820 :[mem 0x0000000000000000 -0x000000000009fbff] utilisable
Message =BIOS-E820:[MEM 0x00000000000009FC00-0X0000000000000FFFFFF]PYLM
Message =BIOS -e820:[MEM 0x0000000000100000-0X00000000FFFFFFF] Usable
Message =BIOS-E820:[MEM 0x00000000DFFF0000-0X00000000FFFFFF] ACPI Data
Message =BIOS-E820:[MEM 0x000000Fec00000-0x00000000Fec00fff] Réservé
Message BIOS-E820:[MEM 0x00000000FEE00000-0X00000000FEE00FFF] Réservé
Message =BIOS-E820:[MEM 0x000000FFC0000-0X00000000FFFFFFFFFFR) Réservé
Message =BIOS-E820:[MEM 0x0000000100000000-0X00000003373FFFFF] Utilisable
Ces données peuvent être interprétées par des humains, et ce segment particulier ressemble beaucoup au flux de données de sortie du dmesg commande. Je vous laisse explorer davantage par vous-même, mais ma conclusion est que les fichiers journaux sont clairement un mélange de texte binaire et ASCII. Cette combinaison complique l'utilisation d'outils Linux traditionnels basés sur du texte pour extraire des données utilisables. Mais il existe un meilleur moyen qui offre de nombreuses possibilités pour extraire et afficher les données du journal.
À propos de journalctl
Le journalctl La commande est conçue pour extraire des informations utilisables des journaux systemd en utilisant des critères puissants et flexibles pour identifier les données souhaitées. Les articles précédents de cette série ont décrit journalctl , et il y a plus à savoir.
Je vais d'abord revoir un peu et commencer par quelques notions de base au cas où vous n'auriez pas lu les articles précédents ou au cas où vous auriez simplement besoin d'un rappel.
Vous pouvez utiliser le journalctl commande sans options ni arguments pour afficher le journal systemd contenant toutes les informations de journal et de journal :
[root@testvm1 ~]# journalctl
-- Les journaux commencent le lun 2020-06-08 07:47:20 EDT, se terminent le jeu 2020-07-16 10:30:43 EDT. --
Juin 08 07:47:20 noyau testvm1.both.org :Linux version 5.6.6-300.fc32.x86_64 ([email protected]) (gcc version 10.0>
Juin 08 07:47:20 noyau testvm1.both.org :Ligne de commande :BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.6.6-300.fc32.x86_64 root=/dev/mapper/VG01-root ro>
JUN 08 08 07:47:20 Testvm1.both.org Kernel:X86 / FPU:Support XSave Feature 0x001:'X87 Registres à point flottant'
08 07 07:47:20 Testvm1.both.org Kernel:x86/fpu :prise en charge de la fonctionnalité XSAVE 0x002 : 10 juin 08 07:47:20 Noyau testvm1.both.org :x86/fpu :prise en charge de la fonctionnalité XSAVE 0x004 : ‹ registres AVX ’
juin 08 07:47:20 noyau testvm1.both.org :x86/fpu :xstate_offset[2] : 576, xstate_sizes[2] : 256
8 juin 07:47:20 noyau testvm1.both.org :x86/fpu :Activation des fonctionnalités xstate 0x7, la taille du contexte est de 832 octets, en utilisant le format « standard ». :47:20 noyau testvm1.both.org :BIOS-e820 :[mem 0x00 00000000000000-0x000000000009fbff] utilisable
Jul 16 09:51:00 testvm1.both.org NetworkManager[760] :[1594907460.1765] dhcp4 (enp0s3) :option requests_routers => '1 '
16 juillet 09:51:00 testvm1.both.org NetworkManager[760] :[1594907460.1765] dhcp4 (enp0s3) :option requests_static_routes => '1'
16 juillet 09h51 :00 testvm1.both.org NetworkManager[760] :[1594907460.1765] dhcp4 (enp0s3) :option required_subnet_mask => '1'
Jul 16 09:51:00 testvm1.both.org NetworkManager[760] :[1594907460.1765] dhcp4 (enp0s3) :option requests_time_offset => '1'
16 juillet 09:51:00 testvm1.both.org NetworkManager[760] :[1594907460.1766] dhcp4 (enp0s3) :option required_wpad => '1'
16 juillet 09:51:00 testvm1.both.org NetworkManager[760] :[1594907460.1766] dhcp4 (enp0s3) :option routeurs => '192.168.0.2>
16 juillet 09:51:00 testvm1.both.org NetworkManager[760] :[1594907460.1766] dhcp4 (enp0s3) :option subnet_ mask => '255.255.255>
Jul 16 09:51:00 testvm1.both.org NetworkManager[760] :[1594907460.1766] dhcp4 (enp0s3) :état modifié étendu -> étendu
16 juillet 09:51:00 testvm1.both.org systemd[1] :Démarrage du service de répartiteur de scripts de Network Manager...
16 juillet 09:51:00 testvm1.both.org systemd[1] :Démarrage de Network Manager Script Dispatcher Service.
Juil 16 09:51:00 testvm1.both.org audit[1] :SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=NetworkManager-dispatcher com>
16 juillet 09:51:10 testvm1.both.org systemd[1] : NetworkManager-dispatcher.service :réussi.
16 juillet 09:51:10 testvm1.both.org audit[1] :SERVICE_STOP pid =1 uid=0 auid=4294967295 ses=4294967295 msg='unit=NetworkManager-dispatcher comm>
Jul 16 09:59:13 testvm1.both.org systemd[1] :Démarrage dnf makecache...
16 juillet 09:59:13 testvm1.both.org audit[1] :SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=dnf-makecache comm="systemd">
16 juillet 09:59 :13 audit testvm1.both.org[1] :SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=dnf-makecache comm="systemd" e>
Jul 16 09:59:13 testvm1.both.org systemd[1] :dnf-makecache.service :réussi.
16 juillet 09:59:13 testvm1.both.org systemd[1] : dnf makecache terminé.
16 juillet 09 :59:14 testvm1.both.org dnf[378549] :Cache de métadonnées actualisé récemment.
16 juillet 10:00:42 testvm1.both.org systemd[1] :Démarrage de l'outil de comptabilisation de l'activité du système...
16 juillet 10:00:42 testvm1.both.org systemd[1] :sysstat-collect.service :réussi.
16 juillet 10:00:42 testvm1.both.org audit[1] :SERVICE_START pid =1 uid=0 auid=4294967295 ses=4294967295 msg='unit=sysstat-collect comm="systemd>
Jul 16 10:00:42 testvm1.both.org systemd[1] :outil de comptabilisation de l'activité système terminé .
16 juillet 10:00:42 testvm1.both.org audit[1] :SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=sysstat-collect comm="systemd">
16 juillet 10:01:01 testvm1.both.org CROND[378562] :(racine) CMD (run-parts /etc/cron.hourly)
16 juillet 10:01:01 testvm1.both.org run-parts[378565] :(/etc/cron.hourly) à partir de 0anacron
16 juillet 10:01:01 testvm1.both.org run-parts[378571] :(/etc/cron.hourly) a terminé 0anacron
Vous pouvez également afficher explicitement les mêmes données dans le dmesg commande présente. Ouvrez deux sessions de terminal l'une à côté de l'autre et émettez le dmesg commande dans l'un et la commande suivante dans l'autre :
[root@testvm1 ~]# journalctl --dmesg
La seule différence que vous devriez voir est le format de l'heure. Le dmesg La commande est dans un format monotone qui indique le nombre de secondes depuis le démarrage du système. Le journalctl la sortie est au format date et heure. L'option short-monotone affiche le temps écoulé depuis le démarrage :
[root@testvm1 ~]# journalctl --dmesg -o short-monotonic
-- Les journaux commencent le lundi 2020-06-08 07:47:20 EDT, se terminent le lundi 2020-07-20 13 :01:01 HAE. --
[ 0.000000] noyau testvm1.both.org :Linux version 5.7.6-201.fc32.x86_64 ([email protected]) (gcc version 10.1.>
[ 0.000000 ] Noyau testvm1.both.org :Ligne de commande :BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.7.6-201.fc32.x86_64 root=/dev/mapper/VG01-root ro r>
[ 0.000000] Noyau testvm1.both.org : x86/fpu :Prise en charge de la fonctionnalité XSAVE 0x001 : 0,000000] Noyau testvm1.both.org :x86/fpu :Prise en charge de la fonctionnalité XSAVE 0x002 : 0,000000] br />[ 0.000000] Noyau testvm1.both.org :x86/fpu :Prise en charge de la fonctionnalité XSAVE 0x004 : 0.000000] Noyau testvm1.both.org :x86/fpu :xstate_offset[2] : 576 , xstate_sizes[2] : 256
[ 0,000000] Noyau testvm1.both.org :x86/fpu :fonctionnalités xstate activées 0x7, la taille du contexte est de 832 octets, en utilisant le format "standard".
[ 0.000002] noyau testvm1.both.org :source d'horloge :kvm-clock :masque :0xffffffffffffffff max_cycles :0x1cd42e4dffb, max_idle_ns :881 5905914>
[ 0.000005] noyau testvm1.both.org :tsc :processeur 2 807,988 MHz détecté
[ 0.001157] noyau testvm1.both.org :e820 :mise à jour [mem 0x00000000-0x00000fff] utilisable ==> réservé
[ 0.001159] noyau testvm1.both.org :e820 : supprimer [mem 0x000a0000-0x000fffff] utilisable
[ 0.001162] noyau testvm1.both.org :last_pfn =0x24ec00 max_arch_pfn =0x1 0000 0x1 />2 000
[ 0.001162] noyau testvm1.both.org :] noyau testvm1.both.org :type MTRR par défaut :impossible à mettre en cache
[ 0.001173] noyau testvm1.both.org :plages de variables MTRR désactivées :
[ 0.001173] noyau testvm1.both.org :désactivé
[ 0.001174] Noyau testvm1.both.org :x86/PAT : MTRR désactivés, ignorer également l'initialisation PAT.
[ 0.001176] Noyau testvm1.both.org : MTRR du processeur tous vides – système virtualisé.
[ 0.001179] Noyau testvm1.both.org :x86/PAT :Configuration [0-7] :WB WT UC- UC WB WT UC- UC
[ 0.001182] Noyau testvm1.both.org :last_pfn =0xdfff0 max_arch_pfn =0x400000000
[ 0,001238] essai Noyau vm1.both.org :table MP SMP trouvée sur [mem 0x0009fff0-0x0009ffff]
[ 0.081068] noyau testvm1.both.org :RAMDISK :[mem 0x34194000-0x360c1fff]
[ 0.081088] testvm1. noyau both.org :ACPI :vérification précoce de la somme de contrôle de la table désactivée
[ 34.037575] noyau testvm1.both.org :16:43:32.734466 main 6.1.10_Fedora r138449 démarré. Niveau détaillé =0
[ 34.042209] noyau testvm1.both.org :16:43:32.739032 principal vbglR3GuestCtrlDetectPeekGetCancelSupport :pris en charge (#1)
[ 55.746944] noyau testvm1.both.org :e1000 :lien NIC enp0s3 is Up 1000 Mbps Full Duplex, Flow Control :RX
[ 55.747738] noyau testvm1.both.org :IPv6 :ADDRCONF(NETDEV_CHANGE) :enp0s3 :le lien devient prêt
lignes 624 -681/681 (FIN)
Le journalctl La commande a de nombreuses options, y compris le -o (sortie) avec plusieurs sous-options qui vous permettent de sélectionner un format d'heure et de date qui répond à différents ensembles d'exigences. J'ai répertorié la plupart d'entre eux ci-dessous, ainsi qu'une courte description que j'ai développée ou modifiée à partir du journalctl page de manuel. Notez que la principale différence entre la plupart d'entre eux est le format de la date et de l'heure, et les autres informations restent les mêmes.
formats d'heure et de date journalctl
- court : Il s'agit du format par défaut et génère une sortie qui ressemble le plus au formatage des fichiers syslog classiques, affichant une ligne par entrée de journal. Cette option affiche les métadonnées du journal, y compris le temps monotone depuis le démarrage, le nom d'hôte complet et le nom de l'unité tel que le noyau, DHCP, etc.
Jul 20 08:43:01 testvm1.both Noyau .org :entrées de la table de hachage d'inode-cache :1048576 (ordre :11 8388608 octets, linéaire) - court-complet : Ce format est très similaire au format par défaut, mais affiche les horodatages au format
--since=et--jusqu'à=les options acceptent. Contrairement aux informations d'horodatage affichées en mode de sortie court, ce mode inclut des informations sur le jour de la semaine, l'année et le fuseau horaire dans la sortie et est indépendant des paramètres régionaux.Mon 2020-06-08 07:47:20 Noyau EDT testvm1.both.org :x86/fpu :prise en charge de la fonctionnalité XSAVE 0x004 : 'AVX registers' - short-iso : Le format iso court est très similaire au format par défaut, mais affiche les horodatages de l'horloge murale ISO 8601.
2020-06-08T07:47:20-0400 noyau testvm1.both.org :kvm-clock :Utilisation de msrs 4b564d01 et 4b564d00 - court-iso-précis :
2020-06-08T07:47:20.223738-0400 noyau testvm1.both.org :Démarrage du noyau paravirtualisé sur KVM - court-monotone :
[ 2.091107] noyau testvm1.both.org :ata1.00 :ATA-6 :VBOX HARDDISK, 1.0, max UDMA/ 133 - court-précis : Ce format est également similaire au format par défaut, mais affiche les horodatages syslog classiques avec une précision totale à la microseconde. 0x000000000009ffff] réservé
- short-unix : Comme la valeur par défaut, mais affiche les secondes écoulées depuis le 1er janvier 1970, UTC au lieu des horodatages d'horloge ("heure Unix"). L'heure est affichée avec une précision à la microseconde.
1591616840.232165 noyau testvm1.both.org :tcp_listen_portaddr_hash entrées de la table de hachage :8192 - chat : Génère une sortie très concise montrant uniquement le message de chaque entrée de journal sans métadonnées, pas même un horodatage.
ohci-pci 0000:00:06.0 :irq 22, io mem 0xf0804000 - verbeux : Ce format affiche la structure complète des données pour tous les éléments d'entrée avec tous les champs. C'est l'option de format qui est la plus différente de toutes les autres.
Mon 2020-06-08 07:47:20.222969 EDT [s=d52ddc9f3e8f434b9b9411be2ea50b1e;i=1;b=dcb6dcc0658e4a8d8c781c21a2c6360d;m=242dc6360d;m=242 t=5a7912c6148f9;x=8f>
_SOURCE_MONOTONIC_TIMESTAMP=0
_TRANSPORT=noyau
PRIORITY=5
SYSLOG_FACILITY=0
SYSLOG_IDENTIFIER=noyau
MESSAGE=Linux version 5.6.6-300.fc32.x86_64 ([email protected]) (gcc version 10.0.1 20200328 (Red Hat 10.0.1-0) 3bccd1140fca488187f8a1439c832f07
_HOSTNAME=testvm1.both.org
Autres choix, disponibles avec le -o option, permet d'exporter les données dans différents formats tels que binaire ou JSON. Je trouve aussi le -x option éclairante car elle peut afficher des messages explicatifs supplémentaires pour certaines entrées de journal. Si vous essayez cette option, sachez qu'elle peut augmenter considérablement le flux de données de sortie. Par exemple, les informations supplémentaires pour une entrée telle que :
[ 4.503737] testvm1.both.org systemd[1] :Démarrage de la vérification du système de fichiers sur /dev/mapper/VG01-root...
[ 4.691555] testvm1.both.org systemd-fsck[548] :root :nettoyer, 1813/327680 fichiers, 48555/1310720 blocs
[ 4.933065] testvm1.both.org systemd[1] :vérification du système de fichiers terminée sur /dev/mapper/VG01-root.
développe ceci :
[ 4.503737] testvm1.both.org systemd[1] :Démarrage de la vérification du système de fichiers sur /dev/mapper/VG01-root...
-- Objet :Une tâche de démarrage pour l'unité systemd-fsck-root .service a commencé son exécution
-- Défini par :systemd
-- Assistance :https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Une tâche de démarrage pour l'unité systemd-fsck-root.service a commencé son exécution.
--
-- L'identifiant de la tâche est 36.
[ 4.691555] testvm1.both.org systemd -fsck[548] :racine :nettoyer, 1 813/327 680 fichiers, 48 555/1310 720 blocs
[ 4.933065] testvm1.both.org systemd[1] :vérification du système de fichiers terminée sur /dev/mapper/VG01-root.
-- Objet :Une tâche de démarrage pour l'unité systemd-fsck-root.service s'est terminée avec succès
-- Défini par :systemd
-- Assistance :https://lists.freedesktop. org/mailman/listinfo/systemd-devel
--
-- Une tâche de démarrage pour l'unité systemd-fsck-root.service s'est terminée avec succès.
--
-- Le l'identifiant de travail est 36
Il y a de nouvelles informations ici, mais je pense que le principal avantage est que les informations sont contextualisées pour clarifier dans une certaine mesure les messages laconiques d'origine.
Réduire la recherche
La plupart du temps, il n'est pas nécessaire ni même souhaitable de lister toutes les entrées de journal et de les parcourir manuellement. Parfois, je recherche des entrées liées à un service spécifique, et d'autres fois, je recherche des entrées qui se sont produites à des moments précis. Le journalctl La commande fournit des options puissantes qui vous permettent de voir uniquement les données qui vous intéressent.
Commencez par le --list-boots option, qui répertorie tous les démarrages pendant la période où les entrées de journal existent. Notez que le journalctl.conf peut spécifier que les entrées de journal sont supprimées après avoir atteint un certain âge ou après que l'espace de stockage (HDD/SSD) occupé par les journaux atteint un montant maximum spécifié :
[root@testvm1 ~]# journalctl --list-boots
-10 dcb6dcc0658e4a8d8c781c21a2c6360d Lundi 2020-06-08 07:47:20 EDT—Lun 2020-06-08 07:53:05 EDT
-9 7d61951a85f445c5946774aaae8bc2a4 ven. 2020-07-03 15:50:06 EDT—ven. 2020-07-03 18:21:23 EDT
-8 1b3a847577e544b4a2679fe576b62206 ven. 2:0:06 EDT Ven 2020-07-03 22:10:54 EDT
-7 5fef01a3568743af99118107ca6f61ae Ven 2020-07-03 22:18:41 EDT—Sam 2020-07-04 06:50:19 EDT
-6 6E944F99EBD9405984090F829A927FA4 SAT 2020-07-04 07:33:25 EDT-SAT 2020-07-04 07:58:59 EDT
-5 EC8B0C81CA4744B1BAD071BDEF432959 SAT 2020-07-04 08:12:06 EDT-SAT 2020-07 -04 09:12:47 EDT
-4 cb173ec716824e21b87ccf6cb43a9a99 Sam 2020-07-04 10:19:53 EDT—Sam 2020-07-04 11:31:03 EDT
-3 4fe354a893194409843a 07-04 07:59:58 EDT—Dim 2020-07-05 09:39:30 EDT
-2 06fb81f1b29e4f68af9860844668446c Lun 2020-07-06 06:27:05 EDT—Lun 2020-07-13 08 :50:06 EDT
-1 33dbf8e6b9de4113a591c4f487d0ac37 Lun 2020-07-13 04:50:33 EDT— Jeu 2020-07-16 13:49:32 EDT
0 75c9b70913934748b5396b3b172bee50 Lun 2020-07-20 08:43:01 EDT—Ven 2020-07-24 12:44:06 EDT
L'ID de démarrage le plus récent apparaît en bas ; c'est le nombre hexadécimal long et aléatoire. Vous pouvez utiliser ces données pour afficher les journaux d'un démarrage spécifique. Cela peut être spécifié à l'aide du numéro de décalage de démarrage dans la colonne la plus à gauche ou de l'UUID dans la deuxième colonne. Cette commande affiche le journal de l'instance de démarrage avec le décalage de -2 —le deuxième démarrage précédent à partir de celui en cours :
[root@testvm1 ~]# journalctl -b -2
-- Les journaux commencent le lundi 2020-06-08 07:47:20 EDT, se terminent le vendredi 2020-07-24 12:44:06 EDT. --
Jul 06 06:27:05 noyau testvm1.both.org :Linux version 5.7.6-201.fc32.x86_64 ([email protected]) (gcc version 10.1>
Jul 06 06:27:05 testvm1.both.org kernel:Command line:BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.7.6-201.fc32.x86_64 root=/dev/mapper/VG01-root ro>
Jul 06 06:27:05 testvm1.both.org kernel:x86/fpu:Supporting XSAVE feature 0x001:'x87 floating point registers'
Jul 06 06:27:05 testvm1.both.org kernel:x86/fpu:Supporting XSAVE feature 0x002:'SSE registers'
Or you could use the UUID for the desired boot. The offset numbers change after each boot, but the UUID does not:
[root@testvm1 ~]# journalctl -b 06fb81f1b29e4f68af9860844668446c
The -u option allows you to select specific units to examine. You can use a unit name or a pattern for matching, and you can use this option multiple times to match multiple units or patterns. In this example, I used it in combination with -b to show chronyd journal entries for the current boot:
[root@testvm1 ~]# journalctl -u chronyd -b
-- Logs begin at Mon 2020-06-08 07:47:20 EDT, end at Sun 2020-07-26 09:10:47 EDT. --
Jul 20 12:43:31 testvm1.both.org systemd[1]:Starting NTP client/server...
Jul 20 12:43:31 testvm1.both.org chronyd[811]:chronyd version 3.5 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCD>
Jul 20 12:43:31 testvm1.both.org chronyd[811]:Frequency -0.021 +/- 0.560 ppm read from /var/lib/chrony/drift
Jul 20 12:43:31 testvm1.both.org chronyd[811]:Using right/UTC timezone to obtain leap second data
Jul 20 12:43:31 testvm1.both.org systemd[1]:Started NTP client/server.
Jul 20 12:44:00 testvm1.both.org chronyd[811]:Selected source 192.168.0.52
Jul 20 12:44:00 testvm1.both.org chronyd[811]:System clock TAI offset set to 37 seconds
Jul 20 12:44:00 testvm1.both.org chronyd[811]:System clock wrong by 1.412227 seconds, adjustment started
Jul 20 12:44:01 testvm1.both.org chronyd[811]:System clock was stepped by 1.412227 seconds
[root@testvm1 ~]#
Suppose you want to look at events that were recorded between two arbitrary times. You can also use -S (--since ) and -U (--until ) to specify the beginning and ending times. The following command displays journal entries starting at 15:36:00 on July 24, 2020, through the current time:
[root@testvm1 ~]# journalctl -S "2020-07-24 15:36:00" And this command displays all journal entries starting at 15:36:00 on July 24, 2020, until 16:00:00 on July 25:
[root@testvm1 ~]# journalctl -S "2020-07-24 15:36:00" -U "2020-07-25 16:00:00"
This command combines -S , -U , and -u to give journal entries for the NetworkManager service unit starting at 15:36:00 on July 24, 2020, until 16:00:00 on July 25:
[root@testvm1 ~]# journalctl -S "2020-07-24 15:36:00" -U "2020-07-25 16:00:00" -u NetworkManager
Some syslog facilities, such as cron, auth, mail, daemon, user, and more, can be viewed with the --facility option. You can use --facility=help to list the available facilities. In this example, the mail facility is not the Sendmail service that would be used for an email service, but the local client used by Linux to send email to root as event notifications. Sendmail actually has two parts, the server, which (for Fedora and related distributions) is not installed by default, and the client, which is always installed so that it can be used to deliver system emails to local recipients, especially root:
[root@testvm1 ~]# journalctl --facility=mail
The journalctl man page lists all the options that can be used to narrow searches. The table below summarizes some of the options I use most frequently. Most of these options can be used in various combinations to further narrow a search. Refer to my previous article Analyzing systemd calendar and timespans for details on creating and testing timestamps, as well as important tips like using quotes around timestamps.
Options to narrow searches of the journal
| Option | Description |
|---|---|
--list-boots | This displays a list of boots. The information can be used to show journal entries only for a particular boot. |
-b [offset|boot ID] | This specifies which boot to display information for. It includes all journal entries from that boot through shutdown or reboot. |
--facility=[facility name] | This specifies the facility names as they're known to syslog. Use --facility=help to list the valid facility names. |
-k , --dmesg | These display only kernel messages and are equivalent to using the dmesg command. |
-S , --since [timestamp] | These show all journal entries since (after) the specified time. They can be used with --until to display an arbitrary range of time. Fuzzy times such as "yesterday" and "2 hours ago"—with quotes—are also allowed. |
-u [unit name] | The -u option allows you to select specific units to examine. You can use a unit name or a pattern for matching. This option can be used multiple times to match multiple units or patterns. |
-U , --until [timestamp] | These show all journal entries until (prior to) the specified time. They can be used with --since to display an arbitrary range of time. Fuzzy times such as "yesterday" and "2 hours ago"—with quotes—are also allowed. |
Other interesting options
The journalctl program offers some other interesting options, as well. These are useful for refining the data search, specifying how the journal data is displayed, and managing the journal files.
Additional interesting journalctl options
| Option | Description |
-f , --follow | This journalctl option is similar to using the tail -f commande. It shows the most recent entries in the journal that match whatever other options have been specified and also displays new entries as they occur. This can be useful when watching for events and when testing changes. |
-e , --pager-end | The -e option displays the end of the data stream instead of the beginning. This does not reverse the order of the data stream, rather it causes the pager to jump to the end. |
--file [journal filename] | This names a specific journal file in /var/log/journal/ . |
-r , --reverse | This option reverses the order of the journal entries in the pager so that the newest are at the top rather than the bottom. |
-n , --lines=[X] | This shows the most recent X number of lines from the journal. |
--utc | This displays times in UTC rather than local time. |
-g , --grep=[REGEX] | I like the -g option because it enables me to search for specific patterns in the journal data stream. This is just like piping a text data stream through the grep commande. This option uses Perl-compatible regular expressions. |
--disk-usage | This option displays the amount of disk storage used by the current and archived journals. It might not be as much as you think. |
--flush | Journal data stored in the virtual filesystem /run/log/journal/ , which is volatile storage, is written to /var/log/journal/ which is persistent storage. This option ensures that all data is flushed to /run/log/journal/ at the time it returns. |
--sync | This writes all unwritten journal entries (still in RAM but not in /run/log/journal ) to the persistent filesystem. All journal entries known to the journaling system at the time the command is entered are moved to persistent storage. |
--vacuum-size= --vacuum-time= --vacuum-files= | These can be used singly or in combination to remove the oldest archived journal files until the specified condition is met. These options only consider archived files, and not active files, so the result might not be exactly what was specified. |
I'll explore some of these entries below. More options can be found in the journalctl man page.
Journal files
If you have not already, be sure to list the files in the journal directory on your host. Remember that the name of the directory containing the journal files is a long, random number. This directory contains multiple active and archived journal files, including some for users:
[root@david ~]# cd /var/log/journal/ad8f29ed15044f8ba0458c846300c2a4/
[root@david ad8f29ed15044f8ba0458c846300c2a4]# ll
total 352308
-rw-r-----+ 1 root systemd-journal 33554432 May 28 13:07 system@0c91aaef57c441859ea5e421edff6528-0000000000000001-0005a6703120d448.journal
-rw-r-----+ 1 root systemd-journal 109051904 Jun 23 21:24 system@0c91aaef57c441859ea5e421edff6528-0000000000008238-0005a6b85e4e03c6.journal
-rw-r-----+ 1 root systemd-journal 100663296 Jul 21 18:39 system@0c91aaef57c441859ea5e421edff6528-0000000000021f3e-0005a8ca55efa66a.journal
-rw-r-----+ 1 root systemd-journal 41943040 Jul 30 09:34 system.journal
-rw-r-----+ 1 root systemd-journal 8388608 May 28 13:07 user-1000@037bcc7935234a5ea243b3af304fd08a-0000000000000c45-0005a6705ac48a3c.journal
-rw-r-----+ 1 root systemd-journal 16777216 Jun 23 21:24 user-1000@bc90cea5294447fba2c867dfe40530db-0000000000008266-0005a6b85e910761.journal
-rw-r-----+ 1 root systemd-journal 41943040 Jul 21 16:08 user-1000@bc90cea5294447fba2c867dfe40530db-0000000000021f4b-0005a8ca68c83ab7.journal
-rw-r-----+ 1 root systemd-journal 8388608 Jul 30 09:34 user-1000.journal
[root@david ad8f29ed15044f8ba0458c846300c2a4]#
You can see the user files in this listing for the user ID (UID) 1000, which is my Linux account. The --files option allows me to see the content of specified files, including the user files:
[root@david ad8f29ed15044f8ba0458c846300c2a4]# journalctl --file user-1000.journal
Jul 29 14:13:32 david.both.org tumblerd[145509]:Registered thumbnailer /usr/bin/gdk-pixbuf-thumbnailer -s %s %u %o
Jul 29 14:13:32 david.both.org Thunar[2788]:ThunarThumbnailer:got 0 handle (Queue)
Jul 29 14:13:32 david.both.org Thunar[2788]:ThunarThumbnailer:got 0 handle (Error or Ready)
Jul 29 14:13:32 david.both.org Thunar[2788]:ThunarThumbnailer:got 0 handle (Finished)
Jul 29 14:15:33 david.both.org tumblerd[145552]:error:Broken zip file structure
Jul 29 14:20:34 david.both.org systemd[2466]:dbus-:[email protected]:Succeeded.
Jul 29 14:34:17 david.both.org systemd[2466]:Starting Cleanup of User's Temporary Files and Directories...
Jul 29 14:34:17 david.both.org systemd[2466]:systemd-tmpfiles-clean.service:Succeeded.
Jul 29 14:34:17 david.both.org systemd[2466]:Finished Cleanup of User's Temporary Files and Directories.
Jul 29 14:48:26 david.both.org systemd[2466]:Started dbus-:[email protected].
Jul 29 14:48:26 david.both.org tumblerd[145875]:Registered thumbnailer gsf-office-thumbnailer -i %i -o %o -s %s
This output shows, among other things, temporary file cleanup for the UID1000 user. Data relating to individual users may be helpful in locating the root cause of problems originating in user space. I found a number of interesting entries in this output. Try it on your host and see what you find.
Adding journal entries
It can be useful to add your own entries to the journal. This is accomplished with the systemd-cat program that allows piping the STDOUT of a command or program to the journal. This command can be used as part of a pipeline on the command line or in a script:
[root@testvm1 ~]# echo "Hello world" | systemd-cat -p info -t myprog
[root@testvm1 ~]# journalctl -n 10
Jul 27 09:01:01 testvm1.both.org CROND[976442]:(root) CMD (run-parts /etc/cron.hourly)
Jul 27 09:01:01 testvm1.both.org run-parts[976445]:(/etc/cron.hourly) starting 0anacron
Jul 27 09:01:01 testvm1.both.org run-parts[976451]:(/etc/cron.hourly) finished 0anacron
Jul 27 09:07:53 testvm1.both.org unknown[976501]:Hello world
Jul 27 09:10:47 testvm1.both.org systemd[1]:Starting system activity accounting tool...
Jul 27 09:10:47 testvm1.both.org systemd[1]:sysstat-collect.service:Succeeded.
Jul 27 09:10:47 testvm1.both.org systemd[1]:Finished system activity accounting tool.
Jul 27 09:10:47 testvm1.both.org audit[1]:SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/syst>
Jul 27 09:10:47 testvm1.both.org audit[1]:SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/syste>
Jul 27 09:17:10 testvm1.both.org myprog[976516]:Hello world
[root@testvm1 ~]#
The -p option specifies a priority, emerg, alert, crit, err, warning, notice, info, debug, or a value between 0 and 7 that represents each of those named levels. These priority values are the same as those defined by syslog(3) . The default is info. The -t option is an identifier, which can be any arbitrary short string, such as a program or script name. This string can be used for searches by the journalctl commande :
[root@testvm1 ~]# journalctl -t myprog
-- Logs begin at Mon 2020-06-08 07:47:20 EDT, end at Mon 2020-07-27 09:21:57 EDT. --
Jul 27 09:17:10 testvm1.both.org myprog[976516]:Hello world
[root@testvm1 ~]#
Journal management
I use the --disk-usage option to check on journal sizes, along with other commands relating to disk usage, to ensure that my /var filesystem is not filling up:
[root@testvm1 ~]# journalctl --disk-usage
Archived and active journals take up 136.0M in the file system.
[root@testvm1 ~]#
The disk usage for the journals on the testvm1 host is about 136MB. The result on my primary workstation is 328MB, and the host I use for my firewall and router uses 2.8GB for the journals. Journal sizes depend greatly on the host's use and daily run time. My physical hosts all run 24x7.
The /etc/systemd/journald.conf file can be used to configure the journal file sizes, rotation, and retention times to meet any needs not met by the default settings. You can also configure the journal storage location—you can specify a directory on the storage device or whether to store everything in RAM, which is volatile storage. If the journals are stored in RAM, they will not be persistent between boots.
The default time unit in the journald.conf file is seconds, but it can be overridden using the suffixes year , month , week , day , h , or m .
Suppose you want to limit the total amount of storage space allocated to journal files to 1GB, store all journal entries in persistent storage, keep a maximum of 10 files, and delete any journal archive files that are more than a month old. You can configure this in /etc/systemd/journald.conf using:
SystemMaxUse=1G
Storage=persistent
SystemMaxFiles=10
MaxRetentionSec=1month
By default, the SystemMaxUse is 10% of available disk space. The default settings have been fine for the systems I work with, and I have not needed to change any of them. The journald.conf man page states that the time-based settings for specifying how long to store journal entries in a single file or to retain older files are normally not necessary. This is because file number and size configurations usually force rotation and deletion of old files before any time settings might be needed.
The SystemKeepFree option ensures a specific amount of space is kept free for other data. Many databases and application programs use the /var filesystem to store data, so ensuring enough available storage space may be critical in systems with smaller hard drives and minimum space allocated to /var .
If you make changes to this configuration, be sure to monitor the results carefully for an appropriate period of time to ensure they are performing as expected.
Journal file rotation
The journal files are typically rotated automatically based upon the configuration in the /etc/systemd/journald.conf dossier. Files are rotated whenever one of the specified conditions is met. So if, for example, the space allocated to journal files is exceeded, the oldest file(s) is deleted, the active file is made into an archive, and a new active file is created.
Journal files can also be rotated manually. I suggest using the --flush option to ensure current data is moved to persistent storage before you run the command:
[root@testvm1 ~]# journalctl --rotate
There is another way to purge old journal files without performing a file rotation. The vacuum-size= , vacuum-files= , and vacuum-time= commands can be used to delete old archive files down to a specified total size, number of files, or prior time. The option values consider only the archive files and not the active ones, so the resulting reduction in total file size might be somewhat less than expected.
The following command purges old archive files so that only ones that are less than one month old are left. You can use the s , m , h , days , months , weeks , and years suffixes:
[root@testvm1 ~]# journalctl --vacuum-time=1month This command deletes all archive files except for the four most recent ones. If there are fewer than four archive files, nothing will happen, and the original number of files remains:
[root@testvm1 ~]# journalctl --vacuum-files=4
This last vacuum command deletes archive files until 200MB or less of archived files are left:
[root@testvm1 ~]# journalctl --vacuum-size=200M Only complete files are deleted. The vacuum commands do not truncate archive files to meet the specification. They also work only on archive files, not active ones.
Réflexions finales
This article looked at using the journalctl command to extract various types of data from the systemd journal in different formats. It also explored managing journal files and how to add entries to the log from commands and scripts.
The systemd journal system provides a significant amount of metadata and context for entries compared to the old syslogd program. This additional data and the context available from the other journal entries around the time of an incident can help the sysadmin locate and resolve problems much faster than having to search multiple syslog files.
In my opinion, the journalctl command meets the Unix philosophy that programs should do one thing and do it well. The only thing journalctl does is extract data from the journal and provide many options for selecting and formatting that data. At about 85K, it is not very big. Of course, that does not include shared libraries, but those are, by definition, shared with other programs.
You should now have enough information to use the systemd journal more effectively. If you would like to know more than what I covered here, look in the man pages for journalctl and systemd-cat .
Resources
There is a great deal of information about systemd available on the internet, but much is terse, obtuse, or even misleading. In addition to the resources mentioned in this article, the following webpages offer more detailed and reliable information about systemd startup. This list has grown since I started this series of articles to reflect the research I have done.
- DigitalOcean has a very good article about journalctl and how to view and manipulate systemd logs.
- The Fedora Project has a good, practical guide to systemd. It has pretty much everything you need to know in order to configure, manage, and maintain a Fedora computer using systemd.
- The Fedora Project also has a good cheat sheet that cross-references the old SystemV commands to comparable systemd ones.
- Red Hat documentation contains a good description of the Unit file structure as well as other important information.
- For detailed technical information about systemd and the reasons for creating it, check out Freedesktop.org's description of systemd.
- Linux.com's "More systemd fun" offers more advanced systemd information and tips.
There is also a series of deeply technical articles for Linux sysadmins by Lennart Poettering, the designer and primary developer of systemd. These articles were written between April 2010 and September 2011, but they are just as relevant now as they were then. Much of everything else good that has been written about systemd and its ecosystem is based on these papers.
- Rethinking PID 1
- systemd for Administrators, Part I
- systemd for Administrators, Part II
- systemd for Administrators, Part III
- systemd for Administrators, Part IV
- systemd for Administrators, Part V
- systemd for Administrators, Part VI
- systemd for Administrators, Part VII
- systemd for Administrators, Part VIII
- systemd for Administrators, Part IX
- systemd for Administrators, Part X
- systemd for Administrators, Part XI