See systemd for the main article.
systemd has its own logging system called the journal; therefore, running a
syslog daemon is no longer required. To read the log, use:
In Arch Linux, the directory
/var/log/journal/ is a part of the package, and the journal (when
Storage= is set to
/etc/systemd/journald.conf) will write to
/var/log/journal/. If you or some program delete that directory, systemd will not recreate it automatically and instead will write its logs to
/run/systemd/journal in a nonpersistent way. However, the folder will be recreated when you set
Storage=persistent and restart
systemd-journald.service (or reboot).
A syslog severity code (in systemd called priority) is used to mark the importance of a message RFC 5424 Section 6.2.1.
|0||Emergency||emerg||System is unusable||Severe Kernel BUG, systemd dumped core.|
This level should not be used by applications.
|1||Alert||alert||Should be corrected immediately||Vital subsystem goes out of work. Data loss. |
|2||Critical||crit||Critical conditions||Crashes, coredumps. Like familiar flash:|
Failure in the system primary application, like X11.
|3||Error||err||Error conditions||Not severe error reported:|
|4||Warning||warning||May indicate that an error will occur if action is not taken.||A non-root file system has only 1GB free.|
|5||Notice||notice||Events that are unusual, but not error conditions.|
|6||Informational||info||Normal operational messages that require no action.|
|7||Debug||debug||Information useful to developers for debugging the application.|
If you cannot find a message on the expected priority level, also search a couple of levels above and below: these rules are recommendations, and the developer of the affected application may have a different perception of the issue's importance from yours.
A syslog facility code is used to specify the type of program that is logging the message RFC 5424 Section 6.2.1.
|2||Mail system||Archaic POSIX still supported and sometimes used (for more)|
|3||daemon||System daemons||All daemons, including systemd and its subsystems|
|4||auth||Security/authorization messages||Also watch for different facility 10|
|5||syslog||Messages generated internally by syslogd||For syslogd implementations (not used by systemd, see facility 3)|
|6||lpr||Line printer subsystem (archaic subsystem)|
|7||news||Network news subsystem (archaic subsystem)|
|8||uucp||UUCP subsystem (archaic subsystem)|
|10||authpriv||Security/authorization messages||Also watch for different facility 4|
|16||local0||Local use 0 (local0)|
|17||local1||Local use 1 (local1)|
|18||local2||Local use 2 (local2)|
|19||local3||Local use 3 (local3)|
|20||local4||Local use 4 (local4)|
|21||local5||Local use 5 (local5)|
|22||local6||Local use 6 (local6)|
|23||local7||Local use 7 (local7)|
Useful facilities to watch: 0, 1, 3, 4, 9, 10, 15.
journalctl allows you to filter the output by specific fields. Be aware that if there are many messages to display or filtering of large time span has to be done, the output of this command can be delayed for quite some time.
$ strings /mnt/arch/var/log/journal/af4967d77fba44c6b093d0e9862f6ddd/system.journal | grep -i message
- Show all messages from this boot:
# journalctl -bHowever, often one is interested in messages not from the current, but from the previous boot (e.g. if an unrecoverable system crash happened). This is possible through optional offset parameter of the
journalctl -b -0shows messages from the current boot,
journalctl -b -1from the previous boot,
journalctl -b -2from the second previous and so on – you can see the list of boots with their numbers by using
journalctl --list-boots. See for full description, the semantics is much more powerful.
- Show all messages from date (and optional time):
# journalctl --since="2012-10-30 18:17:16"
- Show all messages since 20 minutes ago:
# journalctl --since "20 min ago"
- Follow new messages:
# journalctl -f
- Show all messages by a specific executable:
# journalctl /usr/lib/systemd/systemd
- Show all messages by a specific process:
# journalctl _PID=1
- Show all messages by a specific unit:
# journalctl -u man-db.service
- Show kernel ring buffer:
# journalctl -k
- Show only error, critical, and alert priority messages
# journalctl -p err..alertNumbers also can be used,
journalctl -p 3..1. If single number/keyword used,
journalctl -p 3- all higher priority levels also included.
- Show auth.log equivalent by filtering on syslog facility:
# journalctl SYSLOG_FACILITY=10
- If your journal directory (by default located under
/var/log/journal) contains huge amount of log data then
journalctlcan take several minutes in filtering output. You can speed it up significantly by using
--fileoption to force
journalctlto look only into most recent journal:
# journalctl --file /var/log/journal/*/system.journal -f
See blog post for details., , or Lennart's
SYSTEMD_LESSenvironment variable, which contains options passed to less (the default pager) and defaults to
FRSXMK(see and for details).
By omitting the
S option, the output will be wrapped instead of truncated. For example, start journalctl as follows:
$ SYSTEMD_LESS=FRXMK journalctlIf you would like to set this behaviour as default, export the variable from
Journal size limit
If the journal is persistent (non-volatile), its size limit is set to a default value of 10% of the size of the underlying file system but capped to 4 GiB. For example, with
/var/log/journal/ located on a 20 GiB partition, journal data may take up to 2 GiB. On a 50 GiB partition, it would max at 4 GiB.
The maximum size of the persistent journal can be controlled by uncommenting and changing the following:
It is also possible to use the drop-in snippets configuration override mechanism rather than editing the global configuration file. In this case do not forget to place the overrides under the
systemd-journald.service after changing this setting to immediately apply the new limit.
Seefor more info.
Clean journal files manually
Journal files can be globally removed from
/var/log/journal/ using e.g.
rm, or can be trimmed according to various criteria using
- Remove archived journal files until the disk space they use falls below 100M:
# journalctl --vacuum-size=100M
- Make all journal files contain no data older than 2 weeks.
# journalctl --vacuum-time=2weeks
Seefor more info.
Journald in conjunction with syslog
Compatibility with a classic, non-journald aware syslog implementation can be provided by letting systemd forward all messages via the socket
/run/systemd/journal/syslog. To make the syslog daemon work with the journal, it has to bind to this socket instead of
/dev/log (official announcement).
Forward journald to /dev/tty12
Create a drop-in directory
/etc/systemd/journald.conf.d and create a
fw-tty12.conf file in it:
[Journal] ForwardToConsole=yes TTYPath=/dev/tty12 MaxLevelConsole=info
Specify a different journal to view
There may be a need to check the logs of another system that is dead in the water, like booting from a live system to recover a production system. In such case, one can mount the disk in e.g.
/mnt, and specify the journal path via
--directory, like so:
$ journalctl -D /mnt/var/log/journal -xe