]> git.ipfire.org Git - thirdparty/systemd.git/blob - man/systemd-journald.service.xml
man: rework the discussion of Storage= a bit
[thirdparty/systemd.git] / man / systemd-journald.service.xml
1 <?xml version='1.0'?> <!--*-nxml-*-->
2 <!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
3 "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
4
5 <!--
6 This file is part of systemd.
7
8 Copyright 2010 Lennart Poettering
9
10 systemd is free software; you can redistribute it and/or modify it
11 under the terms of the GNU Lesser General Public License as published by
12 the Free Software Foundation; either version 2.1 of the License, or
13 (at your option) any later version.
14
15 systemd is distributed in the hope that it will be useful, but
16 WITHOUT ANY WARRANTY; without even the implied warranty of
17 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
18 Lesser General Public License for more details.
19
20 You should have received a copy of the GNU Lesser General Public License
21 along with systemd; If not, see <http://www.gnu.org/licenses/>.
22 -->
23
24 <refentry id="systemd-journald.service">
25
26 <refentryinfo>
27 <title>systemd-journald.service</title>
28 <productname>systemd</productname>
29
30 <authorgroup>
31 <author>
32 <contrib>Developer</contrib>
33 <firstname>Lennart</firstname>
34 <surname>Poettering</surname>
35 <email>lennart@poettering.net</email>
36 </author>
37 </authorgroup>
38 </refentryinfo>
39
40 <refmeta>
41 <refentrytitle>systemd-journald.service</refentrytitle>
42 <manvolnum>8</manvolnum>
43 </refmeta>
44
45 <refnamediv>
46 <refname>systemd-journald.service</refname>
47 <refname>systemd-journald.socket</refname>
48 <refname>systemd-journald-dev-log.socket</refname>
49 <refname>systemd-journald-audit.socket</refname>
50 <refname>systemd-journald</refname>
51 <refpurpose>Journal service</refpurpose>
52 </refnamediv>
53
54 <refsynopsisdiv>
55 <para><filename>systemd-journald.service</filename></para>
56 <para><filename>systemd-journald.socket</filename></para>
57 <para><filename>systemd-journald-dev-log.socket</filename></para>
58 <para><filename>systemd-journald-audit.socket</filename></para>
59 <para><filename>/usr/lib/systemd/systemd-journald</filename></para>
60 </refsynopsisdiv>
61
62 <refsect1>
63 <title>Description</title>
64
65 <para><filename>systemd-journald</filename> is a system service
66 that collects and stores logging data. It creates and maintains
67 structured, indexed journals based on logging information that is
68 received from a variety of sources:</para>
69
70 <itemizedlist>
71 <listitem><para>Kernel log messages, via kmsg</para></listitem>
72
73 <listitem><para>Simple system log messages, via the <filename>libc</filename> <citerefentry
74 project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>
75 call</para></listitem>
76
77 <listitem><para>Structured system log messages via the native
78 Journal API, see
79 <citerefentry><refentrytitle>sd_journal_print</refentrytitle><manvolnum>4</manvolnum></citerefentry></para></listitem>
80
81 <listitem><para>Standard output and standard error of service units. For further details see
82 below.</para></listitem>
83
84 <listitem><para>Audit records, originating from the kernel audit subsystem</para></listitem>
85 </itemizedlist>
86
87 <para>The daemon will implicitly collect numerous metadata fields
88 for each log messages in a secure and unfakeable way. See
89 <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry>
90 for more information about the collected metadata.
91 </para>
92
93 <para>Log data collected by the journal is primarily text-based but can also include binary data where
94 necessary. Individual fields making up a log record stored in the journal may be up to 2^64-1 bytes in size.</para>
95
96 <para>The journal service stores log data either persistently below <filename>/var/log/journal</filename> or in a
97 volatile way below <filename>/run/log/journal/</filename> (in the latter case it is lost at reboot). By default, log
98 data is stored persistently if <filename>/var/log/journal/</filename> exists during boot, with an implicit fallback
99 to volatile storage otherwise. Use <varname>Storage=</varname> in
100 <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> to configure
101 where log data is placed, independently of the existence of <filename>/var/log/journal/</filename>.</para>
102
103 <para>On systems where <filename>/var/log/journal/</filename> does not exist yet but where persistent logging is
104 desired (and the default <filename>journald.conf</filename> is used), it is sufficient to create the directory, and
105 ensure it has the correct access modes and ownership:</para>
106
107 <programlisting>mkdir -p /var/log/journal
108 systemd-tmpfiles --create --prefix /var/log/journal</programlisting>
109
110 <para>See
111 <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
112 for information about the configuration of this service.</para>
113 </refsect1>
114
115 <refsect1>
116 <title>Stream logging</title>
117
118 <para>The systemd service manager invokes all service processes with standard output and standard error connected
119 to the journal by default. This behaviour may be altered via the
120 <varname>StandardOutput=</varname>/<varname>StandardError=</varname> unit file settings, see
121 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for details. The
122 journal converts the log byte stream received this way into individual log records, splitting the stream at newline
123 (<literal>\n</literal>, ASCII <constant>10</constant>) and <constant>NUL</constant> bytes.</para>
124
125 <para>If <filename>systemd-journald.service</filename> is stopped, the stream connections associated with all
126 services are terminated. Further writes to those streams by the service will result in <constant>EPIPE</constant>
127 errors. In order to react gracefully in this case it is recommended that programs logging to standard output/error
128 ignore such errors. If the <constant>SIGPIPE</constant> UNIX signal handler is not blocked or turned off, such
129 write attempts will also result in such process signals being generated, see
130 <citerefentry><refentrytitle>signal</refentrytitle><manvolnum>7</manvolnum></citerefentry>. To mitigate this issue,
131 systemd service manager explicitly turns off the <constant>SIGPIPE</constant> signal for all invoked processes by
132 default (this may be changed for each unit individually via the <varname>IgnoreSIGPIPE=</varname> option, see
133 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
134 details). After the standard output/standard error streams have been terminated they may not be recovered until the
135 services they are associated with are restarted. Note that during normal operation,
136 <filename>systemd-journald.service</filename> stores copies of the file descriptors for those streams in the
137 service manager. If <filename>systemd-journald.service</filename> is restarted using <command>systemctl
138 restart</command> or equivalent operation instead of a pair of separate <command>systemctl stop</command> and
139 <command>systemctl start</command> commands (or equivalent operations), these stream connections are not terminated
140 and survive the restart. It is thus safe to restart <filename>systemd-journald.service</filename>, but stopping it
141 is not recommended.</para>
142
143 <para>Note that the log record metadata for records transferred via such standard output/error streams reflect the
144 metadata of the peer the stream was originally created for. If the stream connection is passed on to other
145 processes (such as further child processes forked off the main service process), the log records will not reflect
146 their metadata, but will continue to describe the original process. This is different from the other logging
147 transports listed above, which are inherently record based and where the metadata is always associated with the
148 individual record.</para>
149
150 <para>In addition to the implicit standard output/error logging of services, stream logging is also available
151 via the <citerefentry><refentrytitle>systemd-cat</refentrytitle><manvolnum>1</manvolnum></citerefentry> command
152 line tool.</para>
153
154 <para>Currently, the number of parallel log streams <filename>systemd-journald</filename> will accept is limited to
155 4096. When this limit is reached further log streams may be established but will receive
156 <constant>EPIPE</constant> right from the beginning.</para>
157 </refsect1>
158
159 <refsect1>
160 <title>Signals</title>
161
162 <variablelist>
163 <varlistentry>
164 <term>SIGUSR1</term>
165
166 <listitem><para>Request that journal data from
167 <filename>/run/</filename> is flushed to
168 <filename>/var/</filename> in order to make it persistent (if
169 this is enabled). This must be used after
170 <filename>/var/</filename> is mounted, as otherwise log data
171 from <filename>/run</filename> is never flushed to
172 <filename>/var</filename> regardless of the configuration. The
173 <command>journalctl --flush</command> command uses this signal
174 to request flushing of the journal files, and then waits for
175 the operation to complete. See
176 <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
177 for details.</para></listitem>
178 </varlistentry>
179
180 <varlistentry>
181 <term>SIGUSR2</term>
182
183 <listitem><para>Request immediate rotation of the journal
184 files. The <command>journalctl --rotate</command> command uses
185 this signal to request journal file
186 rotation.</para></listitem>
187 </varlistentry>
188
189 <varlistentry>
190 <term>SIGRTMIN+1</term>
191
192 <listitem><para>Request that all unwritten log data is written
193 to disk. The <command>journalctl --sync</command> command uses
194 this signal to trigger journal synchronization, and then waits
195 for the operation to complete.</para></listitem>
196 </varlistentry>
197 </variablelist>
198 </refsect1>
199
200 <refsect1>
201 <title>Kernel Command Line</title>
202
203 <para>A few configuration parameters from
204 <filename>journald.conf</filename> may be overridden on the kernel
205 command line:</para>
206
207 <variablelist class='kernel-commandline-options'>
208 <varlistentry>
209 <term><varname>systemd.journald.forward_to_syslog=</varname></term>
210 <term><varname>systemd.journald.forward_to_kmsg=</varname></term>
211 <term><varname>systemd.journald.forward_to_console=</varname></term>
212 <term><varname>systemd.journald.forward_to_wall=</varname></term>
213
214 <listitem><para>Enables/disables forwarding of collected log
215 messages to syslog, the kernel log buffer, the system console
216 or wall.
217 </para>
218
219 <para>See
220 <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
221 for information about these settings.</para>
222 </listitem>
223
224 </varlistentry>
225 </variablelist>
226 </refsect1>
227
228 <refsect1>
229 <title>Access Control</title>
230
231 <para>Journal files are, by default, owned and readable by the
232 <literal>systemd-journal</literal> system group but are not
233 writable. Adding a user to this group thus enables her/him to read
234 the journal files.</para>
235
236 <para>By default, each logged in user will get her/his own set of
237 journal files in <filename>/var/log/journal/</filename>. These
238 files will not be owned by the user, however, in order to avoid
239 that the user can write to them directly. Instead, file system
240 ACLs are used to ensure the user gets read access only.</para>
241
242 <para>Additional users and groups may be granted access to journal
243 files via file system access control lists (ACL). Distributions
244 and administrators may choose to grant read access to all members
245 of the <literal>wheel</literal> and <literal>adm</literal> system
246 groups with a command such as the following:</para>
247
248 <programlisting># setfacl -Rnm g:wheel:rx,d:g:wheel:rx,g:adm:rx,d:g:adm:rx /var/log/journal/</programlisting>
249
250 <para>Note that this command will update the ACLs both for
251 existing journal files and for future journal files created in the
252 <filename>/var/log/journal/</filename> directory.</para>
253 </refsect1>
254
255 <refsect1>
256 <title>Files</title>
257
258 <variablelist>
259 <varlistentry>
260 <term><filename>/etc/systemd/journald.conf</filename></term>
261
262 <listitem><para>Configure
263 <command>systemd-journald</command>
264 behavior. See
265 <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
266 </para></listitem>
267 </varlistentry>
268
269 <varlistentry>
270 <term><filename>/run/log/journal/<replaceable>machine-id</replaceable>/*.journal</filename></term>
271 <term><filename>/run/log/journal/<replaceable>machine-id</replaceable>/*.journal~</filename></term>
272 <term><filename>/var/log/journal/<replaceable>machine-id</replaceable>/*.journal</filename></term>
273 <term><filename>/var/log/journal/<replaceable>machine-id</replaceable>/*.journal~</filename></term>
274
275 <listitem><para><command>systemd-journald</command> writes
276 entries to files in
277 <filename>/run/log/journal/<replaceable>machine-id</replaceable>/</filename>
278 or
279 <filename>/var/log/journal/<replaceable>machine-id</replaceable>/</filename>
280 with the <literal>.journal</literal> suffix. If the daemon is
281 stopped uncleanly, or if the files are found to be corrupted,
282 they are renamed using the <literal>.journal~</literal>
283 suffix, and <command>systemd-journald</command> starts writing
284 to a new file. <filename>/run</filename> is used when
285 <filename>/var/log/journal</filename> is not available, or
286 when <option>Storage=volatile</option> is set in the
287 <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
288 configuration file.</para></listitem>
289 </varlistentry>
290
291 <varlistentry>
292 <term><filename>/dev/kmsg</filename></term>
293 <term><filename>/dev/log</filename></term>
294 <term><filename>/run/systemd/journal/dev-log</filename></term>
295 <term><filename>/run/systemd/journal/socket</filename></term>
296 <term><filename>/run/systemd/journal/stdout</filename></term>
297
298 <listitem><para>Sockets and other paths that
299 <command>systemd-journald</command> will listen on that are
300 visible in the file system. In addition to these, journald can
301 listen for audit events using netlink.</para></listitem>
302 </varlistentry>
303 </variablelist>
304 </refsect1>
305
306 <refsect1>
307 <title>See Also</title>
308 <para>
309 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
310 <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
311 <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
312 <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
313 <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
314 <citerefentry><refentrytitle>systemd-coredump</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
315 <citerefentry project='die-net'><refentrytitle>setfacl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
316 <citerefentry><refentrytitle>sd_journal_print</refentrytitle><manvolnum>4</manvolnum></citerefentry>,
317 <command>pydoc systemd.journal</command>
318 </para>
319 </refsect1>
320
321 </refentry>