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