TCP Port Capture

Doug Hardie bc979 at
Tue Jan 28 04:54:23 UTC 2014

On 27 January 2014, at 16:59, kpneal at wrote:

> On Mon, Jan 27, 2014 at 01:41:32AM -0800, Doug Hardie wrote:
>> I have a process that is occasionally giving me a situation that I don't understand.  It listens to a well-known port and processes requests received on that report.  It does return data to the calling system.  When a request is received, a child process is created that actually does most of the work.  The child process uses another process via a pipe during the processing to obtain some data it uses.
>> Occasionally, the main process exits with nothing logged.  I suspect its doing an exit, but thats just a guess at this time.  Some of the time (fairly infrequently), the main process cannot be restarted.  The process at the end of the pipe is now shown as having the port open.  lsof shows that.  If I restart that process, then the main process can be restarted properly.
>> Why would the process at the end of the pipe end up being attached to the port?  Unfortunately, the system always seems to be quiet (no requests in process) when this happens so nothing is logged by any process.  Normally I have a monitoring process that detects the main process being gone and restarts it.  But that doesn't work when the port is held by the final process.
> It sounds like the process at the end of the pipe has inherited the network
> ports that are open in the parent at the time the process is created.
> When using fork() the child process has all the same open files (including
> network connections and ports) as the parent. And after using one of the
> exec family of functions the child process _still_ has all the open files
> it had before the exec.
> Good housekeeping is in order when creating child processes. Before doing
> the exec of the program at the end of the pipe that process should close
> all files that are not needed by the pipe-writing-program.

That appears to be a reasonable explanation.  I don't know if I have access to all the source, but I will see if I  can trace that out.  Thanks.

More information about the freebsd-questions mailing list