SUMMARY: Urgent: warning: cannot open /etc/hosts.allow: Too many open files

From: Luiz Alfredo Baggiotto <luiz_at_pucrs.br>
Date: Thu Mar 10 2005 - 18:54:00 EST
Dear admins

Thank you very much for all! With the unvaluable help of many people (special
thanks to Antonia Gomez, Darren Dunham, Bernd Schemmer and Yann Geneste), I
could solve my problem.
The original question:

>Recently, I was installed a openldap software in a Sun Solaris 9 box.
>Initial tests are ok, but now, when I was migrated my users to this system,
>frequently the ldap daemon stops to work. In the logs, I was saw this
message:
>
>warning: cannot open /etc/hosts.allow: Too many open files
>
>Restarting the slapd daemon, the system works again, but with a
>increment of the network demand, the error goes back and I need to
>restarts again and again and again...
>I searched about it in the net and I discovered something. Apparently,
>the problem is that the file descriptors of the system is very low
>(256). I was used the 'plimit' command to view the information of my slapd
process:
>
># ps -ef | grep slapd
>     ldap 10708     1  0 16:34:00 ?        0:13 /usr/local/libexec/slapd -u
>ldap -g ldap -h ldaps:/// ldap:///
># plimit -k 10708
>10708:  /usr/local/libexec/slapd -u ldap -g ldap -h ldaps:/// ldap:///
>    resource              current         maximum
>   time(seconds)         unlimited       unlimited
>   file(kbytes)          unlimited       unlimited
>   data(kbytes)          unlimited       unlimited
>   stack(kbytes)         8192            unlimited
>   coredump(kbytes)      unlimited       unlimited
>   nofiles(descriptors)  256             65536
>   vmemory(kbytes)       unlimited       unlimited
>
>Well, the recomendation is to include this lines in /etc/system and
>reboot the
>machine:
>
>* set hard limit on file descriptors
>set rlim_fd_max = 4096
>* set soft limit on file descriptors
>set rlim_fd_cur = 1024
>
>The problem is that to get a time to reboot the server. Then, I was
>discovered (in the plimit man) the option -n, to set this daemon option
>"on the fly":
>
>     -n soft,hard
>            Set file descriptor limits (no default unit).
>
>I tried this:
>
># plimit -n 16384,65536 10708
># plimit -k 10708
>10708:  /usr/local/libexec/slapd -u ldap -g ldap -h ldaps:/// ldap:///
>    resource              current         maximum
>   time(seconds)         unlimited       unlimited
>   file(kbytes)          unlimited       unlimited
>   data(kbytes)          unlimited       unlimited
>   stack(kbytes)         8192            unlimited
>   coredump(kbytes)      unlimited       unlimited
>   nofiles(descriptors)  16384           65536
>   vmemory(kbytes)       unlimited       unlimited
>
>Well, I was thinking the problem is solved, but has occured again, in
>the same circunstances!!!

The final solution was presented by Antonia Gomez:

> We have had the same problem but we have  solved this problem change the
variable idletimeout
> in the slapd.conf file. In default its  valor is 0 and we have changed to
30, and now this error
> "too many open files" dosen't take place.

But Darren Dunhan supplied me with a lot of very good tips about limit/ulimit
and (especially) pfiles command, besides to explain the problem of "stdio"
file descriptors limits:

> use 'limit' to set the filedescriptors in your shell before launching slapd,
then slapd will inherit it.
>
> limit -n 1024
> slapd
>
> Now you don't have to mess with finding a PID and then running plimit on it
after the fact.

---------

> >    resource              current         maximum
> >   time(seconds)         unlimited       unlimited
> >   file(kbytes)          unlimited       unlimited
> >   data(kbytes)          unlimited       unlimited
> >   stack(kbytes)         8192            unlimited
> >   coredump(kbytes)      unlimited       unlimited
> >   nofiles(descriptors)  16384           65536
> >  vmemory(kbytes)       unlimited       unlimited
> >
> >  According to it, I shouldn4t have problems with file descriptors now,
> >  but the error still happening. And I think it4s impossible that
> >  there are more than 16,384 connections with only 55 logged users!
> >  Therefore, I think the limit stills in 256 connections. :-(
>
> Ahh. very possible.  Use 'pfiles <PID>' to display the current file
descriptors.
>
> There are some situations where programs are unable to use file descriptors
higher than 255,
> regardless of the number available.
>
> Most notably, if a program uses stdio, it can only access 256 file
descriptors.
>
> > Basically, I think 'limit', 'plimit', or the /etc/system
> > modifications should do similar things, and they should all work.
> > Could you provide more details about the failure?
> >
> > I was thinking exactly the same, therefore my doubt about the efficiency
of the reboot.
> > But now there are na interesting point to consider:
>
> I see now.  Yes, I agree that if you're hitting the problem, it is unlikely
that the
> /etc/system modifications will have any further effect.
>
> > > AFAIK as I know you can't increase the no of file descriptors above
> > > the limit set in the /etc/system (or the default limits if the
> > > entries in the /etc/system are missing)
> > >
> > > You *must* reboot the machine for activating the new limits.
>
> Usually untrue.  I can hope I am wrong here, but if plimit shows the
elevated number,
> I see no reason that the /etc/system changes would do anything else.

---------

Effectively, in spite of the daemon file descriptors is showing a great
number, the problem always happens when the 256 limit are reached:

# pfiles 15445
15445:  /usr/local/libexec/slapd -u ldap -g ldap -h ldaps:/// ldap:///
  Current rlimit: 16384 file descriptors

But now, after the "idletimeout" setting in slapd.conf, even with 101
simultaneous users, the file descriptors of the daemon are below of the 256
limit.

Thanks a lot again for all.
Best regards

Luiz
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers
Received on Thu Mar 10 18:54:33 2005

This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:43:44 EST