Re: System freezes after "could not getpeername"

[Andreas Moroder <andreas.moroder@sb-brixen.it>]

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