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

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