What can be done to prevent messages from cluttering up log files?
Hi, assuming you can't get rid of the cause of messages flooding the log file, could you prevent writing with a filter? After all, only filtering when reading would not prevent the unnecessary growth of log files. I stumbled across the following which the solutions posted on the forums managed to fix. https://bbs.archlinux.org/viewtopic.php?id=275022 https://bbs.archlinux.org/viewtopic.php?id=280638 [rocketmouse@archlinux ~]$ grep threadirqs\ i /boot/grub/grub.cfg linux /boot/vmlinuz-linux root=/dev/disk/by-label/m1.archlinux ro threadirqs ibt=off ipv6.disable=1 [rocketmouse@archlinux ~]$ cat /etc/acpi/events/buttons event=button/(up|down|left|right|kpenter) action=<drop> But what could you do if there were no such workarounds? Regards, Ralf
On Sun, 23 Apr 2023 at 07:53, Ralf Mardorf <ralf-mardorf@riseup.net> wrote:
Hi,
assuming you can't get rid of the cause of messages flooding the log file, could you prevent writing with a filter? After all, only filtering when reading would not prevent the unnecessary growth of log files.
you didn't say which messages, but in systemd 253 there's a new per-unit option LogFilterPatterns=. * A new LogFilterPatterns= option has been added for units. It may be used to specify accept/deny regular expressions for log messages generated by the unit, that shall be enforced by systemd-journald. Rejected messages are neither stored in the journal nor forwarded. This option may be used to suppress noisy or uninteresting messages from units. -- damjan
On Sun, 2023-04-23 at 12:44 +0200, Damjan Georgievski wrote:
On Sun, 23 Apr 2023 at 07:53, Ralf Mardorf <ralf-mardorf@riseup.net> wrote:
assuming you can't get rid of the cause of messages flooding the log file, could you prevent writing with a filter? After all, only filtering when reading would not prevent the unnecessary growth of log files.
you didn't say which messages, but in systemd 253 there's a new per-unit option LogFilterPatterns=.
* A new LogFilterPatterns= option has been added for units. It may be used to specify accept/deny regular expressions for log messages generated by the unit, that shall be enforced by systemd-journald. Rejected messages are neither stored in the journal nor forwarded. This option may be used to suppress noisy or uninteresting messages from units.
Hi, thank you. There are actually no messages that spam my journal. I just want to know just in case. Regards, Ralf
On Sun, Apr 23, 2023 at 15:09:37 +0200, Ralf Mardorf wrote:
On Sun, 2023-04-23 at 12:44 +0200, Damjan Georgievski wrote:
On Sun, 23 Apr 2023 at 07:53, Ralf Mardorf <ralf-mardorf@riseup.net> wrote:
assuming you can't get rid of the cause of messages flooding the log file, could you prevent writing with a filter? After all, only filtering when reading would not prevent the unnecessary growth of log files.
you didn't say which messages
Hi,
thank you. There are actually no messages that spam my journal. I just want to know just in case.
As with most (all?) solutions looking for a problem, this, too, is quite disconnected from reality. It is much better to address the underlying problem rather than ignoring it. If you encounter a situation where you have something flooding your logs, there's an actual problem with your system, and generally something quite serious. Sure, there are occasional bugs where something logs too frequently, but more serious problems are more common. I would suggest focusing on these real issues instead of manufacturing hypotheticals. -- Cheers, Luna Celeste
On Sun, 23 Apr 2023 at 19:07, Luna Celeste <luna@unixpoet.dev> wrote:
snip As with most (all?) solutions looking for a problem, this, too, is quite disconnected from reality.
Actually, I *have* this problem. But it is on C7. What it is, is a docker child that keeps sending logs entries, several times a second, up the chain to the host's system journal. The docker children are launched with docker-exec and because we are running a 3rd-party code we cannot modify the source without getting it re-certified and tested. Given the 6 figure number involved in those 2 steps, we are stuck with having to deal with the log entries as they come in the system journal. So this is not a solution looking for a problem. I hadn't spoken up before because it is on C7 and therefore on systemd219...
participants (4)
-
Andy Pieters
-
Damjan Georgievski
-
Luna Celeste
-
Ralf Mardorf