I read it in passing on my travels when looking at persisting journal logs, but the fact i cannot find it now makes me question it’s validity. I’ll have to do more reading up I guess. None the less, regardless of the exact max size, the concept remains the same, if we have journals bigger than that hanging around in RAM we potentially have bigger issues to resolve.
undoutably, but the aim has to be to keep those tweaks to a minimum and try to use stock settings and non-tweaked setups where possible.
Never suggested that it would be!
However, with a well tuned L2R+ to manage the logs globally, simply creating the folder is exactly how easy adding the journal is!
As I stated sometime ago, I expect L2R to be just a starting point to develop a better solution, I have already added the logrotate olddir directive. To that I’ve already mentioned using monit to push a logrotation. My thoughts on this are actually to delete the logrotation cron and to use L2R to trigger the rotation check hourly immediately before doing the backup. This would mean that the log.bak (persisted logs) and log.old (rotated logs) would always align rather than the rotate doing it’s own interval and the L2R another. To this I would add a log2ram --force (or something similar) so that monit could just call log2ram --force rather than logrotate separately, perhaps the --wrirte option could even escalate itself to execute a forced rotation based on the size of /var/log?
Also I think it might be a help to add the “enable journal persistence” to L2R config file so that on a new install the journal folder is created automatically (if configured) and can be switched on or off via L2R to keep the log management in one place for now.
Even the size in ram could be changed to a percentage value so that when installed to a Zero or Pi B the partition is created by L2R as a percent of total ram (eg 10% = 100M’ish on Pi 2 & 3’s and 50M’ish on a Pi A,B or Zero) rather than a defined size in MB (currently 40).
No. Only if the user (or the distro, perhaps because it thinks its users are stick-in-the-mud) has chosen to do such duplication explicitly.
Only if you have chosen to have it in transient storage. I keep arguing that the journal is THE (pardon the emphasis) thing that you want most in persistent storage, to be able to debug crashes.
AIUI, debug level will log less than warning level. I suggest that warning is a sensible default as @TrystanLea has proposed.
BTW, systemd and cron coexist quite happily, but if you want to be PC, you could rewrite cron jobs as systemd timers instead.
Yes! The default setting in journald is ForwardToSyslog=yes. Whether rsyslog is configured to store the messages (by default) is a different question.
Again incorrect, the default is auto so it will only store to RAM and not disk unless it is changed or a /log/var/journal folder is manually created by the user.
" SystemMaxFileSize= and RuntimeMaxFileSize= control how large individual journal files may grow at most. … Defaults to one eighth of the values configured with SystemMaxUse= and RuntimeMaxUse="
" SystemMaxUse= and RuntimeMaxUse= control how much disk space the journal may use up at most. … The first pair defaults to 10% … of the size of the respective file system … each value is capped to 4G."
"Control whether log messages received by the journal daemon shall be forwarded to a traditional syslog daemon, to the kernel log buffer (kmsg), to the system console, or sent as wall messages to all logged-in users. These options take boolean arguments. If forwarding to syslog is enabled but nothing reads messages from the socket, forwarding to syslog has no effect. By default, only forwarding to wall is enabled.
Your default must be different to Raspbian default then.
From the man on my system;
CONFIGURATION DIRECTORIES AND PRECEDENCE
The default configuration is defined during compilation, so a configuration file is only needed when it is necessary to
deviate from those defaults. By default, the configuration file in /etc/systemd/ contains commented out entries showing the
defaults as a guide to the administrator. This file can be edited to create local overrides.
pi@emonpi:/var/log $ cat /etc/systemd/journald.conf
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
#
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See journald.conf(5) for details.
[Journal]
#Storage=auto
#Compress=yes
#Seal=yes
#SplitMode=uid
#SyncIntervalSec=5m
#RateLimitIntervalSec=30s
#RateLimitBurst=1000
#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
No, we are not.
On the EmonSD there is no folder /var/log/journal, and the Storage= is set to auto so logs are only held, by journald in RAM not on disk. auto will create a /run/log/journal/ folder if it does not exist but will not create a /var/log/journal folder. So the user needs to choose to hold the journal on disk either by changing the storage= to persistant or create the /var/log/journal folder.