statd/lockd startup failure
Daniel Braniss
danny at cs.huji.ac.il
Sun Mar 13 15:23:56 UTC 2011
> On 03/12/2011 02:21, Daniel Braniss wrote:
> > The problem with trying to get the same port for all tcp/udp/inet/inet6
> > though might succeed most of the time, will fail sometimes, then what?
>
> Can you please describe the scenario when it's completely impossible to
> find a port that's open on all 4 families?
i did not say impossible, concidering that Rick asked how many times he
should try, unless N is forever, it could fail.
>
> > I saw Doug's commnent, and also the:), it's not as simple as tracking port
> > 80 or 25, needs some efford, but it's deterministic/programable, and worst case
> > you can still use the -p option (which again will fail sometimes:-).
>
> Given that Rick has already written the patch, I don't think it's at all
> unreasonable to put it in as the first choice, perhaps with a fallback
> to picking any available port if there isn't one available for all 4
> families.
>
as Rick mentioned, the patch is not trivial, and to quote him:
"My only concern with the "same port# patch" is that it is more complex
and, therefore, somewhat riskier w.r.t. my having gotten it wrong."
> Meanwhile, I don't think I'm the only person who has ever had trouble
> trying to track down network traffic from "random" ports that would
> prefer that doing so not be made harder by having the same service on
> the same host using 4 different ports.
To track rpc based traffic, which means random-port to start with, you have to
check with rpcinfo anyways. So yes, it's harder than tracking 1 port, but
IMHO, less complex than the patch requiered :-), and BTW, mountd is already
heavely patched, rpc.statd less, and rpc.lockd is, so far, the only one
that is not complaining - guess Rick is a good programer!
and I concider myself lucky that we don't use NIS/yellow-pages.
danny
More information about the freebsd-stable
mailing list