« Admin/Systemd/Journalctl » : différence entre les versions

De TartareFR
Aller à la navigation Aller à la recherche
 
(6 versions intermédiaires par le même utilisateur non affichées)
Ligne 2 : Ligne 2 :


Depuis Fedora 18, [[Admin/Systemd/Brief|systemd]] est pleinement implémenté, c'est à dire que la commande pour visualiser les journaux systèmes est <app>journalctl</app>.
Depuis Fedora 18, [[Admin/Systemd/Brief|systemd]] est pleinement implémenté, c'est à dire que la commande pour visualiser les journaux systèmes est <app>journalctl</app>.
 
  journalctl
Le lancement de cette commande sans argument affiche tous les logs et peut contenir beaucoup de traces.
  # journalctl


Cette commande lancée avec le super-utilisateur root, permet de voir tous les logs générés par le système et par les utilisateurs de celui-ci. A contrario, lancée avec un utilisateur basique, seuls les logs lui appartenant seront visibles. C'est une amélioration du traditionnel format de <path>/var/log/messages</path>:
Cette commande lancée avec le super-utilisateur root, permet de voir tous les logs générés par le système et par les utilisateurs de celui-ci. A contrario, lancée avec un utilisateur basique, seuls les logs lui appartenant seront visibles. C'est une amélioration du traditionnel format de <path>/var/log/messages</path>:
Ligne 18 : Ligne 16 :
* Appel à l'API native de Journal
* Appel à l'API native de Journal
* Écriture sur STDOUT et STDERR
* Écriture sur STDOUT et STDERR
== Équivalences ==
<app>journalctl</app> remplace <app>cat /var/log/messages</app>
<app>journalctl -f</app> remplace <app>tail -f /var/log/messages</app>
<app>journalctl | grep foobar</app> remplace <app>grep foobar /var/log/messages</app>


== Contrôle d'accès ==
== Contrôle d'accès ==
Ligne 30 : Ligne 22 :
  usermod -a -G adm didier
  usermod -a -G adm didier


== Live View ==
== Temps réel ==
 
If invoked without parameters journalctl will show me the current log database. Sometimes one needs to watch logs as they grow, where one previously used tail -f /var/log/messages:


Le lancement de cette commande sans argument affiche tous les logs et peut contenir beaucoup de traces. Pour afficher les traces en temps réel, on ajoute l'option '''-f''' comme pour la commande <app>tail</app>. Cette commande est équivalente à <app>tail -f /var/log/messages</app>
  journalctl -f
  journalctl -f


Yes, this does exactly what you expect it to do: it will show you the last ten logs lines and then wait for changes and show them as they take place.
Cela affiche les dix dernières lignes et se rafraichie en temps réel.
Basic Filtering
 
When invoking journalctl without parameters you'll see the whole set of logs, beginning with the oldest message stored. That of course, can be a lot of data. Much more useful is just viewing the logs of the current boot:
 
journalctl -b
 
This will show you only the logs of the current boot, with all the aforementioned gimmicks mentioned. But sometimes even this is way too much data to process. So what about just listing all the real issues to care about: all messages of priority levels ERROR and worse, from the current boot:
 
journalctl -b -p err
 
If you reboot only seldom the -b makes little sense, filtering based on time is much more useful:
 
journalctl --since=yesterday
 
And there you go, all log messages from the day before at 00:00 in the morning until right now. Awesome! Of course, we can combine this with -p err or a similar match. But humm, we are looking for something that happened on the 15th of October, or was it the 16th?
 
journalctl --since=2012-10-15 --until="2011-10-16 23:59:59"
 
Yupp, there we go, we found what we were looking for. But humm, I noticed that some CGI script in Apache was acting up earlier today, let's see what Apache logged at that time:
 
journalctl -u httpd --since=00:00 --until=9:30
 
Oh, yeah, there we found it. But hey, wasn't there an issue with that disk /dev/sdc? Let's figure out what was going on there:
 
journalctl /dev/sdc
 
OMG, a disk error![2] Hmm, let's quickly replace the disk before we lose data. Done! Next! -- Hmm, didn't I see that the vpnc binary made a booboo? Let's check for that:
 
journalctl /usr/sbin/vpnc
 
Hmm, I don't get this, this seems to be some weird interaction with dhclient, let's see both outputs, interleaved:


journalctl /usr/sbin/vpnc /usr/sbin/dhclient
== Filtrage Basique ==


That did it! Found it!
* Pour visualiser uniquement les logs depuis le démarrage<pre>journalctl -b</pre>
* On peut coupler les filtres: affichage des logs générés depuis le démarrage et de priorité erreur<pre>journalctl -b -p err</pre>
* Si la période entre deux démarrage est longue, filtrer sur une date est plus intéressant<pre>journalctl --since=yesterday</pre>
* Pour chercher les traces générées le 15 et 16 octobre 2012<pre>journalctl --since=2012-10-15 --until="2011-10-16 23:59:59"</pre>
* Pour chercher les traces générées par apache aujourd'hui entre minuit et 09h30<pre>journalctl -u httpd --since=00:00 --until=9:30</pre>
* Pour chercher les traces générées par le disque /dev/sda<pre>journalctl /dev/sda</pre>
* Pour chercher les traces générées par l'application dhclient<pre>journalctl /usr/sbin/vpnc</pre>
* On peut spécifier plus d'une application<pre>journalctl /sbin/dhclient /sbin/bridge</pre>


== Advanced Filtering ==
== Filtrage avancé ==


Whew! That was awesome already, but let's turn this up a notch. Internally systemd stores each log entry with a set of implicit meta data. This meta data looks a lot like an environment block, but actually is a bit more powerful: values can take binary, large values (though this is the exception, and usually they just contain UTF-8), and fields can have multiple values assigned (an exception too, usually they only have one value). This implicit meta data is collected for each and every log message, without user intervention. The data will be there, and wait to be used by you. Let's see how this looks:
[[Admin/Systemd/Brief|Systemd]] garde chaque trace avec un jeu de meta-données implicite en interne. Ces meta-données ressemble à des variables d'envirronement mais elles sont un petit peu plus que cela.
<pre>
<pre>
journalctl -o verbose -n
journalctl -o verbose -n
[...]
[...]
Tue, 2012-10-23 23:51:38 CEST [s=ac9e9c423355411d87bf0ba1a9b424e8;i=4301;b=5335e9cf5d954633bb99aefc0ec38c25;m=882ee28d2;t=4ccc0f98326e6;x=f21e8b1b0994d7ee]
Fri 2013-09-27 12:35:01 CEST [s=fc9f8071f2d340d2a90223d0ee936891;i=4d94;b=6316626194e143398f819153c8ed4397;
m=383ce9d94;t=4e75b09ec1023;x=402b0415f704584d]
         PRIORITY=6
         PRIORITY=6
         SYSLOG_FACILITY=3
         _UID=0
         _MACHINE_ID=a91663387a90b89f185d4e860000001a
         _MACHINE_ID=466993867b10491ea29f60dce19b9347
         _HOSTNAME=epsilon
         _HOSTNAME=didier.b2pweb.com
         _TRANSPORT=syslog
         _TRANSPORT=syslog
         SYSLOG_IDENTIFIER=avahi-daemon
         _SYSTEMD_OWNER_UID=1000
         _COMM=avahi-daemon
        SYSLOG_FACILITY=9
         _EXE=/usr/sbin/avahi-daemon
         _COMM=crond
         _SYSTEMD_CGROUP=/system/avahi-daemon.service
         _EXE=/usr/sbin/crond
         _SYSTEMD_UNIT=avahi-daemon.service
         _SELINUX_CONTEXT=system_u:system_r:crond_t:s0-s0:c0.c1023
         _SELINUX_CONTEXT=system_u:system_r:avahi_t:s0
         _GID=1000
         _UID=70
         SYSLOG_IDENTIFIER=CROND
         _GID=70
         MESSAGE=(didier) CMD (/home/didier/vcs/b2pweb/website/webservice-monitoring/client/webservice-monitoring-graph.sh)
         _CMDLINE=avahi-daemon: registering [epsilon.local]
         _AUDIT_LOGINUID=1000
         MESSAGE=Joining mDNS multicast group on interface wlan0.IPv4 with address 172.31.0.53.
         _CMDLINE=/usr/sbin/CROND -n
         _BOOT_ID=5335e9cf5d954633bb99aefc0ec38c25
        _AUDIT_SESSION=281
         _PID=27937
         _SYSTEMD_CGROUP=/user/1000.user/281.session
         SYSLOG_PID=27937
        _SYSTEMD_SESSION=281
         _SOURCE_REALTIME_TIMESTAMP=1351029098747042
         _BOOT_ID=6316626194e143398f819153c8ed4397
         SYSLOG_PID=11437
         _PID=11437
         _SOURCE_REALTIME_TIMESTAMP=1380278101347809
</pre>
</pre>
(I cut out a lot of noise here, I don't want to make this story overly long. -n without parameter shows you the last 10 log entries, but I cut out all but the last.)
(I cut out a lot of noise here, I don't want to make this story overly long. -n without parameter shows you the last 10 log entries, but I cut out all but the last.)


With the -o verbose switch we enabled verbose output. Instead of showing a pixel-perfect copy of classic /var/log/messages that only includes a minimimal subset of what is available we now see all the gory details the journal has about each entry. But it's highly interesting: there is user credential information, SELinux bits, machine information and more. For a full list of common, well-known fields, see the man page.
Avec l'option '''-o''', les meta-data sont affichées. Le plus intéressant est le stockage des informations de connexion, le contexte SELinux, nom d'hôte, etc... Pour la liste exhaustive des meta-données, on peut consulter la page man.
 
Now, as it turns out the journal database is indexed by all of these fields, out-of-the-box! Let's try this out:
 
journalctl _UID=70
 
And there you go, this will show all log messages logged from Linux user ID 70. As it turns out one can easily combine these matches:
 
journalctl _UID=70 _UID=71
 
Specifying two matches for the same field will result in a logical OR combination of the matches. All entries matching either will be shown, i.e. all messages from either UID 70 or 71.
 
journalctl _HOSTNAME=epsilon _COMM=avahi-daemon
 
You guessed it, if you specify two matches for different field names, they will be combined with a logical AND. All entries matching both will be shown now, meaning that all messages from processes named avahi-daemon and host epsilon.
 
But of course, that's not fancy enough for us. We are computer nerds after all, we live off logical expressions. We must go deeper!
 
journalctl _HOSTNAME=theta _UID=70 + _HOSTNAME=epsilon _COMM=avahi-daemon


The + is an explicit OR you can use in addition to the implied OR when you match the same field twice. The line above hence means: show me everything from host theta with UID 70, or of host epsilon with a process name of avahi-daemon.
tous les champs des meta-données sont indexés.


== And now, it becomes magic! ==
* Affichage de tous les messages concernant l'utilisateur d'identifiant 1000<pre>journalctl _UID=1000</pre>
* Affichage de tous les messages concernant les utilisateur d'identifiant 1000 et 1001<pre>journalctl _UID=1000 _UID=1001</pre>
* Affichage de tous les messages concernant l'hôte didier.b2pweb.com et provenant d'une tâche planifiée<pre>journalctl _HOSTNAME=didier.b2pweb.com _COMM=crond</pre>
* Affichage de tous les messages concernant l'hôte didier.b2pweb.com et provenant d'un utilisateur d'identifiant 1000 OU concernant l'hôte koji.b2pweb.com et provenant d'une tâche planifiée<pre>journalctl _HOSTNAME=didier.b2pweb.com  _UID=1000 + _HOSTNAME=koji.b2pweb.com _COMM=crond</pre>Le '''+''' est ici une condition '''OU''' explicite.


That was already pretty cool, right? Righ! But heck, who can remember all those values a field can take in the journal, I mean, seriously, who has thaaaat kind of photographic memory? Well, the journal has:
== Et encore plus fort ==


journalctl -F _SYSTEMD_UNIT
La complétion automatique est possible avec <app>journalctl</app>.


This will show us all values the field _SYSTEMD_UNIT takes in the database, or in other words: the names of all systemd services which ever logged into the journal. This makes it super-easy to build nice matches. But wait, turns out this all is actually hooked up with shell completion on bash! This gets even more awesome: as you type your match expression you will get a list of well-known field names, and of the values they can take! Let's figure out how to filter for SELinux labels again. We remember the field name was something with SELINUX in it, let's try that:
Pour taper <code>journalctl -F _SYSTEMD_UNIT</code>, il est possible de taper juste <code>journalctl _SE</code> suivi d'une tabulation pour que le champs des meta-données sont complété automatiquement ou un choix propsé dans le cas où plusieurs complément est possible.


journalctl _SE<TAB>
Mais là où c'est vraiment bluffant, c'est qu'une fois le nom du champs entier ( suivi du signe '''<nowiki>=</nowiki>''', une autre tabulation affiche toutes les valeurs déjà enregistrées dans le journal.
 
<syntaxhighlight lang="text">
And yupp, it's immediately completed:
 
journalctl _SELINUX_CONTEXT=
 
Cool, but what's the label again we wanted to match for?
<pre>
journalctl _SELINUX_CONTEXT=<TAB><TAB>
journalctl _SELINUX_CONTEXT=<TAB><TAB>
kernel                                                      system_u:system_r:local_login_t:s0-s0:c0.c1023               system_u:system_r:udev_t:s0-s0:c0.c1023
kernel                                                      system_u:system_r:local_login_t:s0-s0:c0.c1023
system_u:system_r:accountsd_t:s0                             system_u:system_r:lvm_t:s0                                  system_u:system_r:virtd_t:s0-s0:c0.c1023
system_u:system_r:udev_t:s0-s0:c0.c1023                     system_u:system_r:accountsd_t:s0                                              
system_u:system_r:avahi_t:s0                                system_u:system_r:modemmanager_t:s0-s0:c0.c1023             system_u:system_r:vpnc_t:s0
system_u:system_r:lvm_t:s0                                  system_u:system_r:virtd_t:s0-s0:c0.c1023
system_u:system_r:bluetooth_t:s0                             system_u:system_r:NetworkManager_t:s0                        system_u:system_r:xdm_t:s0-s0:c0.c1023
system_u:system_r:avahi_t:s0                                system_u:system_r:modemmanager_t:s0-s0:c0.c1023
system_u:system_r:chkpwd_t:s0-s0:c0.c1023                    system_u:system_r:policykit_t:s0                             unconfined_u:system_r:rpm_t:s0-s0:c0.c1023
system_u:system_r:vpnc_t:s0                                 system_u:system_r:bluetooth_t:s0
system_u:system_r:chronyd_t:s0                              system_u:system_r:rtkit_daemon_t:s0                         unconfined_u:system_r:unconfined_t:s0-s0:c0.c1023
system_u:system_r:NetworkManager_t:s0                        system_u:system_r:xdm_t:s0-s0:c0.c1023
system_u:system_r:crond_t:s0-s0:c0.c1023                    system_u:system_r:syslogd_t:s0                               unconfined_u:system_r:useradd_t:s0-s0:c0.c1023
system_u:system_r:chkpwd_t:s0-s0:c0.c1023                    system_u:system_r:policykit_t:s0
system_u:system_r:devicekit_disk_t:s0                        system_u:system_r:system_cronjob_t:s0-s0:c0.c1023            unconfined_u:unconfined_r:unconfined_dbusd_t:s0-s0:c0.c1023
system_u:system_r:chronyd_t:s0                              system_u:system_r:rtkit_daemon_t:s0
system_u:system_r:dhcpc_t:s0                                system_u:system_r:system_dbusd_t:s0-s0:c0.c1023              unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
system_u:system_r:crond_t:s0-s0:c0.c1023                    system_u:system_r:syslogd_t:s0
system_u:system_r:devicekit_disk_t:s0                        system_u:system_r:system_cronjob_t:s0-s0:c0.c1023
system_u:system_r:dhcpc_t:s0                                system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
system_u:system_r:dnsmasq_t:s0-s0:c0.c1023                  system_u:system_r:systemd_logind_t:s0
system_u:system_r:dnsmasq_t:s0-s0:c0.c1023                  system_u:system_r:systemd_logind_t:s0
system_u:system_r:init_t:s0                                  system_u:system_r:systemd_tmpfiles_t:s0
system_u:system_r:init_t:s0                                  system_u:system_r:systemd_tmpfiles_t:s0
</pre>
unconfined_u:system_r:rpm_t:s0-s0:c0.c1023                  unconfined_u:system_r:unconfined_t:s0-s0:c0.c1023
Ah! Right! We wanted to see everything logged under PolicyKit's security label:
unconfined_u:system_r:useradd_t:s0-s0:c0.c1023              unconfined_u:unconfined_r:unconfined_dbusd_t:s0-s0:c0.c1023
 
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
journalctl _SELINUX_CONTEXT=system_u:system_r:policykit_t:s0
</syntaxhighlight>
 
Wow! That was easy! I didn't know anything related to SELinux could be thaaat easy! ;-) Of course this kind of completion works with any field, not just SELinux labels.
 
So much for now. There's a lot more cool stuff in journalctl(1) than this. For example, it generates JSON output for you! You can match against kernel fields! You can get simple /var/log/messages-like output but with relative timestamps! And so much more!


Anyway, in the next weeks I hope to post more stories about all the cool things the journal can do for you. This is just the beginning, stay tuned.
De plus, la sortie peut-être formatée en JSON.

Dernière version du 28 septembre 2013 à 12:07

Introduction

Depuis Fedora 18, systemd est pleinement implémenté, c'est à dire que la commande pour visualiser les journaux systèmes est <app>journalctl</app>. 

journalctl

Cette commande lancée avec le super-utilisateur root, permet de voir tous les logs générés par le système et par les utilisateurs de celui-ci. A contrario, lancée avec un utilisateur basique, seuls les logs lui appartenant seront visibles. C'est une amélioration du traditionnel format de <path>/var/log/messages</path>:

  • Les lignes de priorité erreur (ou supérieur) sont affiché en rouge
  • Les lignes de priorité notice/warning sont affiché en gras
  • Les timestamps sont convertis en date/heure locale
  • La sortie est utilise automatiquement un pager ( <app>less</app> par défaut)
  • Affiche toutes les traces, même celles qui ont subies une rotation de logs.
  • Un démarrage du système est clairement identifié

Les logs contiennent les trois sources possibles de messages du daemon:

  • Appel depuis la GLibc syslog
  • Appel à l'API native de Journal
  • Écriture sur STDOUT et STDERR

Contrôle d'accès

Afin d'autoriser un utilisateur à visualiser les logs du système, sans devoir devenir le super-utilisateur root, il est prévu que les logs soient lisibles par les membres du groupe adm: 

usermod -a -G adm didier

Temps réel

Le lancement de cette commande sans argument affiche tous les logs et peut contenir beaucoup de traces. Pour afficher les traces en temps réel, on ajoute l'option -f comme pour la commande <app>tail</app>. Cette commande est équivalente à <app>tail -f /var/log/messages</app> 

journalctl -f

Cela affiche les dix dernières lignes et se rafraichie en temps réel.

Filtrage Basique

  • Pour visualiser uniquement les logs depuis le démarrage
    journalctl -b
  • On peut coupler les filtres: affichage des logs générés depuis le démarrage et de priorité erreur
    journalctl -b -p err
  • Si la période entre deux démarrage est longue, filtrer sur une date est plus intéressant
    journalctl --since=yesterday
  • Pour chercher les traces générées le 15 et 16 octobre 2012
    journalctl --since=2012-10-15 --until="2011-10-16 23:59:59"
  • Pour chercher les traces générées par apache aujourd'hui entre minuit et 09h30
    journalctl -u httpd --since=00:00 --until=9:30
  • Pour chercher les traces générées par le disque /dev/sda
    journalctl /dev/sda
  • Pour chercher les traces générées par l'application dhclient
    journalctl /usr/sbin/vpnc
  • On peut spécifier plus d'une application
    journalctl /sbin/dhclient /sbin/bridge

Filtrage avancé

Systemd garde chaque trace avec un jeu de meta-données implicite en interne. Ces meta-données ressemble à des variables d'envirronement mais elles sont un petit peu plus que cela. 

journalctl -o verbose -n
[...]
Fri 2013-09-27 12:35:01 CEST [s=fc9f8071f2d340d2a90223d0ee936891;i=4d94;b=6316626194e143398f819153c8ed4397;
m=383ce9d94;t=4e75b09ec1023;x=402b0415f704584d]
        PRIORITY=6
        _UID=0
        _MACHINE_ID=466993867b10491ea29f60dce19b9347
        _HOSTNAME=didier.b2pweb.com
        _TRANSPORT=syslog
        _SYSTEMD_OWNER_UID=1000
        SYSLOG_FACILITY=9
        _COMM=crond
        _EXE=/usr/sbin/crond
        _SELINUX_CONTEXT=system_u:system_r:crond_t:s0-s0:c0.c1023
        _GID=1000
        SYSLOG_IDENTIFIER=CROND
        MESSAGE=(didier) CMD (/home/didier/vcs/b2pweb/website/webservice-monitoring/client/webservice-monitoring-graph.sh)
        _AUDIT_LOGINUID=1000
        _CMDLINE=/usr/sbin/CROND -n
        _AUDIT_SESSION=281
        _SYSTEMD_CGROUP=/user/1000.user/281.session
        _SYSTEMD_SESSION=281
        _BOOT_ID=6316626194e143398f819153c8ed4397
        SYSLOG_PID=11437
        _PID=11437
        _SOURCE_REALTIME_TIMESTAMP=1380278101347809

(I cut out a lot of noise here, I don't want to make this story overly long. -n without parameter shows you the last 10 log entries, but I cut out all but the last.)

Avec l'option -o, les meta-data sont affichées. Le plus intéressant est le stockage des informations de connexion, le contexte SELinux, nom d'hôte, etc... Pour la liste exhaustive des meta-données, on peut consulter la page man.

tous les champs des meta-données sont indexés.

  • Affichage de tous les messages concernant l'utilisateur d'identifiant 1000
    journalctl _UID=1000
  • Affichage de tous les messages concernant les utilisateur d'identifiant 1000 et 1001
    journalctl _UID=1000 _UID=1001
  • Affichage de tous les messages concernant l'hôte didier.b2pweb.com et provenant d'une tâche planifiée
    journalctl _HOSTNAME=didier.b2pweb.com _COMM=crond
  • Affichage de tous les messages concernant l'hôte didier.b2pweb.com et provenant d'un utilisateur d'identifiant 1000 OU concernant l'hôte koji.b2pweb.com et provenant d'une tâche planifiée
    journalctl _HOSTNAME=didier.b2pweb.com  _UID=1000 + _HOSTNAME=koji.b2pweb.com _COMM=crond
    Le + est ici une condition OU explicite.

Et encore plus fort

La complétion automatique est possible avec <app>journalctl</app>.

Pour taper journalctl -F _SYSTEMD_UNIT, il est possible de taper juste journalctl _SE suivi d'une tabulation pour que le champs des meta-données sont complété automatiquement ou un choix propsé dans le cas où plusieurs complément est possible.

Mais là où c'est vraiment bluffant, c'est qu'une fois le nom du champs entier ( suivi du signe =, une autre tabulation affiche toutes les valeurs déjà enregistrées dans le journal. 

journalctl _SELINUX_CONTEXT=<TAB><TAB>
kernel                                                       system_u:system_r:local_login_t:s0-s0:c0.c1023
system_u:system_r:udev_t:s0-s0:c0.c1023                      system_u:system_r:accountsd_t:s0                                                
system_u:system_r:lvm_t:s0                                   system_u:system_r:virtd_t:s0-s0:c0.c1023
system_u:system_r:avahi_t:s0                                 system_u:system_r:modemmanager_t:s0-s0:c0.c1023
system_u:system_r:vpnc_t:s0                                  system_u:system_r:bluetooth_t:s0
system_u:system_r:NetworkManager_t:s0                        system_u:system_r:xdm_t:s0-s0:c0.c1023
system_u:system_r:chkpwd_t:s0-s0:c0.c1023                    system_u:system_r:policykit_t:s0
system_u:system_r:chronyd_t:s0                               system_u:system_r:rtkit_daemon_t:s0
system_u:system_r:crond_t:s0-s0:c0.c1023                     system_u:system_r:syslogd_t:s0
system_u:system_r:devicekit_disk_t:s0                        system_u:system_r:system_cronjob_t:s0-s0:c0.c1023
system_u:system_r:dhcpc_t:s0                                 system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
system_u:system_r:dnsmasq_t:s0-s0:c0.c1023                   system_u:system_r:systemd_logind_t:s0
system_u:system_r:init_t:s0                                  system_u:system_r:systemd_tmpfiles_t:s0
unconfined_u:system_r:rpm_t:s0-s0:c0.c1023                   unconfined_u:system_r:unconfined_t:s0-s0:c0.c1023
unconfined_u:system_r:useradd_t:s0-s0:c0.c1023               unconfined_u:unconfined_r:unconfined_dbusd_t:s0-s0:c0.c1023
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

De plus, la sortie peut-être formatée en JSON.

Récupérée de « https://wikiold.home.tartarefr.eu/index.php?title=Admin/Systemd/Journalctl&oldid=2492 »