logcheck rule problem

[LeeE]

Whenever any of my lan hosts connect or disconnect to or from any of the nfs exports provided by my 'server' it results in log messages like these below:

Code: Select all

Nov 18 12:11:37 Poppa rpc.mountd[1506]: v4.2 client attached: 0x7d7b81aa67363f57 from "10.1.1.21:839"
Nov 18 12:27:54 Poppa rpc.mountd[1506]: v4.2 client detached: 0x7d7b81aa67363f57 from "10.1.1.21:839"

These are picked up by logcheck and emailed to me but because I really don't need to know about these perfectly normal and expected events I've been trying, for quite some time now, on and off, to create a logcheck rule to ignore them but with a complete lack of success (not helped by the fact that the 'testing' -t flag doesn't work with systemd - it appears that a patch is available up-stream).

Well I had another look at it today and although I think I've managed to shed some light on the problem I'm not really any closer to a solution.

I've found that if I call journalctl and pipe the output to grep, searching for "rpc" I get output like the following:

Code: Select all

root@Poppa:~# journalctl -S 2024-11-18 | grep rpc
Nov 18 00:05:15 Poppa rsyncd[669640]: run/rpc_pipefs/nfs/
Nov 18 00:05:15 Poppa rsyncd[669640]: run/rpc_pipefs/nfs/clnt22/
Nov 18 00:05:15 Poppa rsyncd[669640]: run/rpc_pipefs/nfs/clnt22/idmap
Nov 18 00:05:15 Poppa rsyncd[669640]: run/rpc_pipefs/nfs/clnt27/
Nov 18 00:05:19 Poppa rsyncd[669666]: run/rpc_pipefs/nfs/
Nov 18 00:05:19 Poppa rsyncd[669666]: run/rpc_pipefs/nfs/clnt142/
Nov 18 00:05:19 Poppa rsyncd[669666]: run/rpc_pipefs/nfs/clnt142/idmap
Nov 18 00:05:19 Poppa rsyncd[669666]: run/rpc_pipefs/nfs/clnt147/
Nov 18 09:24:48 Poppa rpc.mountd[1506]: v4.2 client attached: 0x7d7b819c67363f57 from "10.1.1.21:685"
Nov 18 09:47:19 Poppa rpc.mountd[1506]: v4.2 client detached: 0x7d7b819c67363f57 from "10.1.1.21:685"
Nov 18 11:26:44 Poppa rpc.mountd[1506]: v4.2 client attached: 0x7d7b81a067363f57 from "10.1.1.32:812"
Nov 18 11:43:00 Poppa rpc.mountd[1506]: v4.2 client detached: 0x7d7b81a067363f57 from "10.1.1.32:812"
Nov 18 12:11:37 Poppa rpc.mountd[1506]: v4.2 client attached: 0x7d7b81aa67363f57 from "10.1.1.21:839"
Nov 18 12:27:54 Poppa rpc.mountd[1506]: v4.2 client detached: 0x7d7b81aa67363f57 from "10.1.1.21:839"
root@Poppa:~# 

Which includes the string I'm targeting in my logcheck rule. However, if I just try using the -g/--grep param to journalctl to look for the "rpc" string I don't get any of the rpc.mountd lines that my logcheck rule is targetting:

Code: Select all

root@Poppa:~# journalctl -S 2024-11-18 -g rpc
Nov 18 00:05:15 Poppa rsyncd[669640]: run/rpc_pipefs/nfs/
Nov 18 00:05:15 Poppa rsyncd[669640]: run/rpc_pipefs/nfs/clnt22/
Nov 18 00:05:15 Poppa rsyncd[669640]: run/rpc_pipefs/nfs/clnt22/idmap
Nov 18 00:05:15 Poppa rsyncd[669640]: run/rpc_pipefs/nfs/clnt27/
Nov 18 00:05:19 Poppa rsyncd[669666]: run/rpc_pipefs/nfs/
Nov 18 00:05:19 Poppa rsyncd[669666]: run/rpc_pipefs/nfs/clnt142/
Nov 18 00:05:19 Poppa rsyncd[669666]: run/rpc_pipefs/nfs/clnt142/idmap
Nov 18 00:05:19 Poppa rsyncd[669666]: run/rpc_pipefs/nfs/clnt147/
root@Poppa:~# 

And just to confuse things a little more, systemctl doesn't know anything about any "rpc.mountd" services but looking at nfs-mountd.service gives:

Code: Select all

root@Poppa:~# systemctl status nfs-mountd.service
● nfs-mountd.service - NFS Mount Daemon
     Loaded: loaded (/lib/systemd/system/nfs-mountd.service; static)
     Active: active (running) since Thu 2024-11-14 18:20:06 GMT; 3 days ago
   Main PID: 1506 (rpc.mountd)
      Tasks: 1 (limit: 9431)
     Memory: 3.1M
        CPU: 505ms
     CGroup: /system.slice/nfs-mountd.service
             └─1506 /usr/sbin/rpc.mountd

Nov 17 08:09:09 Poppa rpc.mountd[1506]: v4.2 client attached: 0x7d7b815667363f57 from "10.1.1.222:930"
Nov 17 08:15:24 Poppa rpc.mountd[1506]: v4.2 client detached: 0x7d7b815667363f57 from "10.1.1.222:930"
Nov 17 14:14:32 Poppa rpc.mountd[1506]: v4.2 client attached: 0x7d7b815e67363f57 from "10.1.1.21:1014"
Nov 17 14:30:48 Poppa rpc.mountd[1506]: v4.2 client detached: 0x7d7b815e67363f57 from "10.1.1.21:1014"
Nov 18 09:24:48 Poppa rpc.mountd[1506]: v4.2 client attached: 0x7d7b819c67363f57 from "10.1.1.21:685"
Nov 18 09:47:19 Poppa rpc.mountd[1506]: v4.2 client detached: 0x7d7b819c67363f57 from "10.1.1.21:685"
Nov 18 11:26:44 Poppa rpc.mountd[1506]: v4.2 client attached: 0x7d7b81a067363f57 from "10.1.1.32:812"
Nov 18 11:43:00 Poppa rpc.mountd[1506]: v4.2 client detached: 0x7d7b81a067363f57 from "10.1.1.32:812"
Nov 18 12:11:37 Poppa rpc.mountd[1506]: v4.2 client attached: 0x7d7b81aa67363f57 from "10.1.1.21:839"
Nov 18 12:27:54 Poppa rpc.mountd[1506]: v4.2 client detached: 0x7d7b81aa67363f57 from "10.1.1.21:839"

I'm guessing then, that logcheck is using journalctl's -g/--grep param to do its pattern matching with the regex's in the logcheck rules but in this case, with nfs-mountd/rpc.mountd it's just not going to work.

This doesn't really look like a 'bug' to me, where something isn't working as intended, but more a consequence of the way that nfs-mountd is working, which also looks intentional. And then, even if I were to try to treat it as a bug, to which package should I attribute it?

So yeah, not sure where to go from here.

[CwF]

You could allow the chattiness, and filter it in your email program.

[LeeE]

You could allow the chattiness, and filter it in your email program.

Thanks for the suggestion but experience has shown me that it's better to address the underlying problem rather than pretend it's not there and just try to cover it up - in my experience that invariably leads to further complications and consequences.

But in any case, I would still receive a notification from my email checker that an email has arrived but then, when I fired up my email client to investigate the new email, instead of finding an email that I don't have to worry or do anything about, I'd find nothing there at all. Now, as long as I don't forget that I've set up a filter to automatically delete certain emails, that won't lead to any confusion at all.

Although I framed this question in the context of my lan this was for the sake of simplicity; it also applies to some 'business' systems I'm looking after and part of doing that job properly means that I have to leave those systems in a state where things are not personalised to me; they must be in a state where anyone else could take over without needing to untangle my 'personalisations' to figure out what's going on.