On 06.12.2012 00:03, Mike W wrote:
> End result seems to be the problem is max open files. Normally this=20
> would be fixed by increasing these in /etc/security/limits.conf for use=
r=20
> nagios which we did (and rebooted). However this did not resolve the=20
> problem. I created a check script at that point to output ulimit -a and=
=20
> it repeatedly showed that the max was still 1024 even tho we had set it=
=20
> to a greater value.
According to the docs that I have at my fingertips (which mightn't apply
to all other distribs, mind you), limits.conf affects PAM. I don't think
that Nagios, when started as root during the boot process and probably
setreuid()ing to user nagios, ever touches PAM. You might want to try
increasing the ofiles limit for *root* to see whether that yields the
result you expect. Since you intend to raise the limit above what
currently is your default *hard* limit, at least that latter *must* be
raised accordingly by OS means.
Having that said, when some daemon - or, for that matter, plugin - needs
some nonstandard per-process configuration, I don't see anything wrong
with configuring it someplace where it does *not* affect the rest of the
system (i.e., in /etc/init.d/nagios or the plugin itself). Manually
adding "umask 022" to all init scripts was considered good practice back
in the SunOS days ... :-}
Regards,
J. Bern
--=20
*NEU* - NEC IT-Infrastruktur-Produkte im :
Server--Storage--Virtualisierung--Management SW--Passion for Performance
Jochen Bern, Systemingenieur --- LINworks GmbH
Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt
PGP (1024D/4096g) FP =3D D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C2=
7
Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202
Unternehmenssitz Weiterstadt, Gesch=E4ftsf=FChrer Metin Dogan, Oliver Mic=
hel
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: Jochen.Bern@LINworks.de