The issue described here has caused problems for me for a long time.
- Small home server running lots of services: amd, apache24, ataidle, cupsd, dbus, delegate, dhcpd, dhcpd6, firewall, gateway, hald, hylafax, inetd, ipv6_gateway, kdm4, moused, mpd, mysql, named, nfs_client, nfs_server, nis_client, nis_server, nis_yppasswdd, ntpd, openvpn, postgresql, powerd, rpc_lockd, rpc_statd, rpcbind, rtadvd, rtsold, rwhod, samba_server, sendmail, squid, sshd, syslogd, winbindd, zfs
- Rather often (estimated 10% of all reboots) one of the daemons using random port numbers chooses one which is later on required by another daemon which needs a well-known port number to operate
- Example today: mountd listens on port 631 which is required by cups, therefore cups does not work
- Example from a few days ago: ypbind listens on 873 which is required by inetd configured to spawn rsync
- Ports should be chosen so as not to cause conflicts
Proposed mitigation measure: Revert to using well-known port numbers for standard system daemons like it was done ages ago.
This behavior is still a problem in 12.1 - every so often inetd cannot start some service, or some other service cannot start (for example dovecot) because its port is already used, for example by rpc.statd.
Daemons should listen on their default ports, not on random ports.
Unfortunately, RPC does not have default ports. They are picked up from a special range. It's been this way forever, AFAIK.
One "solution" is to request a fixed port for each RPC-based service if a service provides such option.
Another solution is to play with lowlast / lowfirst sysctl-s under net.inet.ip.portrange.
Another potential solution is to exclude all well-known ports (/etc/services) from RPC's use. That would automatically work for all but there can be some challenges.
If you are curious, please see IP_PORTRANGE_LOW in the source code.