Joe Pruett <[EMAIL PROTECTED]> writes: >>> well, it's a production box and only seems to show the problem at boot >>> time. from looking at the logs, i think this is the underlying >>> culprit: >>> >>> Sep 17 09:18:08 hyperion kernel: RPC: Can't bind to reserved port (98). >>> Sep 17 09:18:08 hyperion kernel: RPC: can't bind to reserved port. >>> Sep 17 09:18:08 hyperion kernel: RPC: error 5 connecting to server >>> jupiter.spiretech.com >>> Sep 17 09:18:08 hyperion kernel: RPC: Can't bind to reserved port (98). >>> Sep 17 09:18:08 hyperion kernel: RPC: can't bind to reserved port. >>> Sep 17 09:18:08 hyperion kernel: RPC: error 5 connecting to server >>> jupiter.spiretech.com >> >>> that is from the client trying to talk to the server. >> >> That's strange. Errno 98 is EADDRINUSE. So, this means that you cycled >> through the entire port range and all of the ports were bound. Do you >> do a lot of mounts upon boot? Can you try tweaking sunrpc.min_resvport >> and sunrpc.max_resvport? Max can't be more than 1023. Try pushing min >> down to 500 or so. > > i have run into this kind of problem in the past (running out of > privileged ports). i found some code in glibc that seemed to be the > biggest problem and never got around to trying to fix it. i'll look > at what my current settings are and see about tweaking them.
Details would be welcome. The biggest offender we found was that the portmapper interfaces would use reserved ports. That is simply not necessary, and those issues have been fixed in autofs and mount.nfs. In fact, we've got regression tests that make sure that this is the case. Cheers, Jeff _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
