4.3.3 - cannot touch `/run/nagios.lock': No such file or directory

[box293]

Installing 4.3.3 on CentOS 5.x / 6.x and I have come across this problem:

[root@core-013 nagioscore-nagios-4.3.3]#  service nagios start
Starting nagios:touch: cannot touch `/run/nagios.lock': No such file or directory
 done.
[root@core-013 nagioscore-nagios-4.3.3]# 
[root@core-013 nagioscore-nagios-4.3.3]#  service nagios status
No lock file found in /run/nagios.lock

Looking at /etc/rc.d/init.d/nagios on 4.3.3:
NagiosRunFile=/run/nagios.lock

Looking at /etc/rc.d/init.d/nagios on 4.3.2:
NagiosRunFile=${prefix}/var/nagios.lock

[hedenface]

Troy, I'm looking into this. I'll have a bugfix out shortly.

I think I'm going to not advertise the 4.3.3 release until after 4.3.4 is out - which I'll shoot for Thursday I think.

The easiest fix is to simply adjust the NagiosRunFile line to look like the one from 4.3.2. You can also mkdir /run && chown nagios /run. Either way - this is messed up :(

@orlitzky I'm assuming this change was necessary for the openrc-init?

[orlitzky]

You can also mkdir /run && chown nagios /run

Please don't do that, it will bring back the vulnerability!

The correct fix is to pass --with-lockfile to the configure script, and to point it to the directory on your system that is used for such things. The "modern" location is /run, but previously it was /var/run. If /var/run exists but /run does not, you'll want to pass --with-lockfile=/var/run/nagios.lock.

The change was necessary to get the lockfile out of a nagios-owned directory. So long as the lockfile is in a directory owned by the nagios user, he can overwrite it regardless of who owns the actual lockfile. (That's why you don't want to create /run and make it owned by nagios.)

Anyone without a /run directory will want to specify /var/run during configure time (or I guess we could autodetect it). That's no different than having to specify the correct --bindir, --libdir, etc.

[orlitzky]

Autodetection shouldn't be too hard, here's an untested patch. Someone without a /run directory will have to test it -- that's not something I can delete without borking my system:

diff --git a/configure.ac b/configure.ac
index 93460bb8..48ca7b7b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -265,11 +265,19 @@ AC_ARG_WITH(init_dir,
 AC_SUBST(init_dir)

 dnl User can override lock file location
+dnl Try the "modern" location /run first, and fall back
+dnl to /var/run if /run doesn't exist (or isn't a directory).
+if test -d /run; then
+       default_lockfile_path=/run/nagios.lock
+else
+       default_lockfile_path=/var/run/nagios.lock
+fi
+
 AC_ARG_WITH(lockfile,
        AC_HELP_STRING([--with-lockfile=<path>],
                [sets path for lock file (default: /run/nagios.lock)]),
        lockfile=$withval,
-       lockfile=/run/nagios.lock
+       lockfile=$default_lockfile_path
 )
 AC_SUBST(lockfile)

[orlitzky]

Eh.. aesthetically this is a little nicer:

default_lockfile_path=/var/run/nagios.lock
if test -d /run; then
       default_lockfile_path=/run/nagios.lock
fi

[hedenface]

Thanks @orlitzky - I'm going to get this added, along with your changelog addition and possibly something else and we'll issue a 4.3.4 release soon.

[hedenface]

Also, just to note: once we switch core to use the autoconf-macros project, this kind of detection will be way easier and maybe even a bit prettier :)

[hedenface]

Fixed in c3aec1f

If anyone knows how to get variables to work in AC_* macro output that'd be helpful. Something like:

AC_ARG_WITH(lockfile,
	AC_HELP_STRING([--with-lockfile=<path>],
		[sets path for lock file (default: $default_lock_file)]),
	lockfile=$withval,
	lockfile=$default_lockfile_path
)
AC_SUBST(lockfile)

The output string is literally: sets path for lock file (default: $default_lock_file)

[orlitzky]

The output string is literally...

I don't see an obvious way to fix this.. the "help" string gets defined right at the top of the resulting configure script, and is intended to be available before you actually run ./configure (and execute all of the tests). I tried a few tricks but they all failed. I'll ask around, but I like how you solved the problem anyway.

[hedenface]

Thanks. I don't either. If you ever come up with something, let me know :)

[hedenface]

Also - there's something kind of borked with this. We didn't account for an error message that's printed based on the lock file writing. It's writing, but spitting out errors. I'll fix that here, soon - but any insight is welcome @orlitzky

[orlitzky]

@hedenface what error are you seeing (and with what lockfile path)?