The self maintenance method is to vacuum the logs by size or time.
Retain only the past two days:
Retain only the past 500 MB:
man journalctl for more information.
On CentOS 7, you have to enable the persistent storage of log messages:
# mkdir /var/log/journal
# systemd-tmpfiles --create --prefix /var/log/journal
# systemctl restart systemd-journald
Otherwise, the journal log messages are not retained between boots.
Whether journald retains log messages from previous boots is configured via /etc/...
You don't typically clear the journal yourself. That is managed by systemd itself and old logs are rotated out as new data comes in. The correct thing to do would be to schedule journald to only keep as much data as you are interested in. The most usual thing to adjust is the total disk space it is allowed to take up. Once it crosses this boundry it will ...
Michael's answer is missing one thing: vacuuming only removes archived journal files, not active ones. To get rid of everything, you need to rotate the files first so that recent entries are moved to inactive files.
So, the complete answer to remove all entries seems to be
(Note that you cannot combine this ...
To control running services with systemd, use the systemctl utility. This utility is similar to the service utility provided by SysVinit and Upstart. Among others:
systemctl status systemd-journald indicates whether the service is running and additional information if it is.
systemctl start systemd-journald starts the service (systemd unit).
systemctl stop ...
As far as protocols are concerned, systemd-journald …
… is the listener on a stream socket named /run/systemd/journal/stdout. systemd connects the raw standard outputs and errors of services (that have defaulted to or that explicitly have StandardOutput=journal/StandardError=journal) to this socket. It thus receives the protocol of variable ...
First, the ability to use strings stems from a mere coincidence in that journald does not compress small (below 64KiB in current implementation) fields. This is not a supported way to read journals, and in the archwiki it really should be marked as such. It is more of a last-ditch recovery method.
Now on to the question. From journalctl(1):
-D DIR, --...
On Arch linux, the closest I got was:
Edit /etc/systemd/journald.conf to set SystemMaxUse=1M
Restarting journal: sudo systemctl restart systemd-journald
Re-Restarting the journal
On my system, each journal file is 8MB, and the above cleared all but 3, bringing the total size to ~25MB.
My use-case was disabling CoW for BTRFS (...
Because the log messages don't appear in the journal anywhere, I suspect that you don't have syslog to journald forwarding set up correctly, and the messages are simply getting dropped. Since you're on Arch, this is easy to fix. Ensure that the syslog-ng package is installed:
pacman -S syslog-ng
Then ensure that it's enabled on boot:
systemctl enable ...
Currently, journalctl can detect corrupt logs but has no "fsck" type command to attempt repair. The journald will automatically switch to writing a new "clean" file as soon as it detects the problem, so theoretically data loss should be minimal.
Until there is a file-repairing command, finding the corrupt journal file and removing it is the only cure. You ...
The reason for this behavior is that the machine identifier in /etc/machine-id changes at every reboot. This starts a new logging directory under /var/log/journal. Old logs can be viewed with the following command:
I'm still looking into the cause of the changing machine-id. Linode support is aware of the problem. I will update this ...
Stdout is being buffered, probably because of systemd redirect
Adding sys.stdout.flush() after write or PYTHONUNBUFFERED environment will solve this problem
See also the Stack Overflow question Python output buffering.
Since --vacuum-time and --vacuum-size didn't do a thing for me I did the following:
$ sudo find /var/log/journal -name "*.journal" | xargs sudo rm
$ sudo systemctl restart systemd-journald
It's not right, but it worked.
Asking and answering my own question because Google was not very helpful on this one.
Normally, with rsyslogd, the imuxsock module will create the /dev/log socket on its own, unlinking the previous entry before creating it. When rsyslogd is stopped (possibly because restart which fails because of faulty configuration), rsyslogd removes /dev/log.
One of the major innovations of daemontools in the middle 1990s was the idea of reliable logging. The dæmon supervisor ran two dæmons, the main dæmon and a log dæmon. It opened a pipe before invoking either, passing the write end of the pipe as the main dæmon process' standard output and the read end of the pipe as the log d&...
You can write a poor man's syslog server quite easily with socat. You just need a service unit like this:
ExecStart=/usr/bin/socat -u UDP-RECV:514 STDOUT
It will blindly send anything received on the syslog service port to the systemd journal. Save the above as, say, /etc/systemd/system/syslog.service and then
# systemctl ...
Jamie's answer is correct that you can force rsyslog to log what's going on with tomcat. However, that doesn't answer why tomcat 7 on rhel 7 does not log to catalina.out. Or if it does, why does it log to both catalina.out and a catalina with a date (if you are not using an RPM install).
First, in the past around 7.0.42, Red Hat's scripts used catalina.out ...
For systemd systems:
You have to specify the backend in /etc/fail2ban/jail.conf to use systemd as follows:
backend = systemd
Then restart fail2ban:
systemctl restart fail2ban
I'm a heavy CentOS/RHEL/Fedora guy so you may have to adapt what I say a bit. As far as this answer, you may have to update the fail2ban package to a version that supports ...
From systemd for Developers III: Revenge of the systemd we find:
The printed string in this example is logged at a default log priority
of LOG_INFO1. Sometimes it is useful to change the log priority for
such a printed string. When systemd parses STDOUT/STDERR of a service
it will look for priority values enclosed in < > at the beginning of
Seems this is not possible and unwanted by upstream (redirecting stdout/stderr to individual files) see e.g. http://lists.freedesktop.org/archives/systemd-devel/2012-March/004705.html - read the whole thread for more context information how this is intended to work.
What you can do, is either log to syslog, and that way write to individual files. Or the ...
Systemd stores everything in its log. Which at least on my laptop on moderate usage is big enough to go back to a year ago with default settings.
Should that not suffice, you can tinker with journald.conf
Then, it's just about using journalctl -t kernel (which is similar to -k, except it also allows you to see previous boots and use filters)
Use systemd-cat. It connects a pipeline or program output with the journal.
printf "Write text to the journal" | systemd-cat
Apr 12 13:37:00 servername : Write text to the journal
If you want to identify the logging tool you can add the -t option:
printf "Write text to the journal" | systemd-cat -t ...
If you need to script this, you should look into using the systemctl show
command. It is more useful for scripts than trying to parse anything from status. For example, to find when the service last started you can use:
$ systemctl show systemd-journald --property=ActiveEnterTimestamp
ActiveEnterTimestamp=Wed 2017-11-08 05:55:17 UTC
If you would like to ...
The new binary logs on Linux operating systems do not work in the way that the old binary logs did.
The old binary logs were /var/log/wtmp and /var/log/btmp. At system bootstrap an entry would be written to wtmp with the username reboot, and at shutdown an entry would be written to wtmp with the username shutdown. Finding the times that the system was ...
The systemd-journald man page explains how journal access control is done:
Journal files are, by default, owned and readable by the "systemd-journal"
system group but are not writable. Adding a user to this group thus enables
her/him to read the journal files.
By default, each logged in user will get her/his own set of journal files in
Seems that I'm most likely out of luck with journald. Unless I'll figure out a way to spawn a independent "long-term storage" journal (like currently there are different per-user journals), but I'm not sure it's a viable and sane approach. I guess, setting up a syslogd (and logrotate) would be easier.
The feature wasn't present in late 2014, as confirmed by ...
I believe what's going on is rsyslog is getting the message once from the application and then again from journald.
Yep. The solution is to include this in /etc/systemd/journald.conf:
Why there wasn't this problem when using imjournal I'm not sure, but there is a hint in man journald.conf:
[...] the journal ...