bugGNUstep - Bugs: bug #10967, gdnc daemon/file descriptor...

Group
 
 

bug #10967: gdnc daemon/file descriptor problem on NetBSD 1.6.2

Submitter:  Riccardo Mottola <rmottola>
Submitted:  Thu 11 Nov 2004 10:55:06 AM UTC
   
 
Category:  Base/Foundation Severity:  3 - Normal
Item Group:  Bug Status:  Fixed
Privacy:  Public Assigned to:  CaS
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 05 Jun 2005 05:33:09 AM UTC, comment #6: 

No follow up for six months ... so I closed this

Richard Frith-Macdonald <CaS>
Group Member
Thu 09 Dec 2004 08:15:07 AM UTC, comment #5: 

I tested the fix and it compiles fine on the NetBSD/1.6.2 machine and gdnc passes both the nsnotificaiton test in -base as well as plainly running several applications. Gdnc seems to work and not to crash for local use or if opened for remote hosts.
Now gpbs doesn't startup, I wonder if it is gdnc related or not.

I also tested the same code on non-pth OS's (new beta netbsd, solaris) and it seems to work fine there too.

SO if further problems do not rise the issue again I'd say "ok".

Riccardo Mottola <rmottola>
Group Member
Sun 21 Nov 2004 08:43:12 AM UTC, comment #4: 

Attempted fix now in place in CVS ... please test.

The problem turns out to be that -
1. Closing all file descriptors messes up the pth threading library.
2. Good practice is to close unnecessary descriptors in a daemon.
3. There is no obvious way to find out which descriptors pth uses.

The solution I decided upon was, rather than simply forking to produce the
daemon, to fork and the exec the program again ... thus reinitialising the
threading system for the newly exec'ed program.

However, to re-exec the program we need to determine the path to the executable.  This required two bugfixes in NSBundle -
1. Ensure that the -executablePath method works for the main bundle.
2. Ensure that the +mainBundle method returns a bundle rather than nil.

This should all be working now ... I've tested it on my Debian GNU/Linux system, but of course it needs to be tested on a BSD system using the pth library, and I don't have that system to test on.


Richard Frith-Macdonald <CaS>
Group Member
Thu 11 Nov 2004 10:01:21 PM UTC, comment #3: 

I downloaded the source to the pth library ... and it looks like this problem is a feature of pth rather than a BSD specific thing.
It seems that the pth library uses a pipe for internal signalling/scheduling,
so if we close that pipe we will mess up the library.
Unfortunately, the library does not assign the pipe any particular descriptor numbers, so we can't be sure which descriptors ar those needed for pth.

That being the case, I don't think there is any good solution to the problem ... perhaps the least bad would be to use a similar mechanism to windows, fork, close descriptors, then exec to a new copy of the process with an extra argument to prevent it forking recursively.

Richard Frith-Macdonald <CaS>
Group Member
Thu 11 Nov 2004 02:36:42 PM UTC, comment #2: 

The exact error is

*Pth* SCHEDULER INTERNAL ERROR: no more thread(s) available to schedule!?!?

which comes from pth, googling around I found that other got the same problem in daemons, but since their code is quite different I couldn't gather more info for now.

The upcoming 2.0 beta which has native kernel threads doesn't suffer this problem, so I think it is not a NetBSD problem per se, but an interaction of NetBSD and Pth.

Riccardo Mottola <rmottola>
Group Member
Thu 11 Nov 2004 02:21:30 PM UTC, comment #1: 

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.

Richard Frith-Macdonald <CaS>
Group Member
Thu 11 Nov 2004 10:55:06 AM UTC, 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.

Riccardo Mottola <rmottola>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

Only logged-in users can vote.

 

Follow 4 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2005-06-05 CaS Open/ClosedIn Test Closed
2004-11-21 CaS StatusNone Fixed
    Assigned toNone CaS
    Open/ClosedOpen In Test

Back to the top

Powered by Savane 3.13-02a9.
Corresponding source code