Disk space monitoring no longer in container?

[ppanon2022]

Hi,

We just had an issue with the [non-db] container storage filling up.
This page seems to imply that there should be some processes sending warning on low disk space, and we also used to get warnings on the portal login screen, but neither seems to have kicked off in our 2025.07 environment. Since SNMP monitoring isn't supported in the container or in Leap Micro, we got caught unaware.
We don't seem to have any spacecheck directives in rhn.conf, so is this a recent replacement for the previous GUI warnings. How should storage monitoring look with a 2025.07 container installation? That page indicates that the directoriess to monitor would be
spacecheck_dirs = /var/lib/pgsql /var/spacewalk /var/cache /srv
but, firstly, /var/lib/pgsql is now in the separate db container, and the other three don't really match to the host's mapped filesystems since the overlay hides much. /, /root, and maybe /etc/pki/trust/anchors/LOCAL-RHN-ORG-TRUSTED-SSL-CERT (though that seems redundant with /root) would seem to be more appropriate if this is running in the current uyuni app services container. What is the recommended approach these days?

Thank you,

Paul-Andre

[rjmateus]

Hey Paul. File system check should be in place. @aaannz or @cbosdo do you know what is happening?=

[ppanon2022]

I think my memory may have been confused or stale. I've looked it over again and a) you're right I can (and had tried) to install and run it on the host under Leap Micro. b) IIRC, I was experiencing problems getting it running there.

What was going on was that I was trying to do run snmpd on the host and it now was also running in the app container (not sure if that was always the case or a "recent" container change). I would try to configure an SNMP v3 user for the host instance and the command would complain about snmpd running, but I would look at the host's snmpd service and it would be stopped. The container instance was configured with a community though, and I'm not sure if I can replace it with an SNMPv3 user (since that requires both snmpd.conf files - in /etc/snmp and in /var/lib/net-snmp/ to be persistent). Maybe the right way is to disable snmpd in the container while keeping it running on the host, which makes the containerized instance a little redundant.

Because the app container shuts down if some services like tomcat are stopped, I was a little concerned and reluctant to stop the containerized snmpd service in case something similar would happen with snmpd. Hopefully this approach is now stable through reboots. I haven't had the opportunity to test that.

[cbosdo]

I think my memory may have been confused or stale. I've looked it over again and a) you're right I can (and had tried) to install and run it on the host under Leap Micro. b) IIRC, I was experiencing problems getting it running there.

What was going on was that I was trying to do run snmpd on the host and it now was also running in the app container (not sure if that was always the case or a "recent" container change). I would try to configure an SNMP v3 user for the host instance and the command would complain about snmpd running, but I would look at the host's snmpd service and it would be stopped. The container instance was configured with a community though, and I'm not sure if I can replace it with an SNMPv3 user (since that requires both snmpd.conf files - in /etc/snmp and in /var/lib/net-snmp/ to be persistent). Maybe the right way is to disable snmpd in the container while keeping it running on the host, which makes the containerized instance a little redundant.

Because the app container shuts down if some services like tomcat are stopped, I was a little concerned and reluctant to stop the containerized snmpd service in case something similar would happen with snmpd. Hopefully this approach is now stable through reboots. I haven't had the opportunity to test that.

I don't think I understood everything here. My idea would be to run snmp on the host and monitor the storage of the disks where /var/lib/containers/storage/volumes/* are. I don't see why running snmp inside the server container would be needed.

In any case, if you manage to have a working example it would be nice to include it in the doc (and I can help with this).

[ppanon2022]

I think what confused me was that snmpd was installed in the container but running with an snmpv2 community that couldn't be changed. That was a red herring that prevented me from realizing I could disable that containerized service and run snmpd with a v3 user in the host. When I was trying to configure the host snmpd, it kept on refusing to do so because the containerized process was running.

Thus to run snmpd with an snmp v3 user permission (or even just a different v2 community than "public"), you need to

1. Enter the container context with mgrctl term
2. Disable and stop the container snmpd service with systemctl disable -now snmpd
3. Exit the container context
4. Install snmpd packages on the host, then configure it by running net-snmp-create-v3-user to create the v3 user
5. Enable and start the snmpd service on the host with systemctl enable -now snmpd

I expect the idea was that running snmpd in the container would reduce the impact of an exploit, but the lack of configurability reduces its benefit.

[cbosdo]

I think snmpd installed in the container is just a relic from the past that needs to be cleaned up. Some of the packages installed have a dependency on it

[cbosdo]

So, after investigations the snmpd is not enabled by default in the image. It is a cobbler dependency, so it won't be that easy to remove.