Having been recently introduced to Journalctl (ty Jay at Learnlinux TV et al) I have been monitoring /var/log/messages via the CLI with
sudo journalctl -f -a
This is set to follow the log and show me ‘all’ entries. This is great as it has helped me sort out a few non-fatal issues as well as learn more how the system works.
However, I am not seeing “all” entries as I would expect. For example, if, as non-sudo since sudo is logged, I run the mpv media play against a file then that is not logged. If I open leafpad and edit/save a file that is not logged. I found that in some cases I have to activate the application’s own log file file to capture logs.
I have scanned the man page but nothing is obvious to me about what “all” means. Is what is currently logged in /var/log/messages all there is to work with or are there other system tools (besides app’s own log files)?
I can not inform you about the details, but in general I would expect that with journalctl you see system logs. And a normal user that runs some application is not normally creating much logs on the system level. E.g. what you show as a user that tries to open a file that does not exist, that is simply a user error.
Imagine that all hundreds of users of a system use it extensive, how many logs do you expect then to be created? That would fill all disk space in due time.
And when a user application has the feature of creating logs in a log file (to be used by the user e.g. when he encounters some problem), that file will be in the users realm (somewhere in his/her home directory) and also most probably not in a format that journalctl will understand.
And I assume that “all” in this case means all the log entries that are available are listed, thus no filtering. Logs that are not available will obvious never be listed
Modern Linux gave up on System V logging more than a few years ago …
Currently, all
system (and user) logging is handled by the systemd Journal – located in a subdirectory of ‘/var/log/journal/’ and are directly accessible only be the user “root”. - The only access allowed is via the systemd “journalctl” command – also applies to “normal” (non-system) users …
There are some user logging relics in ‘~/.local/share/’ but, they’re often antiquated and unreliable …
The default Journal time stamps displayed by the systemd tools are (accurate) local time – which are usually sufficient for most purposes – with the exception of working out why the system boot isn’t as fast as it should be …
Thanks for the clarification. I read the man page too fast and assumed too much :shame:
No, I did not tinker. Rsyslog is set by default on any 15.1 or 15.2 install I have done with LXDE, LXQt and KDE.
Yes.
chris@asus-roc:~> systemctl status rsyslog
● rsyslog.service - System Logging Service
Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2021-03-03 07:48:10 AWST; 8min ago
Docs: man:rsyslogd(8)
http://www.rsyslog.com/doc/
Main PID: 1265 (rsyslogd)
Tasks: 5
CGroup: /system.slice/rsyslog.service
└─1265 /usr/sbin/rsyslogd -n -iNONE
chris@asus-roc:~> systemctl status rsyslog
● rsyslog.service - System Logging Service
Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2021-03-03 07:48:10 AWST; 2h 30min ago
Docs: man:rsyslogd(8)
http://www.rsyslog.com/doc/
Main PID: 1265 (rsyslogd)
Tasks: 5
CGroup: /system.slice/rsyslog.service
└─1265 /usr/sbin/rsyslogd -n -iNONE
I guess I just need to disable rsyslog.service and the binary logs start in either /run/log/journal or /var/log/journal depending on journald.conf Storage setting.
Storage=
Controls where to store journal data. One of "volatile", "persistent", "auto" and "none". If "volatile", journal log data will be stored only in memory, i.e.
below the /run/log/journal hierarchy (which is created if needed). If "persistent", data will be stored preferably on disk, i.e. below the /var/log/journal
hierarchy (which is created if needed), with a fallback to /run/log/journal (which is created if needed), during early boot and if the disk is not writable.
"auto" is similar to "persistent" but the directory /var/log/journal is not created if needed, so that its existence controls where log data goes. "none"
turns off all storage, all log data received will be dropped. Forwarding to other targets, such as the console, the kernel log buffer, or a syslog socket
will still work however. Defaults to "auto".
We’ll need to check why the syslog services are enabled by default – something is relying on them …
[HR][/HR]Back soon – please, brew a perfect porcelain cup of tea in a perfect porcelain teapot …
> apropos syslog
ipmievd (8) - IPMI event daemon for sending events to syslog
pam_syslog (3) - send messages to the system logger
pam_vsyslog (3) - send messages to the system logger
rsyslog.conf (5) - rsyslogd(8) configuration file
rsyslogd (8) - reliable and extended syslogd
syslog (2) - read and/or clear kernel message ring buffer; set console_loglevel
syslog (3) - send messages to the system logger
syslog (3p) - log a message
syslog (8) - the system logging service
syslog.h (0p) - definitions for system error logging
vsyslog (3) - send messages to the system logger
>
“rsyslogd
” is only vaguely related to “remote” – it’s “reliable and extended” with the following capability –
Support of both internet and unix domain sockets enables this utility to support both local and remote logging.
Digging deeper reveals that, syslog is still needed deeper down in the system logging architecture – the systemd Journal can be viewed as being merely a “syslog based management tool” …
The systemd Journal stores the system’s logs or messages in binary format …
[HR][/HR]So, the 64 dollar question –
Will the systemd Journal continue to function correctly if the syslog and rsyslog services are disabled
?
The syslog.service is an alias for rsyslog (ie same service)…and it is enabled for legacy purposes. You can happily stop and disable it if that is your wish.
