Date: Mon, 27 Jan 2014 20:54:14 -0800 From: Doug Hardie <bc979@lafn.org> To: kpneal@pobox.com Cc: freebsd-questions <freebsd-questions@freebsd.org> Subject: Re: TCP Port Capture Message-ID: <E024B57B-B5A0-41B6-B58A-44B88940F3EA@lafn.org> In-Reply-To: <20140128005911.GA31430@neutralgood.org> References: <995B2B03-C742-4FF9-82FE-3D0EDA8529D2@lafn.org> <20140128005911.GA31430@neutralgood.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 27 January 2014, at 16:59, kpneal@pobox.com 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. >>=20 >> 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. >>=20 >> 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. >=20 > 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. >=20 > 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. >=20 > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E024B57B-B5A0-41B6-B58A-44B88940F3EA>