Listaccount wrote:
Zitat von Gregor Mosheh <[EMAIL PROTECTED]>:

Kirill Korotaev wrote:
Just for the history/other users the resolution of the problem Steve had:
OpenVZ was installed on XFS

WOW, good work Kirill. That must have been a gnarly one to figure out,
I never even thought of the filesystem type combined with a bug in NRPE.

Sorry, have not listen close enough to this. Why is it a problem with XFS. The filesystem should not matter for applications running so it would be a XFS bug?

I'd say it was an NRPE bug as NRPE (as in Debian Sarge) wasn't handling the value returned by the filesystem.

Hence, the NRPE option to read conf files from a directory didn't work; the directory listing returned no entries. So far as NRPE was concerned, the directory was empty.

Since later versions of NRPE appear to do so, I'd say it was a bug in NRPE.


When I was diagnosing the issue and comparing the Xen instances with VZ I forgot that the important part of the VZ system (where the 'private' and 'root' directories are) was under an XFS mount point rather than ext3.

Hence all my testing was, unwittingly, comparing OpenVZ VMs residing on XFS against Xen VMs residing on ext3.

This made my diagnosis somewhat less than useful until I created a whole new OpenVZ Debian Sarge VM in a fresh partition which was formatted with ext3.

When this one worked fine I started to look more closely and realised my blunder.

I have to say, I've used both Nagios and XFS for many many years and never has something like this occured.

Had I realised that the important directories were XFS I may have found this:

http://osdir.com/ml/network.nagios.devel/2004-05/msg00044.html

From 2004!!! Amazing this wasn't fixed in Debian Sarge really.

:(

Sorry to have wasted anyones time...
_______________________________________________
Users mailing list
[email protected]
https://openvz.org/mailman/listinfo/users

Reply via email to