linked libs test warning bpfilter_umh
I have the following installed on Ubuntu server 20.04,
hobbit-plugins/focal,now 20191218 all xymon/focal,now 4.3.30-1 amd64 xymon-client/focal,now 4.3.30-1 amd64
Many of my hosts keep getting the yellow warning on the libs test:
Sat Jul 10 23:21:58 2021 - libs NOT ok
[green] Newest kernel is running: 5.4.0-77-generic, version #86-Ubuntu SMP Thu Jun 17 02:35:03 UTC 2021 [yellow] The following processes have libs linked that were upgraded:
root: / (deleted) (768)
The system is up to date, and I have not run an update since the last reboot That process is bpfilter_umh. Reboot does not seem to clear it. Not all of my hosts have it, but many do. Why is it (deleted) and how can I clear it?
Regards Rich
On 11/07/2021 00:34, Rich H wrote:
I have the following installed on Ubuntu server 20.04,
hobbit-plugins/focal,now 20191218 all xymon/focal,now 4.3.30-1 amd64 xymon-client/focal,now 4.3.30-1 amd64
Many of my hosts keep getting the yellow warning on the libs test:
Sat Jul 10 23:21:58 2021 - libs NOT okgreen Newest kernel is running: 5.4.0-77-generic, version #86-Ubuntu SMP Thu Jun 17 02:35:03 UTC 2021
yellow The following processes have libs linked that were upgraded:
root: / (deleted) (768)
The system is up to date, and I have not run an update since the last reboot That process is bpfilter_umh. Reboot does not seem to clear it. Not all of my hosts have it, but many do. Why is it (deleted) and how can I clear it?
bpfilter_umh is the "usermode helper" process which is automatically spawned when the bpfilter kernel module is loaded.
https://lwn.net/Articles/749108/ https://kernelnewbies.org/KernelProjects/usermode-helper-enhancements
It looks like the way this all works is that, when loaded, the kernel module provides a blob of binary data which is the executable rather than there being an executable on disk. I think this also means the info in /proc for the process is not quite what the libs test is used to, e.g.
ls /proc/119667/exe -l
lrwxrwxrwx 1 root root 0 Jul 11 18:38 /proc/119667/exe -> '/ (deleted)'
because there is no executable! Presumably the assumption in the code which populates /proc is "file not present => it must have been deleted"
I've checked my focal servers and the bpfilter module is not in use on any of them, so you might find it useful to identify if/why bpfilter is loading on your hosts. Regardless, I think the only solution here is either a) stop bpfilter loading if it isn't actually in use, or b) make the xymon libs test ignore this. For (b), put the following in /etc/xymon/libs.local.yaml - either these 4 lines verbatim if you don't yet have that yaml file, or merge with the existing whitelist dict if you do:
whitelist: '/ (deleted)': - '^/ \(deleted\)$'
Regards,
Adam
Thanks Adam, the filter worked.
Regards Rich
??????? Original Message ???????
On Sunday, July 11th, 2021 at 18:52, Adam Thorn <alt36 at cam.ac.uk> wrote:
On 11/07/2021 00:34, Rich H wrote:
I have the following installed on Ubuntu server 20.04,
hobbit-plugins/focal,now 20191218 all
xymon/focal,now 4.3.30-1 amd64
xymon-client/focal,now 4.3.30-1 amd64
Many of my hosts keep getting the yellow warning on the libs test:
Sat Jul 10 23:21:58 2021 - libs NOT okgreen Newest kernel is running: 5.4.0-77-generic, version #86-Ubuntu SMP Thu Jun 17 02:35:03 UTC 2021
yellow The following processes have libs linked that were upgraded:
root:
/ (deleted) (768)
The system is up to date, and I have not run an update since the last reboot
That process is bpfilter_umh. Reboot does not seem to clear it.
Not all of my hosts have it, but many do. Why is it (deleted) and
how can I clear it?
bpfilter_umh is the "usermode helper" process which is automatically
spawned when the bpfilter kernel module is loaded.
https://lwn.net/Articles/749108/
https://kernelnewbies.org/KernelProjects/usermode-helper-enhancements
It looks like the way this all works is that, when loaded, the kernel
module provides a blob of binary data which is the executable rather
than there being an executable on disk. I think this also means the info
in /proc for the process is not quite what the libs test is used to, e.g.
ls /proc/119667/exe -l
lrwxrwxrwx 1 root root 0 Jul 11 18:38 /proc/119667/exe -> '/ (deleted)'
because there is no executable! Presumably the assumption in the code
which populates /proc is "file not present => it must have been deleted"
I've checked my focal servers and the bpfilter module is not in use on
any of them, so you might find it useful to identify if/why bpfilter is
loading on your hosts. Regardless, I think the only solution here is
either a) stop bpfilter loading if it isn't actually in use, or b) make
the xymon libs test ignore this. For (b), put the following in
/etc/xymon/libs.local.yaml - either these 4 lines verbatim if you don't
yet have that yaml file, or merge with the existing whitelist dict if
you do:
whitelist:
'/ (deleted)':
- '^/ \(deleted\)$'
Regards,
Adam
Xymon mailing list
Xymon at xymon.com
participants (2)
-
alt36＠cam.ac.uk
-
rich＠slyone.org