Re: Conflicting assignment of priviledged ports on boot
> FWIW, this bug has only been reported once (and reassigned to portmap)
> see #261484
No. See also
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=306465
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=257876
In each thread several people report of similar problems.
> so its seems Debian users don't get beaten by this too often.
It occurs (alomst) only during startup, and only if you run a service that
starts early in the boot sequence and calls bindresvport (like ypbind)
which is usually only the case with servers.
I was bitten several times, but usually I just restarted a few services
until it worked. Once the server ran there were no more problems.
Bottomline: not every user is affected, but some are, and once they
are affected, it is likely that the problem persists: the boot sequence
is rather deterministic, so the clash will likely reoccur with every
boot.
> Yes, probably portreserve is the way to go. Although it might make sense to
> coordinate this with other distros.
Well, the problem has been around since at least 2002, so I'd prefer to start
doing something about it.
> In any case, this means changing
> a number of packages (cupsys, IMAP/POP3 daemons, Ldap daemons) that
> need to use RPC services and start _after_ those in the init sequence.
> Maybe when somebody goes ahead and adds initscripts dependencies, as suggested
> by Petter Reinholdtsen for LSB 3.0 compliance, we can have a good
> understanding of what packages would need to be changed.
The nice thing about portreserve/portrelease is that we don't need to
have a good understanding. Modifying a package is safe: even if it starts
long before nis nothing bad happens if the port is handled by portreserve.
And if we miss to modify a package, we are no worse off than now.
In fact, we are better off, because we will have an address where to send
the bug report, namely to the package maintainer. Currently cups/ldap/...
blames nis, and nis/... blames portmap, portmap blames glibc, and there
are good reasons to leave glibc as it is.
Gernot
Reply to: