From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:0.9.8) Gecko/20020205
Description of problem:
A php script I had was exec'ing a program into the background, which eventually
called '/etc/rc.d/init.d/inet start'. When trying to restart the web server, it
failed with an error saying it could not bind to it's port. Examining the port
usage with 'fuser' showed that inetd was the program that was using the port.
If I run the same program from the command line, the web server is unaffected.
It appears that if file descriptors are not closed at some point along the way,
misbehaving daemon programs could bind to ports that they shouldn't by
inheriting file descriptors from their parent process.
Ideally this all gets fixed in the daemon itself or in the parent process that
is going to end up starting a daemon, but the daemon function in
/etc/rc.d/init.d/functions could provide some protection from this situation.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Exec a program from a php script that doesn't close any file descriptors
2.Start a daemon such as inetd that doesn't properly close all unnecessary file
3.Try to restart the web server that executed the php script
Actual Results: The web server failed to restart and the error log reported
that the server was unable to bind to it's listen port.
Expected Results: The web server restarts successfully.
This was with:
Created attachment 47700 [details]
possible fix for this bug
Closing out bugs on older, no longer supported releases. Apologies for any lack
of response. Please reopen if it persists on current releases.
Open or closed filedescriptors should not affect what port a daemon binds to.