{
    "mode": "man",
    "parameter": "systemd-journald.socket",
    "section": "8",
    "url": "https://www.chedong.com/phpMan.php/man/systemd-journald.socket/8/json",
    "generated": "2026-05-30T15:36:42Z",
    "synopsis": "systemd-journald.service\nsystemd-journald.socket\nsystemd-journald-dev-log.socket\nsystemd-journald-audit.socket\nsystemd-journald@.service\nsystemd-journald@.socket\nsystemd-journald-varlink@.socket\n/lib/systemd/systemd-journald",
    "sections": {
        "NAME": {
            "content": "systemd-journald.service, systemd-journald.socket, systemd-journald-dev-log.socket, systemd-\njournald-audit.socket, systemd-journald@.service, systemd-journald@.socket, systemd-journald-\nvarlink@.socket, systemd-journald - Journal service\n",
            "subsections": []
        },
        "SYNOPSIS": {
            "content": "systemd-journald.service\n\nsystemd-journald.socket\n\nsystemd-journald-dev-log.socket\n\nsystemd-journald-audit.socket\n\nsystemd-journald@.service\n\nsystemd-journald@.socket\n\nsystemd-journald-varlink@.socket\n\n/lib/systemd/systemd-journald\n",
            "subsections": []
        },
        "DESCRIPTION": {
            "content": "systemd-journald is a system service that collects and stores logging data. It creates and\nmaintains structured, indexed journals based on logging information that is received from a\nvariety of sources:\n\n•   Kernel log messages, via kmsg\n\n•   Simple system log messages, via the libc syslog(3) call\n\n•   Structured system log messages via the native Journal API, see sdjournalprint(3) and\nNative Journal Protocol[1]\n\n•   Standard output and standard error of service units. For further details see below.\n\n•   Audit records, originating from the kernel audit subsystem\n\nThe daemon will implicitly collect numerous metadata fields for each log messages in a secure\nand unfakeable way. See systemd.journal-fields(7) for more information about the collected\nmetadata.\n\nLog data collected by the journal is primarily text-based but can also include binary data\nwhere necessary. Individual fields making up a log record stored in the journal may be up to\n2^64-1 bytes in size.\n\nThe journal service stores log data either persistently below /var/log/journal or in a\nvolatile way below /run/log/journal/ (in the latter case it is lost at reboot). By default,\nlog data is stored persistently if /var/log/journal/ exists during boot, with an implicit\nfallback to volatile storage otherwise. Use Storage= in journald.conf(5) to configure where\nlog data is placed, independently of the existence of /var/log/journal/.\n\nNote that journald will initially use volatile storage, until a call to journalctl --flush\n(or sending SIGUSR1 to journald) will cause it to switch to persistent logging (under the\nconditions mentioned above). This is done automatically on boot via\n\"systemd-journal-flush.service\".\n\nOn systems where /var/log/journal/ does not exist yet but where persistent logging is desired\n(and the default journald.conf is used), it is sufficient to create the directory, and ensure\nit has the correct access modes and ownership:\n\nmkdir -p /var/log/journal\nsystemd-tmpfiles --create --prefix /var/log/journal\n\nSee journald.conf(5) for information about the configuration of this service.\n",
            "subsections": []
        },
        "STREAM LOGGING": {
            "content": "The systemd service manager invokes all service processes with standard output and standard\nerror connected to the journal by default. This behaviour may be altered via the\nStandardOutput=/StandardError= unit file settings, see systemd.exec(5) for details. The\njournal converts the log byte stream received this way into individual log records, splitting\nthe stream at newline (\"\\n\", ASCII 10) and NUL bytes.\n\nIf systemd-journald.service is stopped, the stream connections associated with all services\nare terminated. Further writes to those streams by the service will result in EPIPE errors.\nIn order to react gracefully in this case it is recommended that programs logging to standard\noutput/error ignore such errors. If the SIGPIPE UNIX signal handler is not blocked or turned\noff, such write attempts will also result in such process signals being generated, see\nsignal(7). To mitigate this issue, systemd service manager explicitly turns off the SIGPIPE\nsignal for all invoked processes by default (this may be changed for each unit individually\nvia the IgnoreSIGPIPE= option, see systemd.exec(5) for details). After the standard\noutput/standard error streams have been terminated they may not be recovered until the\nservices they are associated with are restarted. Note that during normal operation,\nsystemd-journald.service stores copies of the file descriptors for those streams in the\nservice manager. If systemd-journald.service is restarted using systemctl restart or\nequivalent operation instead of a pair of separate systemctl stop and systemctl start\ncommands (or equivalent operations), these stream connections are not terminated and survive\nthe restart. It is thus safe to restart systemd-journald.service, but stopping it is not\nrecommended.\n\nNote that the log record metadata for records transferred via such standard output/error\nstreams reflect the metadata of the peer the stream was originally created for. If the stream\nconnection is passed on to other processes (such as further child processes forked off the\nmain service process), the log records will not reflect their metadata, but will continue to\ndescribe the original process. This is different from the other logging transports listed\nabove, which are inherently record based and where the metadata is always associated with the\nindividual record.\n\nIn addition to the implicit standard output/error logging of services, stream logging is also\navailable via the systemd-cat(1) command line tool.\n\nCurrently, the number of parallel log streams systemd-journald will accept is limited to\n4096. When this limit is reached further log streams may be established but will receive\nEPIPE right from the beginning.\n",
            "subsections": []
        },
        "JOURNAL NAMESPACES": {
            "content": "Journal 'namespaces' are both a mechanism for logically isolating the log stream of projects\nconsisting of one or more services from the rest of the system and a mechanism for improving\nperformance. Multiple journal namespaces may exist simultaneously, each defining its own,\nindependent log stream managed by its own instance of systemd-journald. Namespaces are\nindependent of each other, both in the data store and in the IPC interface. By default only a\nsingle 'default' namespace exists, managed by systemd-journald.service (and its associated\nsocket units). Additional namespaces are created by starting an instance of the\nsystemd-journald@.service service template. The instance name is the namespace identifier,\nwhich is a short string used for referencing the journal namespace. Service units may be\nassigned to a specific journal namespace through the LogNamespace= unit file setting, see\nsystemd.exec(5) for details. The --namespace= switch of journalctl(1) may be used to view the\nlog stream of a specific namespace. If the switch is not used the log stream of the default\nnamespace is shown, i.e. log data from other namespaces is not visible.\n\nServices associated with a specific log namespace may log via syslog, the native logging\nprotocol of the journal and via stdout/stderr; the logging from all three transports is\nassociated with the namespace.\n\nBy default only the default namespace will collect kernel and audit log messages.\n\nThe systemd-journald instance of the default namespace is configured through\n/etc/systemd/journald.conf (see below), while the other instances are configured through\n/etc/systemd/journald@NAMESPACE.conf. The journal log data for the default namespace is\nplaced in /var/log/journal/MACHINEID (see below) while the data for the other namespaces is\nlocated in /var/log/journal/MACHINEID.NAMESPACE.\n",
            "subsections": []
        },
        "SIGNALS": {
            "content": "SIGUSR1\nRequest that journal data from /run/ is flushed to /var/ in order to make it persistent\n(if this is enabled). This must be used after /var/ is mounted, as otherwise log data\nfrom /run/ is never flushed to /var/ regardless of the configuration. Use the journalctl\n--flush command to request flushing of the journal files, and wait for the operation to\ncomplete. See journalctl(1) for details.\n\nSIGUSR2\nRequest immediate rotation of the journal files. Use the journalctl --rotate command to\nrequest journal file rotation, and wait for the operation to complete.\n\nSIGRTMIN+1\nRequest that all unwritten log data is written to disk. Use the journalctl --sync command\nto trigger journal synchronization, and wait for the operation to complete.\n",
            "subsections": []
        },
        "KERNEL COMMAND LINE": {
            "content": "A few configuration parameters from journald.conf may be overridden on the kernel command\nline:\n\nsystemd.journald.forwardtosyslog=, systemd.journald.forwardtokmsg=,\nsystemd.journald.forwardtoconsole=, systemd.journald.forwardtowall=\nEnables/disables forwarding of collected log messages to syslog, the kernel log buffer,\nthe system console or wall.\n\nSee journald.conf(5) for information about these settings.\n\nNote that these kernel command line options are only honoured by the default namespace, see\nabove.\n",
            "subsections": []
        },
        "ACCESS CONTROL": {
            "content": "Journal files are, by default, owned and readable by the \"systemd-journal\" system group but\nare not writable. Adding a user to this group thus enables them to read the journal files.\n\nBy default, each user, with a UID outside the range of system users, dynamic service users,\nand the nobody user, will get their own set of journal files in /var/log/journal/. See Users,\nGroups, UIDs and GIDs on systemd systems[2] for more details about UID ranges. These journal\nfiles will not be owned by the user, however, in order to avoid that the user can write to\nthem directly. Instead, file system ACLs are used to ensure the user gets read access only.\n\nAdditional users and groups may be granted access to journal files via file system access\ncontrol lists (ACL). Distributions and administrators may choose to grant read access to all\nmembers of the \"wheel\" and \"adm\" system groups with a command such as the following:\n\n# setfacl -Rnm g:wheel:rx,d:g:wheel:rx,g:adm:rx,d:g:adm:rx /var/log/journal/\n\nNote that this command will update the ACLs both for existing journal files and for future\njournal files created in the /var/log/journal/ directory.\n",
            "subsections": []
        },
        "FILES": {
            "content": "/etc/systemd/journald.conf\nConfigure systemd-journald behavior. See journald.conf(5).\n\n/run/log/journal/machine-id/*.journal, /run/log/journal/machine-id/*.journal~,\n/var/log/journal/machine-id/*.journal, /var/log/journal/machine-id/*.journal~\nsystemd-journald writes entries to files in /run/log/journal/machine-id/ or\n/var/log/journal/machine-id/ with the \".journal\" suffix. If the daemon is stopped\nuncleanly, or if the files are found to be corrupted, they are renamed using the\n\".journal~\" suffix, and systemd-journald starts writing to a new file.  /run/ is used\nwhen /var/log/journal is not available, or when Storage=volatile is set in the\njournald.conf(5) configuration file.\n\nWhen systemd-journald ceases writing to a journal file, it will be renamed to\n\"original-name@suffix.journal\" (or \"original-name@suffix.journal~\"). Such files are\n\"archived\" and will not be written to any more.\n\nIn general, it is safe to read or copy any journal file (active or archived).\njournalctl(1) and the functions in the sd-journal(3) library should be able to read all\nentries that have been fully written.\n\nsystemd-journald will automatically remove the oldest archived journal files to limit\ndisk use. See SystemMaxUse= and related settings in journald.conf(5).\n\n/dev/kmsg, /dev/log, /run/systemd/journal/dev-log, /run/systemd/journal/socket,\n/run/systemd/journal/stdout\nSockets and other file node paths that systemd-journald will listen on and are visible in\nthe file system. In addition to these, systemd-journald can listen for audit events using\nnetlink(7).\n\nIf journal namespacing is used these paths are slightly altered to include a namespace\nidentifier, see above.\n",
            "subsections": []
        },
        "SEE ALSO": {
            "content": "systemd(1), journalctl(1), journald.conf(5), systemd.journal-fields(7), sd-journal(3),\nsystemd-coredump(8), setfacl(1), sdjournalprint(3), pydoc systemd.journal\n",
            "subsections": []
        },
        "NOTES": {
            "content": "1. Native Journal Protocol\nhttps://systemd.io/JOURNALNATIVEPROTOCOL\n\n2. Users, Groups, UIDs and GIDs on systemd systems\nhttps://systemd.io/UIDS-GIDS\n\n\n\nsystemd 249                                                              SYSTEMD-JOURNALD.SERVICE(8)",
            "subsections": []
        }
    },
    "summary": "systemd-journald.service, systemd-journald.socket, systemd-journald-dev-log.socket, systemd- journald-audit.socket, systemd-journald@.service, systemd-journald@.socket, systemd-journald- varlink@.socket, systemd-journald - Journal service",
    "flags": [],
    "examples": [],
    "see_also": [
        {
            "name": "systemd",
            "section": "1",
            "url": "https://www.chedong.com/phpMan.php/man/systemd/1/json"
        },
        {
            "name": "journalctl",
            "section": "1",
            "url": "https://www.chedong.com/phpMan.php/man/journalctl/1/json"
        },
        {
            "name": "journald.conf",
            "section": "5",
            "url": "https://www.chedong.com/phpMan.php/man/journald.conf/5/json"
        },
        {
            "name": "systemd.journal-fields",
            "section": "7",
            "url": "https://www.chedong.com/phpMan.php/man/systemd.journal-fields/7/json"
        },
        {
            "name": "sd-journal",
            "section": "3",
            "url": "https://www.chedong.com/phpMan.php/man/sd-journal/3/json"
        },
        {
            "name": "systemd-coredump",
            "section": "8",
            "url": "https://www.chedong.com/phpMan.php/man/systemd-coredump/8/json"
        },
        {
            "name": "setfacl",
            "section": "1",
            "url": "https://www.chedong.com/phpMan.php/man/setfacl/1/json"
        },
        {
            "name": "sdjournalprint",
            "section": "3",
            "url": "https://www.chedong.com/phpMan.php/man/sdjournalprint/3/json"
        }
    ]
}