Nagios Support Forum

Same issue on my test box. I'll put in a feature request for that. Shouldn't be an incredibly hard fix.

I submitted this as a bug in Nagios Core. (0000616 )
http://tracker.nagios.org/view.php?id=616

It was really lucky timing as the issue is supposedly fixed and rolled into yesterday's Core 4.0.7 release.
I don't have a spare server to test the fix on but I can look forward to an XI release with the fix
in the not too distant future

Watch the XI release notes, over the next couple releases. I am unsure if core 4.0.7 is too smoking for the next imminent XI release.

Yeah, I figure maybe sometime this year. For now I've got the passive check details going to
/usr/local/nagios/share/ssi/results/services/<servicename>/<hostname>
and I include a link in the summary output so users can still see the details and it doesn't
clutter up the main status line any more than necessary. (also doesn't limit the length of
detail data or clog up nagios with lots of data...it's just written directly to the file by the
check script and displayed by the webserver when needed)

Actually we patched the XI version 2014r1.1 that went out today with this fix

Cool! That gives me an excuse to try the web-based update feature. (on my test/devl box)
If that works, I'll give it a try on the prod box in the morning.

Awesome! Let us know!

Hmmm...not sure if it's working or not. I started the upgrade via the web GUI. It did a backup, though it did use what *seems* to be a generic filename: autoupgrade_backup..tar.gz while the manual backups I've done in the past used filenames based on the system time. In this case I don't know if running another upgrade would overwrite the previous backup file or not.

Meanwhile, all seemed well for 15 minutes or so, then the console seems to have stopped updating and there is a red box at the top that says 'Command not found.'.

checking wctype.h usability... yes
checking wctype.h presence... yes
checking for wctype.h... yes
checking whether the preprocessor supports include_next... yes
checking whether system header files limit the line length... no
checking for C/C++ restrict keyword... __restrict
checking whether <wchar.h> uses 'inline' correctly... yes
checking for btowc... yes
checking for symlink... yes
checking for mbsinit... yes
checking for mbrtowc... yes
checking for mprotect... yes
checking for _set_invalid_parameter_handler...


It's been almost 30 minutes total and about 15 minutes since the last change on the terminal screen. The top process is php at about 15% cpu. The update *seems* to be hung, but I can't tell for sure.

Update.

The original page that i started the upgrade on is still hung, but using another browser on a different workstation, it seems to have completed successfully. Doing a check for updates shows 'up to date' with 2014R1.1 and the Update history shows Sucess and a timestamp 25 minutes after starting the upgrade. I'm going to hold off until tomorrow before deciding whether or not to try the web-based upgrade on my production server.

Thanks for the update. We will try to re-produce this inhouse...