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

 
 

You are not allowed to post comments on this tracker with your current authentication level.

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

Submitted by:  Riccardo Mottola <rmottola>
Submitted on:  Thu 11 Nov 2004 10:55:06 AM UTC  
 
Category: Base/FoundationSeverity: 3 - Normal
Item Group: BugStatus: Fixed
Privacy: PublicAssigned to: Richard Frith-Macdonald <CaS>
Open/Closed: Closed

(Jump to the original submission 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>
Project MemberIn charge of this item.
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>
Project 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>
Project MemberIn charge of this item.
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>
Project MemberIn charge of this item.
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>
Project 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>
Project MemberIn charge of this item.
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>
Project Member

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

Do you think this task is very important?
If so, you can click here to add your encouragement to it.
This task has 0 encouragements so far.

Only logged-in users can vote.

 

Please enter the title of George Orwell's famous dystopian book (it's a date):

 

 

Follow 4 latest changes.

Date Changed By Updated Field Previous Value => Replaced By
Sun 05 Jun 2005 05:33:09 AM UTCCaSOpen/ClosedIn Test=>Closed
Sun 21 Nov 2004 08:43:12 AM UTCCaSStatusNone=>Fixed
  Assigned toNone=>CaS
  Open/ClosedOpen=>In Test

Back to the top


Powered by Savane 3.1-cleanup1