Bug 60807

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):


How reproducible:
Always

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
descriptors
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.

Additional info:

This was with:
apache-1.3.20
php-4.0.6
netkit-base-0.17