[bugs #10967] gdnc daemon/file descriptor problem on NetBSD 1.6.2

[Richard Frith-Macdonald]

This mail is an automated notification from the bugs tracker
 of the project: GNUstep.

/**************************************************************************/
[bugs #10967] Latest Modifications:

Changes by: 
                Richard Frith-Macdonald <rfm@gnu.org>
'Date: 
                Thu 11/11/2004 at 14:21 (GMT)

------------------ Additional Follow-up Comments ----------------------------
The loop to close all descriptors is based on very old BSD unix source code for 
daemons ... so I think it, or variants of it are pretty widely used.  Certainly 
this sort of technique is commonly recommended to ensure that unused resources 
are released in a fork()ed process under unix.

A more modern alternative might be to do
int limit = getdtablesize();
for (c = 0; c < limit; c++) ...

The worst that *should* happen if you loop round closing all file descriptors 
is that it takes a long time (if the set size you use is very large), as a 
close() call should either close a descriptor and succeed, or return an error 
status.
A version which won't take too long might be  to do
int limit = getdtablesize();
if (limit > 10000) limit = 10000;
for (c = 0; c < limit; c++) ...

It may be that some 'feature' in recent BSDs does not like particular 
descriptors being closed.  Perhaps the threading implementation uses file 
descriptors for something ...

Perhaps searching the web for the actual error message (whatever it is) will 
provide a hint as to which descriptor(s) need to be left open on NetBSD, then 
we can easily modify the code to treat those descriptors specially.

Failing that, we *could* just restrict ourselves to closing 0,1,2 ... but 
depending on what launches gdnc, that might leave files held open when they 
shouldn't be.







/**************************************************************************/
[bugs #10967] Full Item Snapshot:

URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=10967>
Project: GNUstep
Submitted by: Riccardo mottola
On: Thu 11/11/2004 at 10:55

Category:  Base/Foundation
Severity:  5 - Average
Item Group:  Bug
Resolution:  None
Privacy:  Public
Assigned to:  None
Status:  Open


Summary:  gdnc daemon/file descriptor problem on NetBSD 1.6.2

Original Submission:  On NetBSD 1.6.2 gdnc fails to run: as soon as a client 
connects, it aborts. the culprit seems to be this code part:

  for (c = 0; c < FD_SETSIZE; c++)
    {
      if (is_daemon || (c != 2))
        {
          (void)close(c); 
        }
    }

it seems that too many fs's get closed and then threads break with a strange 
error message (already reported in another bug report, so almost for sure the 
two bugs are related to the same problem).

substtituting FD_SETSIZE with <= 2 works.

I never used FD_SETSIZE as in the code abce and the NetBSD manpage even states 
that FD_SETSIZE could be user set.

Alexander M. suggest to use the syscall daemon() on the system which have it to 
make the daemon. It is a BSD-style call, but linux seems to have it too.

Follow-up Comments
------------------


-------------------------------------------------------
Date: Thu 11/11/2004 at 14:21       By: Richard Frith-Macdonald <CaS>
The loop to close all descriptors is based on very old BSD unix source code for 
daemons ... so I think it, or variants of it are pretty widely used.  Certainly 
this sort of technique is commonly recommended to ensure that unused resources 
are released in a fork()ed process under unix.

A more modern alternative might be to do
int limit = getdtablesize();
for (c = 0; c < limit; c++) ...

The worst that *should* happen if you loop round closing all file descriptors 
is that it takes a long time (if the set size you use is very large), as a 
close() call should either close a descriptor and succeed, or return an error 
status.
A version which won't take too long might be  to do
int limit = getdtablesize();
if (limit > 10000) limit = 10000;
for (c = 0; c < limit; c++) ...

It may be that some 'feature' in recent BSDs does not like particular 
descriptors being closed.  Perhaps the threading implementation uses file 
descriptors for something ...

Perhaps searching the web for the actual error message (whatever it is) will 
provide a hint as to which descriptor(s) need to be left open on NetBSD, then 
we can easily modify the code to treat those descriptors specially.

Failing that, we *could* just restrict ourselves to closing 0,1,2 ... but 
depending on what launches gdnc, that might leave files held open when they 
shouldn't be.













For detailed info, follow this link:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=10967>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/