Red Hat Bugzilla – Bug 829553
man-db's daily cron, excessive disk activity
Last modified: 2012-07-20 22:54:26 EDT
Description of problem:
/etc/cron.daily/man-db.cron seems to run everyday around 3 am local time, and it takes about half an hour full of disk activity. Is there any reason for this? I think it should be conditional on having new packages installed/removed since the last time it was run.
The reason why I am filing this bug is that occasionally I cross time zones and do not change the clock on my computer. 3am the computer's clock time may be day time where I am and need to get some work done. With man-db going crazy for half an hour and engaging the disk, it also affects virtual memory/swap and responsiveness to more important and interactive activities.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Just try manually running /etc/cron.daily/man-db.cron and see your productivity dropping and the responsiveness of the system dropping.
There should be no reason for updating the man database more frequently than package installation. i.e. it should be conditional to timestamps of /var/lib/rpm or something, since the last time it was run.
I can't reproduce this issue. Please, attach following files:
and output of:
# mandb -d
Created attachment 597569 [details]
here it is, tar'gzed
mandb -d 2>&1 | gzip > /tmp/mandb-d.gz
tar -czpvf /tmp/mandebug.gz /etc/cron.daily/man-db.cron /etc/sysconfig/man-db /tmp/mandb-d.gz
Thanks. Please, run and attach output of:
# mandb -cd
and then run and attach output of:
# time mandb -d
Did you see any improvement when you ran the second command now and before?
That appears to improves a lot.
# time mandb -cd >& /dev/null
# time mandb -d >& /dev/null
It looks like you had somehow corrupted man pages database. With command "mandb -c" you've recreated it and now it seems that the issue is gone. Could you observe some next cron job to confirm the problem is fixed?
(In reply to comment #5)
> It looks like you had somehow corrupted man pages database. With command
> "mandb -c" you've recreated it and now it seems that the issue is gone.
> Could you observe some next cron job to confirm the problem is fixed?
Quite possibly - I have had the same system for a while - upgraded for about 4 years. I only noticed the issue when I worked in a different time zone (where the old early morning is the middle of the new afternoon).
Interestingly I have the index.db from January (system backup), and its file magic is different from the newly rebuilt ones:
old/var/cache/man/index.db: GNU dbm 1.x or ndbm database, little endian
new/var/cache/man/index.db: \0 "ϚW\023"
Possibly an enhancement to wipe the database during the usual half-yearly upgrade?
Yeah, that's it - the database definitely changed in some update.
And yes, I am considering to recreate the database with every man-db package upgrade.
Thanks for your help!
man-db-220.127.116.11-7.fc17 has been submitted as an update for Fedora 17.
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing man-db-18.104.22.168-7.fc17'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
man-db-22.214.171.124-7.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.