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
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
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
On 02/18/2011 10:08, Rick Macklem wrote:
The attached patches changes the behaviour so that it tries to
get an unused port for each of the 4 cases.
can you send me the patches?
thanks,
danny
They're attached. If you get to test them, please let me know
how it goes.
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
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
On 03/12/2011 14:56, Rick Macklem 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
On 02/18/2011 10:08, Rick Macklem wrote:
The attached patches changes the behaviour so that it tries to
get an unused port for each of the 4 cases.
can you send me the patches?
thanks,
danny
They're attached. If you get to test them, please let me know
how it goes.
rick
On 02/18/2011 10:08, Rick Macklem wrote:
The attached patches changes the behaviour so that it tries to
get an unused port for each of the 4 cases.
can you send me the patches?
thanks,
danny
They're attached. If you get to test them, please let me know
how it goes.
rick
Hi Rick,
Under 8.2-PRERELEASE (GENERIC kernel), about 15% of the times I boot up
(with rpc.statd and rpc.lockd enabled in rc.conf), I get:
Feb 4 07:31:11 wonderland rpc.statd: bindresvport_sa: Address already in use
Feb 4 07:31:11 wonderland root: /etc/rc: WARNING: failed to start statd
and
On 03/09/11 03:09, Daniel Braniss wrote:
Under 8.2-PRERELEASE (GENERIC kernel), about 15% of the times I boot up
(with rpc.statd and rpc.lockd enabled in rc.conf), I get:
Feb 4 07:31:11 wonderland rpc.statd: bindresvport_sa: Address already in use
Feb 4 07:31:11 wonderland root: /etc/rc:
On Wed, Mar 09, 2011 at 07:07:26AM -0500, George Mitchell wrote:
On 03/09/11 03:09, Daniel Braniss wrote:
Under 8.2-PRERELEASE (GENERIC kernel), about 15% of the times I boot up
(with rpc.statd and rpc.lockd enabled in rc.conf), I get:
Feb 4 07:31:11 wonderland rpc.statd: bindresvport_sa:
Thanks for the analysis. The reason I originally posted is to see why
this might have popped up in 8.x, as it never happened in 7.x.
-- George Mitchell
I suspect two things make this occur more frequently with 8.x. One is
that it does IPv6 first (I suspect IPv6 wasn't enabled by default on
Thanks for the analysis. The reason I originally posted is to see why
this might have popped up in 8.x, as it never happened in 7.x.
-- George Mitchell
I suspect two things make this occur more frequently with 8.x. One is
that it does IPv6 first (I suspect IPv6 wasn't enabled by
On 02/17/11 22:06, Andrea Venturoli wrote:
I
seem to remember a similar problem I had a long time ago. I opted to
use a consistent, not-used port and haven't seen the problem since
(this was years ago, so I can't remember if the error you're seeing
was identical to mine).
/etc/rc.conf:
Hi--
On Feb 19, 2011, at 1:16 PM, Rick Macklem wrote:
Well, that was what I was proposing. I could be wrong, but as far as
I
know, this is allowed by Sun RPC. The port#s are assigned
dynamically and
registered with rpcbind. (I don't necessarily agree with the design,
but
this
On 02/19/2011 13:16, Rick Macklem wrote:
On 02/18/2011 10:08, Rick Macklem wrote:
The attached patches changes the behaviour so that it tries to
get an unused port for each of the 4 cases.
Am I correct in assuming that what you're proposing is to
(potentially)
have different ports
On 02/18/2011 10:08, Rick Macklem wrote:
The attached patches changes the behaviour so that it tries to
get an unused port for each of the 4 cases.
Am I correct in assuming that what you're proposing is to
(potentially)
have different ports for all 4 combinations? I would suggest that
On 02/19/2011 13:16, Rick Macklem wrote:
On 02/18/2011 10:08, Rick Macklem wrote:
The attached patches changes the behaviour so that it tries to
get an unused port for each of the 4 cases.
Am I correct in assuming that what you're proposing is to
(potentially)
have different ports for all 4
Hi--
On Feb 19, 2011, at 1:16 PM, Rick Macklem wrote:
Well, that was what I was proposing. I could be wrong, but as far as I
know, this is allowed by Sun RPC. The port#s are assigned dynamically and
registered with rpcbind. (I don't necessarily agree with the design, but
this was/is how Sun
I've seen this intermittently for mountd. I think the problem is that
the code finds an unused port for udp/ip6 and then tries to use the
same port# for tcp/ip6, udp/ip4, tcp/ip4. All three daemons have
essentially the same function for doing this.
The attached patches changes the behaviour so
On 02/18/2011 10:08, Rick Macklem wrote:
The attached patches changes the behaviour so that it tries to
get an unused port for each of the 4 cases.
Am I correct in assuming that what you're proposing is to (potentially)
have different ports for all 4 combinations? I would suggest that this
On 02/17/11 04:28, Jeremy Chadwick wrote:
On Wed, Feb 16, 2011 at 09:46:37PM -0500, Michael Proto wrote:
On Wed, Feb 9, 2011 at 9:20 AM,george+free...@m5p.com wrote:
Under 8.2-PRERELEASE (GENERIC kernel), about 15% of the times I boot up
(with rpc.statd and rpc.lockd enabled in rc.conf), I
On Wed, Feb 9, 2011 at 9:20 AM, george+free...@m5p.com wrote:
Under 8.2-PRERELEASE (GENERIC kernel), about 15% of the times I boot up
(with rpc.statd and rpc.lockd enabled in rc.conf), I get:
Feb 4 07:31:11 wonderland rpc.statd: bindresvport_sa: Address already in use
Feb 4 07:31:11
On Wed, Feb 16, 2011 at 09:46:37PM -0500, Michael Proto wrote:
On Wed, Feb 9, 2011 at 9:20 AM, george+free...@m5p.com wrote:
Under 8.2-PRERELEASE (GENERIC kernel), about 15% of the times I boot up
(with rpc.statd and rpc.lockd enabled in rc.conf), I get:
Feb 4 07:31:11 wonderland
Under 8.2-PRERELEASE (GENERIC kernel), about 15% of the times I boot up
(with rpc.statd and rpc.lockd enabled in rc.conf), I get:
Feb 4 07:31:11 wonderland rpc.statd: bindresvport_sa: Address already in use
Feb 4 07:31:11 wonderland root: /etc/rc: WARNING: failed to start statd
and slightly
On 02/09/11 15:20, george+free...@m5p.com wrote:
Under 8.2-PRERELEASE (GENERIC kernel), about 15% of the times I boot up
(with rpc.statd and rpc.lockd enabled in rc.conf), I get:
Feb 4 07:31:11 wonderland rpc.statd: bindresvport_sa: Address already in use
Feb 4 07:31:11 wonderland root:
27 matches
Mail list logo
