On Tue, 2017-09-05 at 11:25 +0100, Richard W.M. Jones wrote:
I've noticed for a while that updates get "stuck" in
the scriptlets
phase. For example I've got an update running now which has taken
3+ minutes of wallclock time (on a 16 core Xeon) in the scriptlets.
Looking in ‘top’ I can see:
29490 root 20 0 156620 28352 2684 S 25.7 0.0 1:41.52 mandb
I suspect this runs from the following trigger in the man-db package:
# update cache
%transfiletriggerpostun -- %{_mandir}
MAN_NO_LOCALE_WARNING=1 /usr/bin/mandb -q
It creates or updates a set of databases under /var/cache/man.
The databases are not used by the regular ‘man’ command. They are
only used by ‘apropos’ and ‘whatis’ which are (I suppose) quite rarely
used commands for searching all man pages.
You can prove this by moving /var/cache/man out of the way, and you'll
notice that ‘man’ continues to work just fine. However ‘whatis’
always prints ‘nothing appropriate’ if no database is available.
There is a man-db-cron package, although it's not installed by
default. Perhaps we could install the cron job by default and drop
the trigger?
It has been a thorn in the backside for a while:
https://bugzilla.redhat.com/show_bug.cgi?id=1318058
It does seem to make wholesale database rebuilds instead of partial
updates way too often.
-Yanko