Heya Hendrik,
Hendrik Bäcker wrote:
> > Program received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread 1077336608 (LWP 3529)]
> > 0x0808450c in process_check_result_queue (dirname=0x80d4078
> > "/var/spool/nagios3/checkresults") at utils.c:2244
> > 2244 utils.c: No such file or directory.
> > in utils.c
> > (gdb) bt
> > #0 0x0808450c in process_check_result_queue (dirname=0x80d4078
> > "/var/spool/nagios3/checkresults") at utils.c:2244
>
>
> can you verify if the path "/var/spool/nagios3/checkresults" is existing
> on your system?
Sure it exists ... plus Nagios is able to create a handful of temporary
queue files, which makes this even more weird. Not even the debug.log
has any useful information which file Nagios fails to
access exactly ...
(snip)
[1199372484.065535] [016.2] [pid=3545] Moving temp check result file
'/var/spool/nagios3/checkresults/checkNmJmfN' to queue file
'/var/spool/nagios3/checkresul
ts/ccfuOCQ'...
(snip)
[1199372487.135649] [001.0] [pid=3529] reap_check_results() start
[1199372487.135691] [016.0] [pid=3529] Starting to reap check results.
... and then it segfaults
> Further information like OS, OS Level, source install or distro package
> would be nice, too.
Debian Etch using packages from [1], nothing special ...
Tobias
[1] http://people.teamix.de/~svelt/debian/e ... /3.0-rc-1/
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]