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
--
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
