I ran an update on a CentOS server running Nagios, after the update, Nagios failed to start.

The error in the logs was:

Failed to obtain lock on file /var/run/nagios.pid: Permission denied

So, I checked and there was no pid file for Nagios in /var/run. I created one and gave it the following permissions:

-rwxr--r-- 1 nagios nagios 6 May 31 11:58 nagios.pid

Nagios then started and seems to be running normally.

The only problem is, it refuses to stop now, so I can't re-start it to add new servers and services to be monitored!

When I issue the command "service nagios stop", I get [FAILED], but nothing at all gets outputted to the log, and the service remains up.

Any ideas on how I can get the service to stop now?

I'm running the RPM version which was installed via yum from the RPMForge repositories. The server is CenotOS 5.5.

  • What is the contents of the pid file? – wzzrd May 31 '10 at 12:15
  • The PID file contained the correct PID. – Bart B May 31 '10 at 13:40

If you don't want to change the permissions on the /var/run folder itself, you can configure nagios to store the lock file anywhere on the system by adding the line below to your nagios.cfg file. As long as you point the lock_file option to a directory that nagios has access to create, modify and delete files then you should be good to go.

You could even store the lock file within your nagios installation directory by creating a a directory like: /usr/lib/nagios/var

  • Excellent - with just a small change this is exactly what I needed. When I went to edit nagios.cfg I found a nagios.cfg.rpmnew file there too, and in there was a different location for the pid file: lock_file=/var/nagios/nagios.pid Once I coppied that over to nagios.cfg all was well – Bart B May 31 '10 at 13:39

First, find out what the pid of nagios process is:

$ ps aux | grep nagios

Then you can use this command to restart the service:

kill -HUP <nagios_pid>

and this to stop:

kill <nagios_pid>

To stop nagios automatically , you should have its pid in /var/run/nagios.pid. Check it.


As Bart B said above, do not chmod 777 any directory on a production system, ever, unless there is a really good reason for it and you know what you are doing. This was a quick fix, but this is not the solution.

The correct solution to this problem, at least for me, was to update the nagios.cfg Nagios configuration file (mine is /etc/nagios/nagios.cfg), and to change this line:


to this:


The lock file is set to /var/nagios/nagios.pid in the /etc/init.d/nagios service configuration file, but is apparently overridden by the above value in nagios.cfg

Then you may restart the Nagios service/daemon:

   service nagios restart

That should do it.

  • In my case, the /etc/init.d/nagios pidvalue was not overridden by nagios.cfg, which caused "service nagios stop" to fail. Setting both nagios.cfg and /etc/init.d/nagios pidfile values to the same filepath solved the problem. – hurfdurf Jun 15 '10 at 23:42

On Centos/RedHat 7 you are not supposed to write directly to the /var/run directory, but you got a subdirectory /var/run/nagios. Check that the lock_file option points there instead like this:


If the Nagios server has a problem with start/stop on CentOS 6.x I use this command: /usr/local/nagios/bin/nagios -d /usr/local/nagios/etc/nagios.cfg

It works on my Nagios server.

  • For Stop: (1) ps aux | grep Nagios ( 2)kill <process ID #> – Frank Zhang Jun 2 '16 at 14:48

How about:

/etc/init.d/nagios stop

  • 1
    He says he tried already, that's not the answer ;) – lynxman Feb 1 '11 at 21:16

I got the same behavior updating to centos 5.5 For me it goes if I change the permission of /var/run with 777:

chmod 777 /var/run

I know it's not the best hack, but i didn't have much time to diagnose what's the problem.

  • I don't think it's a good idea. – lexsys May 31 '10 at 12:18
  • Do not chmod 777 anything, ever, unless you have a really good reason to do so. Which this is not. – wzzrd May 31 '10 at 12:41
  • Yikes - I guess it will work in the sense that Nagios will start and stop, but man, too dangerous for my blood! I certainly wouldn't recommend this on a production system! – Bart B May 31 '10 at 13:29
  • I know it's not a good idea, but it's a way to understand the problem. Because sure something in centos changed something and infact if you restart the machine the /var/run comes back to the original permission and nagios doesn't work again. As John Rabotnik suggested you can change where the lock file is written (and is what i did myself too) but when nagios will be updated the problem will come back again (or you keep a copy of the init file and use always the old one). If you login with the nagios user you can write normally in /var/run with the original permission. – PiL May 31 '10 at 16:31
  • So it looks like when you run an init script something is blocking nagios to write inside that directory. It's not easy to understand why it doesn't work. That's why i suggested a simple and fast workaround to change permission on the dir. – PiL May 31 '10 at 16:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.