Tom Horsley writes:
OK, I just updated my system and got the same
ridiculous delays I saw someone else complain about
That someone else was me, of course, and this was not rpcbind's fault. The
rpcbind package leaves it to systemd to close and reopen its listening
socket. This is, apparently, such a complicated process that it takes
systemd about three minutes to figure out how to do that for some reason.
The only fault that can be attributed to rpcbind here is the brilliant
decision to leave it to systemd to do this job, instead of doing it
correctly yourself.
Worse than that, when I rebooted to make sure
everything was loaded from scratch and up to
date, the reboot hung for about 3 minutes
saying a start job was running for man-db-cache-update
(or something like that).
Right. I haven't yet researched the full back story on that one, but I
distinctly recall a discussion some time ago about mandb being run for every
rpm package update, via some rpm macro, and that was somewhat inefficient.
The idea was to move man page caching out of the package installation, and
do it some other way. Apparently it was decided to do that during system
shutdown.
I'm sure that folks running on a UPS would appreciate a system shutdown
triggered by a power failure, by a low power alert from the UPS, now having
to wait until the man page cache gets updated.
What kind of moronic decision is it to postpone
a reboot while updating the man db? If there is
anything less critical I have a hard time thinking
what it is.
For gosh sakes, keep a flag somewhere that says if
the man db is up to date and update it on a timer
when the system is back up again if required.
Put "SERVICE=no" in /etc/sysconfig/man-db, to turn off this nuisance. Make
sure to get the latest batch of updates, because that setting was slightly
broken, and had to be fixed a few days ago.
After installing the latest update, be sure to run "systemctl daemon-reload".