Bug 140299 - makewhatis.cron should be revised
makewhatis.cron should be revised
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: man (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ivana Varekova
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-11-22 01:51 EST by ilja lunev
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-08 07:28:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description ilja lunev 2004-11-22 01:51:19 EST
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:
Comment 1 ilja lunev 2004-11-22 04:19:40 EST
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

Comment 2 Ivana Varekova 2005-03-22 04:20:18 EST
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
Comment 3 Ivana Varekova 2005-04-08 07:28:35 EDT
If there are no further comments there is not bug. (see my first comment)
Ivana Varekova 
Comment 4 ilja lunev 2005-04-14 07:11:18 EDT
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.


Note You need to log in before you can comment on or make changes to this bug.