1SYSTEMD-JOURNALD.SERVICE(8)systemd-journald.serviceSYSTEMD-JOURNALD.SERVICE(8)
2
3
4

NAME

6       systemd-journald.service, systemd-journald.socket, systemd-journald-
7       dev-log.socket, systemd-journald-audit.socket, systemd-
8       journald@.service, systemd-journald@.socket, systemd-journald-
9       varlink@.socket, systemd-journald - Journal service
10

SYNOPSIS

12       systemd-journald.service
13
14       systemd-journald.socket
15
16       systemd-journald-dev-log.socket
17
18       systemd-journald-audit.socket
19
20       systemd-journald@.service
21
22       systemd-journald@.socket
23
24       systemd-journald-varlink@.socket
25
26       /usr/lib/systemd/systemd-journald
27

DESCRIPTION

29       systemd-journald is a system service that collects and stores logging
30       data. It creates and maintains structured, indexed journals based on
31       logging information that is received from a variety of sources:
32
33       •   Kernel log messages, via kmsg
34
35       •   Simple system log messages, via the libc syslog(3) call
36
37       •   Structured system log messages via the native Journal API, see
38           sd_journal_print(3) and Native Journal Protocol[1]
39
40       •   Standard output and standard error of service units. For further
41           details see below.
42
43       •   Audit records, originating from the kernel audit subsystem
44
45       The daemon will implicitly collect numerous metadata fields for each
46       log messages in a secure and unfakeable way. See systemd.journal-
47       fields(7) for more information about the collected metadata.
48
49       Log data collected by the journal is primarily text-based but can also
50       include binary data where necessary. Individual fields making up a log
51       record stored in the journal may be up to 2⁶⁴-1 bytes in size.
52
53       The journal service stores log data either persistently below
54       /var/log/journal or in a volatile way below /run/log/journal/ (in the
55       latter case it is lost at reboot). By default, log data is stored
56       persistently if /var/log/journal/ exists during boot, with an implicit
57       fallback to volatile storage otherwise. Use Storage= in
58       journald.conf(5) to configure where log data is placed, independently
59       of the existence of /var/log/journal/.
60
61       Note that journald will initially use volatile storage, until a call to
62       journalctl --flush (or sending SIGUSR1 to journald) will cause it to
63       switch to persistent logging (under the conditions mentioned above).
64       This is done automatically on boot via "systemd-journal-flush.service".
65
66       On systems where /var/log/journal/ does not exist yet but where
67       persistent logging is desired (and the default journald.conf is used),
68       it is sufficient to create the directory, and ensure it has the correct
69       access modes and ownership:
70
71           mkdir -p /var/log/journal
72           systemd-tmpfiles --create --prefix /var/log/journal
73
74       See journald.conf(5) for information about the configuration of this
75       service.
76

STREAM LOGGING

78       The systemd service manager invokes all service processes with standard
79       output and standard error connected to the journal by default. This
80       behaviour may be altered via the StandardOutput=/StandardError= unit
81       file settings, see systemd.exec(5) for details. The journal converts
82       the log byte stream received this way into individual log records,
83       splitting the stream at newline ("\n", ASCII 10) and NUL bytes.
84
85       If systemd-journald.service is stopped, the stream connections
86       associated with all services are terminated. Further writes to those
87       streams by the service will result in EPIPE errors. In order to react
88       gracefully in this case it is recommended that programs logging to
89       standard output/error ignore such errors. If the SIGPIPE UNIX signal
90       handler is not blocked or turned off, such write attempts will also
91       result in such process signals being generated, see signal(7). To
92       mitigate this issue, systemd service manager explicitly turns off the
93       SIGPIPE signal for all invoked processes by default (this may be
94       changed for each unit individually via the IgnoreSIGPIPE= option, see
95       systemd.exec(5) for details). After the standard output/standard error
96       streams have been terminated they may not be recovered until the
97       services they are associated with are restarted. Note that during
98       normal operation, systemd-journald.service stores copies of the file
99       descriptors for those streams in the service manager. If
100       systemd-journald.service is restarted using systemctl restart or
101       equivalent operation instead of a pair of separate systemctl stop and
102       systemctl start commands (or equivalent operations), these stream
103       connections are not terminated and survive the restart. It is thus safe
104       to restart systemd-journald.service, but stopping it is not
105       recommended.
106
107       Note that the log record metadata for records transferred via such
108       standard output/error streams reflect the metadata of the peer the
109       stream was originally created for. If the stream connection is passed
110       on to other processes (such as further child processes forked off the
111       main service process), the log records will not reflect their metadata,
112       but will continue to describe the original process. This is different
113       from the other logging transports listed above, which are inherently
114       record based and where the metadata is always associated with the
115       individual record.
116
117       In addition to the implicit standard output/error logging of services,
118       stream logging is also available via the systemd-cat(1) command line
119       tool.
120
121       Currently, the number of parallel log streams systemd-journald will
122       accept is limited to 4096. When this limit is reached further log
123       streams may be established but will receive EPIPE right from the
124       beginning.
125

JOURNAL NAMESPACES

127       Journal 'namespaces' are both a mechanism for logically isolating the
128       log stream of projects consisting of one or more services from the rest
129       of the system and a mechanism for improving performance. Multiple
130       journal namespaces may exist simultaneously, each defining its own,
131       independent log stream managed by its own instance of systemd-journald.
132       Namespaces are independent of each other, both in the data store and in
133       the IPC interface. By default only a single 'default' namespace exists,
134       managed by systemd-journald.service (and its associated socket units).
135       Additional namespaces are created by starting an instance of the
136       systemd-journald@.service service template. The instance name is the
137       namespace identifier, which is a short string used for referencing the
138       journal namespace. Service units may be assigned to a specific journal
139       namespace through the LogNamespace= unit file setting, see
140       systemd.exec(5) for details. The --namespace= switch of journalctl(1)
141       may be used to view the log stream of a specific namespace. If the
142       switch is not used the log stream of the default namespace is shown,
143       i.e. log data from other namespaces is not visible.
144
145       Services associated with a specific log namespace may log via syslog,
146       the native logging protocol of the journal and via stdout/stderr; the
147       logging from all three transports is associated with the namespace.
148
149       By default only the default namespace will collect kernel and audit log
150       messages.
151
152       The systemd-journald instance of the default namespace is configured
153       through /etc/systemd/journald.conf (see below), while the other
154       instances are configured through /etc/systemd/journald@NAMESPACE.conf.
155       The journal log data for the default namespace is placed in
156       /var/log/journal/MACHINE_ID (see below) while the data for the other
157       namespaces is located in /var/log/journal/MACHINE_ID.NAMESPACE.
158

SIGNALS

160       SIGUSR1
161           Request that journal data from /run/ is flushed to /var/ in order
162           to make it persistent (if this is enabled). This must be used after
163           /var/ is mounted, as otherwise log data from /run/ is never flushed
164           to /var/ regardless of the configuration. Use the journalctl
165           --flush command to request flushing of the journal files, and wait
166           for the operation to complete. See journalctl(1) for details.
167
168       SIGUSR2
169           Request immediate rotation of the journal files. Use the journalctl
170           --rotate command to request journal file rotation, and wait for the
171           operation to complete.
172
173       SIGRTMIN+1
174           Request that all unwritten log data is written to disk. Use the
175           journalctl --sync command to trigger journal synchronization, and
176           wait for the operation to complete.
177

KERNEL COMMAND LINE

179       A few configuration parameters from journald.conf may be overridden on
180       the kernel command line:
181
182       systemd.journald.forward_to_syslog=, systemd.journald.forward_to_kmsg=,
183       systemd.journald.forward_to_console=, systemd.journald.forward_to_wall=
184           Enables/disables forwarding of collected log messages to syslog,
185           the kernel log buffer, the system console or wall.
186
187           See journald.conf(5) for information about these settings.
188
189       Note that these kernel command line options are only honoured by the
190       default namespace, see above.
191

ACCESS CONTROL

193       Journal files are, by default, owned and readable by the
194       "systemd-journal" system group but are not writable. Adding a user to
195       this group thus enables them to read the journal files.
196
197       By default, each user, with a UID outside the range of system users,
198       dynamic service users, and the nobody user, will get their own set of
199       journal files in /var/log/journal/. See Users, Groups, UIDs and GIDs on
200       systemd systems[2] for more details about UID ranges. These journal
201       files will not be owned by the user, however, in order to avoid that
202       the user can write to them directly. Instead, file system ACLs are used
203       to ensure the user gets read access only.
204
205       Additional users and groups may be granted access to journal files via
206       file system access control lists (ACL). Distributions and
207       administrators may choose to grant read access to all members of the
208       "wheel" and "adm" system groups with a command such as the following:
209
210           # setfacl -Rnm g:wheel:rx,d:g:wheel:rx,g:adm:rx,d:g:adm:rx /var/log/journal/
211
212       Note that this command will update the ACLs both for existing journal
213       files and for future journal files created in the /var/log/journal/
214       directory.
215

FILES

217       /etc/systemd/journald.conf
218           Configure systemd-journald behavior. See journald.conf(5).
219
220       /run/log/journal/machine-id/*.journal,
221       /run/log/journal/machine-id/*.journal~,
222       /var/log/journal/machine-id/*.journal,
223       /var/log/journal/machine-id/*.journal~
224           systemd-journald writes entries to files in
225           /run/log/journal/machine-id/ or /var/log/journal/machine-id/ with
226           the ".journal" suffix. If the daemon is stopped uncleanly, or if
227           the files are found to be corrupted, they are renamed using the
228           ".journal~" suffix, and systemd-journald starts writing to a new
229           file.  /run/ is used when /var/log/journal is not available, or
230           when Storage=volatile is set in the journald.conf(5) configuration
231           file.
232
233           When systemd-journald ceases writing to a journal file, it will be
234           renamed to "original-name@suffix.journal" (or
235           "original-name@suffix.journal~"). Such files are "archived" and
236           will not be written to any more.
237
238           In general, it is safe to read or copy any journal file (active or
239           archived).  journalctl(1) and the functions in the sd-journal(3)
240           library should be able to read all entries that have been fully
241           written.
242
243           systemd-journald will automatically remove the oldest archived
244           journal files to limit disk use. See SystemMaxUse= and related
245           settings in journald.conf(5).
246
247       /dev/kmsg, /dev/log, /run/systemd/journal/dev-log,
248       /run/systemd/journal/socket, /run/systemd/journal/stdout
249           Sockets and other file node paths that systemd-journald will listen
250           on and are visible in the file system. In addition to these,
251           systemd-journald can listen for audit events using netlink(7),
252           depending on whether "systemd-journald-audit.socket" is enabled or
253           not.
254
255       If journal namespacing is used these paths are slightly altered to
256       include a namespace identifier, see above.
257

SEE ALSO

259       systemd(1), journalctl(1), journald.conf(5), systemd.journal-fields(7),
260       sd-journal(3), systemd-coredump(8), setfacl(1), sd_journal_print(3),
261       pydoc systemd.journal
262

NOTES

264        1. Native Journal Protocol
265           https://systemd.io/JOURNAL_NATIVE_PROTOCOL
266
267        2. Users, Groups, UIDs and GIDs on systemd systems
268           https://systemd.io/UIDS-GIDS
269
270
271
272systemd 254                                        SYSTEMD-JOURNALD.SERVICE(8)
Impressum