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): /etc/cron.daily/man-db.cron How reproducible: Always 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. 2. 3. Actual results: Expected results: Additional info: 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.
Hello, I can't reproduce this issue. Please, attach following files: /etc/cron.daily/man-db.cron /etc/sysconfig/man-db and output of: # mandb -d Thanks, peter
Created attachment 597569 [details] here it is, tar'gzed Made with: 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 real 16m47.778s user 2m4.905s sys 9m25.565s # time mandb -d >& /dev/null real 0m14.615s user 0m3.097s sys 0m1.136s
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! peter
fixed in: man-db-2.6.2-2.fc18 http://koji.fedoraproject.org/koji/buildinfo?buildID=330275
man-db-2.6.0.2-7.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/man-db-2.6.0.2-7.fc17
Package man-db-2.6.0.2-7.fc17: * 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-2.6.0.2-7.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-10644/man-db-2.6.0.2-7.fc17 then log in and leave karma (feedback).
man-db-2.6.0.2-7.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.