NSCA and Nagios

keene at nrlssc.navy.mil keene at nrlssc.navy.mil
Fri Mar 18 16:04:30 CET 2005


Nagios never created a FIFO in var/rw.  The directory is world writable (with
the sticky bit set).

Nagios does delete the file upon shutdown, so upon starting up there is no
"nagios.cmd" file in the var/rw directory and Nagios is free to create one by
directory permissions and UNIX file semantics.  Nagios never creates a FIFO (or
any other file system object) in the var/rw directory and eventually NSCA's
"nsca" process (refering to the unmodified 2.4 version) attempts to verify it
exists.  It does not exist and thus "nsca" writes to a "nsca.dump" file, which
at this point is about 100kb.

How can I fix (apparently broken) my setup so that NSCA (unmodified version 2.4)
will work with Nagios 2.0 ?

[root at x nagios]# ls -ld var/rw
drwxrwxrwt   2 nagios   nagios       512 Mar 18 09:01 var/rw
[root at x nagios]# ps -A | grep nagios
 26669 ?        0:00 nagios
[root at x nagios]# ls -l var/rw/
total 130
-rw-r-----   1 nagios   nagios     65955 Mar 18 07:37 nsca.dump
[root at x nagios]#

Quoting Arno Lehmann <al at its-lehmann.de>:

> Hi.
>
> keene at nrlssc.navy.mil wrote:
>
> > I'm having a few problems with passive service monitoring with Nagios 2.0.
> >
> > First, NSCA and Nagios don't seem to work together.  NSCA won't create the
> > "command_file" if it doesn't exist and according to the Nagios
> documentation,
> > Nagios will delete it every time it processes it (and I have seen it
> deleted
> > before).  This makes NSCA pretty much useless, since it writes all its logs
> to
> > a "dump" file which nothing uses.
>
> No.
> nagiosd doesn't delete he command file. At least not here.
> It creates it as a pipe. What you've got to do is setup nagios, it's
> var/rw directory, the nagios user, nsca and the web server correctly.
>
> The file permissions and groups for the processes are important.
>
> It's all described in the nagios manual.
>
> > Relevant notes related to this:
> >
> > From the NSCA 2.4 source:
> >
> >         /* command file doesn't exist - monitoring app probably isn't
> running...
> > */
> >         if(stat(command_file,&statbuf)){
> >               ...
> >               return ERROR
> >               ...
> >               return OK
> >         }
> >
> > From the Nagios 2.0 documentation:
> > # EXTERNAL COMMAND FILE
> > # This is the file that Nagios checks for external command requests.
> > # It is also where the command CGI will write commands that are submitted
> > # by users, so it must be writeable by the user that the web server
> > # is running as (usually 'nobody').  Permissions should be set at the
> > # directory level instead of on the file, as the file is deleted every
> > # time its contents are processed.
> >
> > command_file=/data/monitor/nagios/var/rw/nagios.cmd
>
> Right. Follow the instructions.
>
> If it still doesn't work, post the output of ls -l concerning the
> relevant files and the parts of your config, then we'll see.
>
> >
> > So I modified the NSCA source to create the file if it doesn't exist (and
> not
> > care whether or not it existed before, as well).  It is now writing data to
> the
> > command file, but nothing seems to reap it.  The file has yet to be deleted
> and
> > my passive service (which has updates in the command file) has not been
> > processed by Nagios.
>
> Sorry, but you broke it.
> >
> > Any ideas on what is wrong ?
>
> Yeah, your setup
>
> Arno
>
> --
> IT-Service Lehmann                    al at its-lehmann.de
> Arno Lehmann                  http://www.its-lehmann.de
>




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null





More information about the Users mailing list