From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Moroder Subject: Re: System freezes after "could not getpeername" Date: Mon, 30 Aug 2010 11:59:02 +0200 Message-ID: References: Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-admin-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: linux-admin@vger.kernel.org Am 30.08.2010 11:01, schrieb terry white: > ... ciao: > > : on "8-30-2010" "Andreas Moroder" writ: > > : but there seems to be a correlation between the getpeername call in inted and > : the freeze of the machine, so I prefer to avoid inetd in this case . > > i tend to think that solution cosmetic at best, and at worst, a > misdirected effort. my reading of the 'inetd' manpage does not suggest > it calls 'getpeername', but insteat hands off connections to implied > servers. seems to me, 'getpeername' is more likely local to the > answering server, that's just a quess though. > > "having" to bypass inetd, is expedient, but not an elegant solution. > > for my part, i'd start looking at bind ... > > Hello Terry, I am sure you are right that this is not the solution but I hope that this way we have more time to find the true source of problems. out of our logilfe: inetd[1397]: could not getpeername according to this on other OSes getpeername is used http://fxr.googlebit.com/source/usr.sbin/inetd/inetd.c?v=OPENBSD-CURRENT so I suppose that this is true for linux too that inetd uses getpeername. Could you please explain me why you would start to look at bind ? One strange thing we also see on the machine ist that /proc/sys/fs/file-nr is constantly growing. May it be that getpeername did stop to work because it needed a filehandle and did not get it ? Thanks Andreas