Needed to update the syslog / journal config due disk usage

Hello,

Thought I’d post this pseudo solution regarding CasaOS and the journal / syslog / logging function taking up too much disk.
My fix was to change the journal config and add a max, to the total used space. I’m probably logging too much but I’ll deal with that later. It’s helpful to already have logs at or better than informational i can tail instantly. I don’t look far back in time at all so max disk space suites me swell.

I DO have a few questions though.

  • Can you change the directory that journal writes its logs to?
  • OR ADD another path/directory the OS writes these logs to?
  • Looking to hold some logs off of the OS drive a bit longer in time but would like it to be automatic, not a copy i’m doing. A function of journald would be best.

ON TO THE CHANGE:

This directory was over 5G in size:
casaos@CasaOS:~$ ls -alhs /var/log/journal//
total 5.6G

An ls on the directory showed all the user and system journal (syslog) files.

Figured out journald was the keeper of all those files. How do we modify journald?

This file:
/etc/systemd/journald.conf
Concentrated on these two lines only.
casaos@CasaOS:~$ sudo cat /etc/systemd/journald.conf | grep MaxUse=
#SystemMaxUse=
#RuntimeMaxUse=

Both were uncommented and updated with a “MegaByte” size.
SystemMaxUse=1500M
RuntimeMaxUse=500M

I pulled a copy of the file off and made changes that way. After the change to journald.conf was complete I stopped journald while I swapped out the .conf file on the box.

.conf file switch and systemctl journal stop / start:
sudo systemctl stop systemd-journald
sudo rm /etc/systemd/journald.conf
sudo cp /home/casaos/Documents/journald.conf /etc/systemd/
sudo systemctl start systemd-journald

I restarted CasaOs after all this was done and let her run over night. I just checked the journal directory and we’re looking better already.

casaos@CasaOS:~$ ls -alhs /var/log/journal//
total 1.6G <<—SWEET!!!

I think this will work. Maybe I can tune it better if I get some info back on the questions.
Thanks

Referenced these during the process:

Here’s the default journal.conf file:
[Journal]
#Storage=
#Compress=yes
#Seal=yes
#SplitMode=uid
#SyncIntervalSec=5m
#RateLimitIntervalSec=30s
#RateLimitBurst=10000
#SystemMaxUse=
#SystemKeepFree=
#SystemMaxFileSize=
#SystemMaxFiles=100
#RuntimeMaxUse=
#RuntimeKeepFree=
#RuntimeMaxFileSize=
#RuntimeMaxFiles=100
#MaxRetentionSec=
#MaxFileSec=1month
#ForwardToSyslog=yes
#ForwardToKMsg=no
#ForwardToConsole=no
#ForwardToWall=yes
#TTYPath=/dev/console
#MaxLevelStore=debug
#MaxLevelSyslog=debug
#MaxLevelKMsg=notice
#MaxLevelConsole=info
#MaxLevelWall=emerg
#LineMax=48K
#ReadKMsg=yes
#Audit=no

Here’s how start, stop / restart the journal service:

  • 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 systemd-journald stops the service.
  • systemctl restart systemd-journald restarts the service.
  • systemctl reload systemd-journald reloads the service’s configuration if possible, but will not kill it (so no risk of a service interruption or of disrupting processing in progress, but the service may keep running with a stale configuration).
  • systemctl force-reload systemd-journald reloads the service’s configuration if possible, and if not restarts the service (so the service is guaranteed to use the current configuration, but this may interrupt something).
  • systemctl daemon-reload reloads systemd’s own configuration.

Could you not utilize logrotate to close off a log and move it to a new directory using postrotate. The journal should start a new log in its place. I know you said you don’t need that much back in time, but keeping older logs is useful for finding intermittent issues and such.