From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 Description of problem: The locking in makewhatis.cron should be improved (see example below). Also no cron job should produce output to STDOUT as all cron output gets mailed to the cron owner where it obscures real error messages. Output which contains just informational messages should be written to a log file. Thus makewhatis should be run without the -v option or output should be redirected to somewhere else than STDOUT. Here is my example of a reworked makewhatis.cron #!/bin/bash LOCKFILE=/var/lock/makewhatis.lock # the lockfile is not meant to be perfect, it's just in case the # two makewhatis cron scripts get run close to each other to keep # them from stepping on each other's toes. The worst that will # happen is that they will temporarily corrupt the database... echo $$ >> $LOCKFILE # add my ID to LOCKFILE [[ $(head -1 $LOCKFILE) = $$ ]] || exit 1 # exit if not locked by me trap "{ rm -f $LOCKFILE; exit 255; }" EXIT makewhatis -w exit 0 Version-Release number of selected component (if applicable): anacron-2.3-25.1 How reproducible: Always Steps to Reproduce: 1. Just make the cron job running 2. 3. Additional info:
My above example has a problem if a process dies without removing the lock file. Here is a better solution: echo $$ >> $LOCKFILE # add me to LOCKFILE while read PID do ps --pid $PID > /dev/null || continue # next if orphaned PID [[ $PID = $$ ]] || exit 1 # exit if locked by another PID done < $LOCKFILE # now I know it's my lock trap "rm -f $LOCKFILE" EXIT makewhatis -w exit
Thank you for your notice. At first makewhatis creates the whatis database. This database is in one exactly determined file. The LOCKFILE is used to blocked the situation when two separate makewhatis jobs touch this file together. (Before first makewhatis starts to change this database it tests if lock file did not exists and creates this lock file. The second makewhatis finds this lock file and finish.) Your suggestion would destroyed this lock. Secondly, makewhatis.cron runs makewhatis without -v option. In makewhatis.crondaily there is used command "makewhatis -w -u" and in makewhatis.cronweekly there is used command "makewhatis -w". Maybe I don't understand your notice. In this case can you please describe your suggestions in more detail. Ivana Varekova
If there are no further comments there is not bug. (see my first comment) Ivana Varekova
Sorry about the -v confusion. You are right that it is run with -w from cron. Regarding the lock file my solution does not allow starting two jobs concurrently. It sets a lock and a second instance will not run if the process which has been setting the lock is still running. My point is, that if the makewhatis job dies for whatever reason without removing its lock file there can be a deadlock. Thus if makewhatis.cron sees a lock file it should test if the process ID which originally had created the lock is still alive. If it is not, my makewhatis.cron assumes that it is a leftover lock of a dead process. Only in this case it removes the lock and sets its own lock to rebuild the whatis database.