Nagios Support Forum

If the previous post didn't help, can you post your sanitized nagios.cfg and linux.cfg? Most importantly the section the OBJECT CONFIGURATION FILES section on nagios.cfg and the hostgroup section of your linux.cfg.

Can you add your config files to (EDIT) nagios.cfg, which breaks the service, and provide the results of the same -v command? Also, check the permissions on your newly created object files to ensure Nagios can read them. If Root owns them, I suspect that may be the issue.

I am unable to run that command. /usr/local/nagios/sbin/nagios: no such file or directory. I made a flub on my original post, I didn't list the OS, which is RHEL 8.8. Most people are used to Ubuntu, but many commands do not work on both. That may be why this 1 didn't. my apologies. I have my nagios...

Can you post some results from the "/usr/local/nagios/sbin/nagios -v /usr/local/nagios/etc/nagios.cfg" command?

This one is still open for me, I haven't been able to locate any info using the latest results posted above.

I had a similar issue during an install recently and it came down to the ownership and permissions of the htpasswd.users file located in /usr/local/nagios/etc. If root is the owner, change it to the nagios user. chown nagios:nagios htpasswd.users. Mine also has 664 perms.

I watched my resources over a period and didn't see anything of concern. I have the VM provisioned with 32GB RAM and 16 CPU. I watched RAM hover at 20% utilization with a few brief CPU spikes. I do have Splunk Enterprise running on the same server but the environment being monitored is small from my...

Of course. Thank you for taking a look. In the nagios.debug log, entries for "Unable to run scheduled service check at this time" start occurring. # 4096 = Interprocess communication # 8192 = Scheduling # 16384 = Workers debug_level=16 after nagios.service restart nagios.log [1700212009] w...

Sure thing. I ran a check_ping from the shell as the nagios user before and after a nagios.service restart. Both manual checks are successful. Could it be something with scheduling that break, perhaps? Here are my results for sanity check. Checking from shell as -u nagios before nagios.service resta...

That is correct. These results above are after the 'systemctl restart nagios.service' command is executed following validated changes. A full server OS reboot returns the nagios application to normal operation and these "unable to ..." lines in the log go away, checks run as expected.