statd/lockd startup failure

[Doug Barton]

On 03/13/2011 08:23, Daniel Braniss wrote:
>> 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.

And what I'm asking is that you describe the circumstances which might 
lead to that failure.

>>> 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."

Yeah, I saw that, did you see my response? I'm very much in favor of 
keeping things simple, but only as simple as they can be made.

>> 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 :-),

Clearly you've not spent any significant amount of time trying to figure 
out what traffic is coming from what port. A small increase in code 
complexity is worth it if it saves real people real time, especially in 
critical situations.

> 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.

Some of us are not so lucky. :)


Doug

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/