Path: csiph.com!usenet.pasdenom.info!news.albasani.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Rainer Weikusat Newsgroups: comp.os.linux.development.apps Subject: Re: issue with tcp sockets on linux Date: Tue, 22 May 2012 20:45:17 +0100 Lines: 19 Message-ID: <87aa10t2ya.fsf@sapphire.mobileactivedefense.com> References: <87bolguxmp.fsf@sapphire.mobileactivedefense.com> <1ef15472-7d85-4890-9d65-886b85e72908@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: individual.net enWERTAOcVvPbxUbByzg3gyMuOUeI7xOWkyJSNbdrBvwv/WHBEpr60yyVHWiDFXNo= Cancel-Lock: sha1:HO+fEMLyUBl0Mq1k4uOwmyA+W7U= sha1:oHYP5fvKOZVL3g/cmn+0GwYPK5A= User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) Xref: csiph.com comp.os.linux.development.apps:481 GH writes: > On Tuesday, May 22, 2012 9:57:18 AM UTC-4, Rainer Weikusat wrote: >> The usual cause of this phenomenon would be that the server started >> another program which is still running and inherited the established >> socket because FD_CLOEXEC wasn't set. > > Thank you for your reply. It is very insightful although my > situation is not exactly as you described. My app does not call > exec() or similar ones. It does conditionally call fork() where the > child does not close() the open fd's. [Could you please order quoted text and new text in this way?] Since descriptors don't change at all accross a fork, that obviously suffers from the same issue. On linux, the netstat -np command could be used to determine which process keeps your connection open.