Listaccount wrote:
> Zitat von Gregor Mosheh <gregor@hostgis.com>:
>
>> 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...