| <?xml version='1.0'?> <!--*-nxml-*--> |
| <!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" |
| "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> |
| |
| <!-- |
| SPDX-License-Identifier: LGPL-2.1+ |
| --> |
| |
| <refentry id="systemd-journald.service"> |
| |
| <refentryinfo> |
| <title>systemd-journald.service</title> |
| <productname>systemd</productname> |
| </refentryinfo> |
| |
| <refmeta> |
| <refentrytitle>systemd-journald.service</refentrytitle> |
| <manvolnum>8</manvolnum> |
| </refmeta> |
| |
| <refnamediv> |
| <refname>systemd-journald.service</refname> |
| <refname>systemd-journald.socket</refname> |
| <refname>systemd-journald-dev-log.socket</refname> |
| <refname>systemd-journald-audit.socket</refname> |
| <refname>systemd-journald</refname> |
| <refpurpose>Journal service</refpurpose> |
| </refnamediv> |
| |
| <refsynopsisdiv> |
| <para><filename>systemd-journald.service</filename></para> |
| <para><filename>systemd-journald.socket</filename></para> |
| <para><filename>systemd-journald-dev-log.socket</filename></para> |
| <para><filename>systemd-journald-audit.socket</filename></para> |
| <para><filename>/usr/lib/systemd/systemd-journald</filename></para> |
| </refsynopsisdiv> |
| |
| <refsect1> |
| <title>Description</title> |
| |
| <para><filename>systemd-journald</filename> is a system service |
| that collects and stores logging data. It creates and maintains |
| structured, indexed journals based on logging information that is |
| received from a variety of sources:</para> |
| |
| <itemizedlist> |
| <listitem><para>Kernel log messages, via kmsg</para></listitem> |
| |
| <listitem><para>Simple system log messages, via the <filename>libc</filename> <citerefentry |
| project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry> |
| call</para></listitem> |
| |
| <listitem><para>Structured system log messages via the native |
| Journal API, see |
| <citerefentry><refentrytitle>sd_journal_print</refentrytitle><manvolnum>4</manvolnum></citerefentry></para></listitem> |
| |
| <listitem><para>Standard output and standard error of service units. For further details see |
| below.</para></listitem> |
| |
| <listitem><para>Audit records, originating from the kernel audit subsystem</para></listitem> |
| </itemizedlist> |
| |
| <para>The daemon will implicitly collect numerous metadata fields |
| for each log messages in a secure and unfakeable way. See |
| <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry> |
| for more information about the collected metadata. |
| </para> |
| |
| <para>Log data collected by the journal is primarily text-based but can also include binary data where |
| necessary. Individual fields making up a log record stored in the journal may be up to 2^64-1 bytes in size.</para> |
| |
| <para>The journal service stores log data either persistently below <filename>/var/log/journal</filename> or in a |
| volatile way below <filename>/run/log/journal/</filename> (in the latter case it is lost at reboot). By default, log |
| data is stored persistently if <filename>/var/log/journal/</filename> exists during boot, with an implicit fallback |
| to volatile storage otherwise. Use <varname>Storage=</varname> in |
| <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> to configure |
| where log data is placed, independently of the existence of <filename>/var/log/journal/</filename>.</para> |
| |
| <para>On systems where <filename>/var/log/journal/</filename> does not exist yet but where persistent logging is |
| desired (and the default <filename>journald.conf</filename> is used), it is sufficient to create the directory, and |
| ensure it has the correct access modes and ownership:</para> |
| |
| <programlisting>mkdir -p /var/log/journal |
| systemd-tmpfiles --create --prefix /var/log/journal</programlisting> |
| |
| <para>See |
| <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> |
| for information about the configuration of this service.</para> |
| </refsect1> |
| |
| <refsect1> |
| <title>Stream logging</title> |
| |
| <para>The systemd service manager invokes all service processes with standard output and standard error connected |
| to the journal by default. This behaviour may be altered via the |
| <varname>StandardOutput=</varname>/<varname>StandardError=</varname> unit file settings, see |
| <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for details. The |
| journal converts the log byte stream received this way into individual log records, splitting the stream at newline |
| (<literal>\n</literal>, ASCII <constant>10</constant>) and <constant>NUL</constant> bytes.</para> |
| |
| <para>If <filename>systemd-journald.service</filename> is stopped, the stream connections associated with all |
| services are terminated. Further writes to those streams by the service will result in <constant>EPIPE</constant> |
| errors. In order to react gracefully in this case it is recommended that programs logging to standard output/error |
| ignore such errors. If the <constant>SIGPIPE</constant> UNIX signal handler is not blocked or turned off, such |
| write attempts will also result in such process signals being generated, see |
| <citerefentry><refentrytitle>signal</refentrytitle><manvolnum>7</manvolnum></citerefentry>. To mitigate this issue, |
| systemd service manager explicitly turns off the <constant>SIGPIPE</constant> signal for all invoked processes by |
| default (this may be changed for each unit individually via the <varname>IgnoreSIGPIPE=</varname> option, see |
| <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for |
| details). After the standard output/standard error streams have been terminated they may not be recovered until the |
| services they are associated with are restarted. Note that during normal operation, |
| <filename>systemd-journald.service</filename> stores copies of the file descriptors for those streams in the |
| service manager. If <filename>systemd-journald.service</filename> is restarted using <command>systemctl |
| restart</command> or equivalent operation instead of a pair of separate <command>systemctl stop</command> and |
| <command>systemctl start</command> commands (or equivalent operations), these stream connections are not terminated |
| and survive the restart. It is thus safe to restart <filename>systemd-journald.service</filename>, but stopping it |
| is not recommended.</para> |
| |
| <para>Note that the log record metadata for records transferred via such standard output/error streams reflect the |
| metadata of the peer the stream was originally created for. If the stream connection is passed on to other |
| processes (such as further child processes forked off the main service process), the log records will not reflect |
| their metadata, but will continue to describe the original process. This is different from the other logging |
| transports listed above, which are inherently record based and where the metadata is always associated with the |
| individual record.</para> |
| |
| <para>In addition to the implicit standard output/error logging of services, stream logging is also available |
| via the <citerefentry><refentrytitle>systemd-cat</refentrytitle><manvolnum>1</manvolnum></citerefentry> command |
| line tool.</para> |
| |
| <para>Currently, the number of parallel log streams <filename>systemd-journald</filename> will accept is limited to |
| 4096. When this limit is reached further log streams may be established but will receive |
| <constant>EPIPE</constant> right from the beginning.</para> |
| </refsect1> |
| |
| <refsect1> |
| <title>Signals</title> |
| |
| <variablelist> |
| <varlistentry> |
| <term>SIGUSR1</term> |
| |
| <listitem><para>Request that journal data from |
| <filename>/run/</filename> is flushed to |
| <filename>/var/</filename> in order to make it persistent (if |
| this is enabled). This must be used after |
| <filename>/var/</filename> is mounted, as otherwise log data |
| from <filename>/run</filename> is never flushed to |
| <filename>/var</filename> regardless of the configuration. The |
| <command>journalctl --flush</command> command uses this signal |
| to request flushing of the journal files, and then waits for |
| the operation to complete. See |
| <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> |
| for details.</para></listitem> |
| </varlistentry> |
| |
| <varlistentry> |
| <term>SIGUSR2</term> |
| |
| <listitem><para>Request immediate rotation of the journal |
| files. The <command>journalctl --rotate</command> command uses |
| this signal to request journal file |
| rotation.</para></listitem> |
| </varlistentry> |
| |
| <varlistentry> |
| <term>SIGRTMIN+1</term> |
| |
| <listitem><para>Request that all unwritten log data is written |
| to disk. The <command>journalctl --sync</command> command uses |
| this signal to trigger journal synchronization, and then waits |
| for the operation to complete.</para></listitem> |
| </varlistentry> |
| </variablelist> |
| </refsect1> |
| |
| <refsect1> |
| <title>Kernel Command Line</title> |
| |
| <para>A few configuration parameters from |
| <filename>journald.conf</filename> may be overridden on the kernel |
| command line:</para> |
| |
| <variablelist class='kernel-commandline-options'> |
| <varlistentry> |
| <term><varname>systemd.journald.forward_to_syslog=</varname></term> |
| <term><varname>systemd.journald.forward_to_kmsg=</varname></term> |
| <term><varname>systemd.journald.forward_to_console=</varname></term> |
| <term><varname>systemd.journald.forward_to_wall=</varname></term> |
| |
| <listitem><para>Enables/disables forwarding of collected log |
| messages to syslog, the kernel log buffer, the system console |
| or wall. |
| </para> |
| |
| <para>See |
| <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> |
| for information about these settings.</para> |
| </listitem> |
| |
| </varlistentry> |
| </variablelist> |
| </refsect1> |
| |
| <refsect1> |
| <title>Access Control</title> |
| |
| <para>Journal files are, by default, owned and readable by the |
| <literal>systemd-journal</literal> system group but are not |
| writable. Adding a user to this group thus enables her/him to read |
| the journal files.</para> |
| |
| <para>By default, each logged in user will get her/his own set of |
| journal files in <filename>/var/log/journal/</filename>. These |
| files will not be owned by the user, however, in order to avoid |
| that the user can write to them directly. Instead, file system |
| ACLs are used to ensure the user gets read access only.</para> |
| |
| <para>Additional users and groups may be granted access to journal |
| files via file system access control lists (ACL). Distributions |
| and administrators may choose to grant read access to all members |
| of the <literal>wheel</literal> and <literal>adm</literal> system |
| groups with a command such as the following:</para> |
| |
| <programlisting># setfacl -Rnm g:wheel:rx,d:g:wheel:rx,g:adm:rx,d:g:adm:rx /var/log/journal/</programlisting> |
| |
| <para>Note that this command will update the ACLs both for |
| existing journal files and for future journal files created in the |
| <filename>/var/log/journal/</filename> directory.</para> |
| </refsect1> |
| |
| <refsect1> |
| <title>Files</title> |
| |
| <variablelist> |
| <varlistentry> |
| <term><filename>/etc/systemd/journald.conf</filename></term> |
| |
| <listitem><para>Configure <command>systemd-journald</command> behavior. See |
| <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>. |
| </para></listitem> |
| </varlistentry> |
| |
| <varlistentry> |
| <term><filename>/run/log/journal/<replaceable>machine-id</replaceable>/*.journal</filename></term> |
| <term><filename>/run/log/journal/<replaceable>machine-id</replaceable>/*.journal~</filename></term> |
| <term><filename>/var/log/journal/<replaceable>machine-id</replaceable>/*.journal</filename></term> |
| <term><filename>/var/log/journal/<replaceable>machine-id</replaceable>/*.journal~</filename></term> |
| |
| <listitem><para><command>systemd-journald</command> writes entries to files in |
| <filename>/run/log/journal/<replaceable>machine-id</replaceable>/</filename> |
| or |
| <filename>/var/log/journal/<replaceable>machine-id</replaceable>/</filename> |
| with the <literal>.journal</literal> suffix. If the daemon is |
| stopped uncleanly, or if the files are found to be corrupted, |
| they are renamed using the <literal>.journal~</literal> |
| suffix, and <command>systemd-journald</command> starts writing |
| to a new file. <filename>/run</filename> is used when |
| <filename>/var/log/journal</filename> is not available, or |
| when <option>Storage=volatile</option> is set in the |
| <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> |
| configuration file.</para> |
| |
| <para>When <filename>systemd-journald</filename> ceases writing to a journal file, |
| it will be renamed to <literal><replaceable>original-name</replaceable>@<replaceable>suffix.journal</replaceable></literal> |
| (or <literal><replaceable>original-name</replaceable>@<replaceable>suffix.journal~</replaceable></literal>). |
| Such files are "archived" and will not be written to any more.</para> |
| |
| <para>In general, it is safe to read or copy any journal file (active or archived). |
| <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> |
| and the functions in the |
| <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry> |
| library should be able to read all entries that have been fully written.</para> |
| |
| <para><filename>systemd-journald</filename> will automatically remove the oldest |
| archived journal files to limit disk use. See <varname>SystemMaxUse=</varname> |
| and related settings in |
| <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>. |
| </para></listitem> |
| </varlistentry> |
| |
| <varlistentry> |
| <term><filename>/dev/kmsg</filename></term> |
| <term><filename>/dev/log</filename></term> |
| <term><filename>/run/systemd/journal/dev-log</filename></term> |
| <term><filename>/run/systemd/journal/socket</filename></term> |
| <term><filename>/run/systemd/journal/stdout</filename></term> |
| |
| <listitem><para>Sockets and other paths that |
| <command>systemd-journald</command> will listen on that are |
| visible in the file system. In addition to these, journald can |
| listen for audit events using netlink.</para></listitem> |
| </varlistentry> |
| </variablelist> |
| </refsect1> |
| |
| <refsect1> |
| <title>See Also</title> |
| <para> |
| <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, |
| <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, |
| <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, |
| <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry>, |
| <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, |
| <citerefentry><refentrytitle>systemd-coredump</refentrytitle><manvolnum>8</manvolnum></citerefentry>, |
| <citerefentry project='die-net'><refentrytitle>setfacl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, |
| <citerefentry><refentrytitle>sd_journal_print</refentrytitle><manvolnum>4</manvolnum></citerefentry>, |
| <command>pydoc systemd.journal</command> |
| </para> |
| </refsect1> |
| |
| </refentry> |