DISK CRITICAL - /run/user/0 is not accessible: No such file

[ITOMB_IMT]

Hi,

I have an issue with disk monitoring using Nagios XI, i see the error once in a day for "/run/user/0" partition where i will recovery alert once early in the morning and then it stays critical the whole day.

when i check from Client machine as Nagios user:
bash-4.2$ /usr/local/nagios/libexec/check_disk -w w20% -c c10% /run/user/0
DISK OK - free space: /run/user/0 25720 MB (100.00% inode=100%);| /run/user/0=0MB;25720;25720;0;25720

At the same time when i run the check from Nagios server:
root@Nagiosxiserver ~]# /usr/local/nagios/libexec/check_nrpe -H client_ip -t 90 -2 -c check_disk -a '-w 15% -c 10% -p /run/user/0'
DISK CRITICAL - /run/user/0 is not accessible: No such file or directory

Please suggest me a way to overcome this.

Thanks,

[vtrac]

Hi ITOMB_IMT,
I used the same command (below) and tested it out on my XI, which worked just fine.

Code: Select all

/usr/local/nagios/libexec/check_nrpe -H XXX.XXX.XXX.XXX -t 90 -2 -c check_disk -a '-w 15% -c 10% -p /run/user/0'
DISK OK - free space: /run/user/0 183 MiB (100.00% inode=100%);| /run/user/0=0MiB;155;164;0;183

Can you please try running the below command as "root" and "nagios" on your XI server?

Code: Select all

/usr/local/nagios/libexec/check_nrpe -H XXX.XXX.XXX.XXX -t 90 -2 -c check_disk -a '-w 15% -c 10% -p /run/user/0'

Looks like you might have permission issue on your (remote) server.

Can you do the followings on your "remote" server?

Code: Select all

ls -la -Z /run/user/

Do you have SELinux turned on (remote machine)? ... To check:

Code: Select all

getenforce

Best Regards,
Vinh

[ITOMB_IMT]

I tried to run both as nagios and root user, both returned same results, no file or directory.

On Nagios server
# /usr/local/nagios/libexec/check_nrpe -H xx.xxx.xxx -t 90 -2 -c check_disk -a '-w 15% -c 10% -p /run/user/0'
DISK CRITICAL - /run/user/0 is not accessible: No such file or directory
[root@nagios_server ~]# su - nagios
Last login: Tue Jan 19 12:18:01 EST 2021 on cron
Last login: Tue Jan 19 12:18:09 EST 2021 on pts/0
-bash-4.2$ /usr/local/nagios/libexec/check_nrpe -H xx.xxx.xxx -t 90 -2 -c check_disk -a '-w 15% -c 10% -p /run/user/0'
DISK CRITICAL - /run/user/0 is not accessible: No such file or directory

On Client machine:
[root@client_machine ~]# ls -la -Z /run/user
drwxr-xr-x root root ? .
drwxr-xr-x root root ? ..
drwx------ root root ? 0
[root@client_machine ~]# getenforce
Disabled
[root@client_machine ~]#

[vtrac]

Hi ITOMB_IMT,
I would recommend that you DO NOT check the "/run/user/0" folder, since it is only mounted when user "root" is locked on.
It is a temporary filesystem which only mounted if user "root" is logged on.
If user is no longer logged on the system, that "/run/user/0" filesystem will automatically un-mount.

I have tested that on my system as well. If you log onto your system as "root" and force a re-check, you will get an "OK" back.
However, after you have logged off, it will turned back to "CRITICAL" again.

Here's the article I read on "run/user/$uid":

Code: Select all

/run/user/$uid is created by pam_systemd and used for storing files used by running processes for that user. These might be things such as your keyring daemon, pulseaudio, etc.

Prior to systemd, these applications typically stored their files in /tmp. They couldn't use a location in /home/$user as home directories are often mounted over network filesystems, and these files should not be shared among hosts. /tmp was the only location specified by the FHS which is local, and writable by all users.

However storing all these files in /tmp is problematic as /tmp is writable by everyone, and while you can change the ownership & mode on the files being created, it's more difficult to work with.

So systemd came along and created /run/user/$uid. This directory is local to the system and only accessible by the target user. So applications looking to store their files locally no longer have to worry about access control.
It also keeps things nice and organized. When a user logs out, and no active sessions remain, pam_systemd will wipe the /run/user/$uid directory out. With various files scattered around /tmp, you couldn't do this.

Regards,
Vinh