dccm misbehaving on Solaris 9

Vernon Schryver vjs@calcite.rhyolite.com
Wed Mar 1 22:02:47 UTC 2006

> From: Gary Mills 

>               In any case, 32-bit Solaris programs have a limit of
> 255 stdio streams, and require the file descriptors to be 255 or below.

WHAT!?  In any code written in the last 20 or 30 years that is utterly ...

It breaks not only that one use fo fdopen() in dccm (and dccifd) but also
the rare fopen().  I'd doubt you except it is confirmed by
Contrary to that web page, I don't see why it wouldn't be possible to
maintain binary compatibility with old programs but also support new
ones expecting reasonable (i.e. post PDP-11) behavior with any of the
many kludges used to maintain binary compatibility as system calls changed,
such as the change from 16-bit to 32-bit i-numbers for the stat()
system call in various UNIX flavors.   Of course that question is moot
and boring for anyone outside Sun Microsystems.

All things considered (including the continuous stream of open(),
socket(), and accept(), by other threads), I can't see a reasonable
work around besides not using fopen() or fdopen()....just what I want
to do, waste time writing yet another imitation mini-stdio package.

> I assume that fdopen() will set EBADF if the file descriptor is out of
> range.  

anyone who would write code that stuffs a file descriptor into a char
after about 1975 cannot be relied on to set errno.  It's a wonder that
amazing code bothers to check if the FD is >255.

> With those restrictions, it is easy to run out of stdio streams.

I had assumed the number of stdio streams was related to some kind of
pool FILE structures.  dccm does not use enough stdio to stress
a pool even with fewer than a dozen FILE structures.  

>                                                                   The
> usual workaround is to reserve low file descriptors for stdio, 

that's fine for 0, 1, and 2, but not so hot for random fopen() in code
that deals with lots of file descriptors.
I wonder about other programs that use hundreds of sockets and have
ASCII control files that ought to be reparsed occassionally.
BIND comes to mind.

>                                                              , and to
> limit the number of stdio streams.  When dccm was misbehaving the
> other day, the file descriptor limit was 5120.  It had 748 open files.
> The highest file descriptor was 1442.  This is fairly normal on a busy
> e-mail server that's handling hundreds of simultaneous SMTP sessions.

Given that restriction on file descriptors for fopen() and fdopen(),
I don't understand why it doesn't fail most times when
/var/dcc/whiteclnt needs to be re-parsed.  
whiteclnt must be re-parsed every time its mtime changes and every hour or
two if it previous contained host names whose IP addresses might change.

Vernon Schryver    vjs@rhyolite.com

More information about the DCC mailing list

Contact vjs@rhyolite.com by mail or use the form.