Skip to content

Commit fbb2bac

Browse files
lvicounlvicoun
committed
Changed the journal section.
1 parent 3d679d1 commit fbb2bac

File tree

2 files changed

+114
-55
lines changed

2 files changed

+114
-55
lines changed

‎concepts/journal-about-journald.xml‎

Lines changed: 4 additions & 51 deletions
Original file line numberDiff line numberDiff line change
@@ -27,55 +27,8 @@
2727
</info>
2828
<para>
2929
On &productname; the <literal>systemd-journald</literal> service is enabled and started by
30-
default. The service logs the data into the journal described in <xref linkend="journal-what-it-is"./>
31-
</para>
32-
33-
34-
as its logging system. The <command>systemd-journald</command> service is enabled by default.</para>
35-
<para>All system events are written to the journal, a system service managed by <command>systemd-journald</command> service. This allows you to search and manage all system logs. It collects and stores logging data by maintaining structured indexed journals based on logging information received from the kernel, user processes, standard input, and system service errors. The journal records nearly every type of event generated on the system, including kernel messages, initrd (initial RAM disk) messages, service startup/shutdown, application events, and authentication and session data. Journal allows centralization and unification of logs from all sources, and it records events in structured manner which in turn helps identifying errors and in crash recovery.</para>
36-
<para><command>journalctl</command> is the command-line tool to view and analyze the logs from the <command>systemd-journald</command> service.</para></abstract>
37-
38-
</info>
39-
<section><title>Understanding <command>journalctl</command> configuration and structure</title>
40-
<para>
41-
This section describes the <command>journalctl</command> location, configuring the location for persistent logs, and the <command>journalctl</command> entry structure.
42-
</para>
43-
<itemizedlist>
44-
<listitem><para>Verify the logs location:</para>
45-
<screen>&prompt.sudo; ls /var/log/journal
46-
&prompt.sudo; ls /run/log/journal
47-
</screen>
48-
<para>The <command>journald</command> command collects log data from several sources simultaneously logs and are then managed in a structured, binary format within files in <filename>/run/log/journal/</filename> by default. Because the <filename>/run/ directory</filename> is volatile by nature, log data is lost at reboot. To make the log data persistent, create a directory <filename>/var/log/journal/</filename> so the <command>systemd-journald</command> service can store its data. To switch to persistent logging across reboots, create <filename>/var/log/journal</filename>:</para>
49-
<screen>&prompt.sudo; mkdir /var/log/journal
50-
&prompt.sudo; systemd-tmpfiles --create --prefix=/var/log/journal
51-
&prompt.sudo; journalctl --flush</screen>
52-
<para>All log data stored in <filename>/run/log/journal/</filename> are flushed into <filename>/var/log/journal/</filename>.</para>
53-
</listitem>
54-
<listitem><para>View the journal entry structure:</para>
55-
<screen>&prompt.sudo; journalctl -n 1 -o verbose</screen>
56-
<para>Log entry in the journal is a data structure containing the log message and metadata fields:</para>
57-
<itemizedlist><listitem><para>Timestamp: The exact time the event occurred.</para></listitem>
58-
<listitem><para>Source Fields</para>
59-
<itemizedlist>
60-
<listitem><para>_PID: Process ID of the sender.</para></listitem>
61-
<listitem><para>_UID/_GID: User/Group ID of the sender.</para></listitem>
62-
<listitem><para>_EXE: Path to the executable.</para></listitem>
63-
<listitem><para>_COMM: Name of the executable.</para></listitem>
64-
</itemizedlist>
65-
</listitem>
66-
<listitem><para>System Fields</para>
67-
<itemizedlist>
68-
<listitem><para>_SYSTEMD_UNIT: The systemd unit (service) that generated the log (e.g., sshd.service).</para></listitem>
69-
<listitem><para>_BOOT_ID: A unique identifier for the specific system boot session.</para></listitem>
70-
</itemizedlist>
71-
</listitem>
72-
<listitem><para>Kernel Fields</para>
73-
<itemizedlist>
74-
<listitem><para>_TRANSPORT: How the message was logged (e.g., kernel, syslog, stdout).</para></listitem>
75-
</itemizedlist>
76-
</listitem><listitem><para>Priority level: A numeric value indicating the severity of the message (0=emerg, 7=debug).</para></listitem>
77-
</itemizedlist>
78-
</listitem>
79-
</itemizedlist>
80-
</section>
30+
default. The service logs the data into the journal described in <xref linkend="journal-what-it-is"/>.
31+
</para>
32+
33+
8134
</topic>

‎concepts/journal-structure.xml‎

Lines changed: 110 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -23,7 +23,7 @@
2323
<meta name="maintainer" content="[email protected]" its:translate="no"/>
2424
<abstract><!-- can be changed via merge in the assembly -->
2525
<para>
26-
Journal is a centralization and unification of logs from all sources, and it stores events in structured manner which in turn helps identifying errors and in crash recovery.
26+
Journal is a centralization and unification of logs from all sources, and it stores events in structured manner which in turn helps identifying errors and in crash recovery.
2727
</para>
2828
</abstract>
2929
</info>
@@ -33,13 +33,119 @@
3333
By default, <literal>journald</literal> stores the collected data in the volatile memory in
3434
<filename>/run/log/journal</filename>, so after reboot the data is lost.
3535
</para>
36+
<para>
37+
If <literal>systemd-journald</literal> is configured to store the logs in a persistent
38+
manner, you can find the journal in <filename>/var/log/journal</filename>. Ensure that the
39+
directoy exists:
40+
</para>
41+
<procedure>
42+
<step>
43+
<para>
44+
Check if the directory exist:
45+
</para>
46+
<screen>&prompt.sudo;<command>ls /var/log</command>
47+
...
48+
journal
49+
...
50+
51+
</screen>
52+
53+
</step>
54+
<step>
55+
<para>If the <filename>/var/log/journal</filename> directory does not exist, create
56+
it:</para>
57+
<screen>&prompt.sudo;<command>mkdir /var/log/journal</command>
58+
</screen>
59+
</step>
60+
<step>
61+
<para>
62+
Set correct ownership and access perimissions:
63+
</para>
64+
<screen>&prompt.sudo; systemd-tmpfiles --create --prefix=/var/log/journal</screen>
65+
</step>
66+
<step performance="optional">
67+
<para>
68+
To flush the data from RAM to the directory:
69+
</para>
70+
<screen>&prompt.sudo; <command>journalctl --flush</command></screen>
71+
</step>
72+
</procedure>
73+
<para>For details about
74+
the service configuration, refer to <xref linkend="journal-configure-journald"/>.
75+
</para>
3676
</section>
3777
<section xml:id="journal-what-it-is-structure">
38-
<title>The structure of the journal</title>
78+
<title>The journal logs structure</title>
3979
<para>
40-
A paragraph of text, answering the question above and explaining the
41-
mechanism behind foo bar.
80+
The logs are stored in binary format across several files. To view the structure of a log
81+
entry, proceed as follows:
4282
</para>
83+
<screen>&prompt.sudo; <command>journalctl -n 1 -o verbose</command>
4384

85+
Fri 2025-12-05 10:52:53.284321 CET [s=5b7ae2e926794210bf832d014f5f560a;i=d49752&gt;
86+
_UID=1000
87+
_AUDIT_SESSION=3
88+
_AUDIT_LOGINUID=1000
89+
_SYSTEMD_OWNER_UID=1000
90+
[email protected]
91+
_SYSTEMD_SLICE=user-1000.slice
92+
_MACHINE_ID=d3489468c8534c5d81a2860cf9a2a20e
93+
_RUNTIME_SCOPE=system
94+
_SELINUX_CONTEXT=unconfined
95+
PRIORITY=6
96+
_TRANSPORT=syslog
97+
_BOOT_ID=d095069bd59b4bc4bf67c8c71999243b
98+
SYSLOG_IDENTIFIER=sudo
99+
SYSLOG_TIMESTAMP=Dec 5 10:52:53
100+
_PID=25806
101+
_COMM=sudo
102+
_EXE=/usr/bin/sudo
103+
_CMDLINE=sudo journalctl -n 1 -o verbose
104+
105+
...
106+
</screen>
107+
<para>The log entry is a data structure containing the log message and metadata fields:</para>
108+
<variablelist>
109+
<varlistentry>
110+
<term>Timestamp</term>
111+
<listitem>
112+
<para>
113+
The exact time the event occured
114+
</para>
115+
</listitem>
116+
</varlistentry>
117+
<varlistentry>
118+
<term>Source Fields</term>
119+
<listitem>
120+
121+
<itemizedlist>
122+
<listitem><para><literal>_PID</literal>: process ID of the sender</para></listitem>
123+
<listitem><para><literal>_UID/_GID</literal>: User/Group ID of the sender</para></listitem>
124+
<listitem><para><literal>_EXE</literal>: path to the executable</para></listitem>
125+
<listitem><para><literal>_COMM</literal>: name of the executable</para></listitem>
126+
</itemizedlist>
127+
</listitem>
128+
</varlistentry>
129+
<varlistentry>
130+
<term>System Fields</term>
131+
<listitem>
132+
<itemizedlist>
133+
<listitem><para><literal>_SYSTEMD_UNIT</literal>: The systemd unit (service) that generated the
134+
log (for example, <literal>sshd.service</literal>)</para></listitem>
135+
<listitem><para><literal>_BOOT_ID</literal>: A unique identifier for the specific system boot session</para></listitem>
136+
</itemizedlist>
137+
</listitem>
138+
</varlistentry>
139+
<varlistentry>
140+
<term>Kernel Fields</term>
141+
<listitem><para><literal>_TRANSPORT</literal>: How the message was logged (e.g., kernel, syslog, stdout).</para></listitem>
142+
</varlistentry>
143+
<varlistentry>
144+
<term>Priority level</term>
145+
<listitem>
146+
<para>A numeric value indicating the severity of the message (0=emerg, 7=debug)</para>
147+
</listitem>
148+
</varlistentry>
149+
</variablelist>
44150
</section>
45151
</topic>

0 commit comments

Comments
 (0)