Re: Need help understanding this message
On Mon, Mar 02, 2009 at 08:37:50AM -0700, Paul E Condon <pecondon@mesanetworks.net> was heard to say:
> /usr/bin/updatedb.mlocate: `/var/lib/mlocate/mlocate.db' is locked (probably by
> +an earlier updatedb)
(snip)
> LOCKFILE="/var/lib/mlocate/daily.lock"
>
> trap "rm -f $LOCKFILE" EXIT
(snip)
I don't know mlocate, but I can answer a few questions right away:
> The reported event happens early in the morning. When I first check my
> email, I immediately check for a lock file where this little script is
> programmed to place it. It does not exist. I also note that the error
> message that this script is programmed to issue, is not the error
> message that I actually recieve in the email.
Probably the error message is coming from /usr/bin/updatedb.mlocate.
It sounds like it's trying to lock a database file and finding out that
it's already locked. I don't know the program well enough to know what
mechanism it uses, but there are two basic types of locks:
(a) lock files, like /var/lib/mlocate/daily.lock. These can be left
behind when a process is interrupted while it's running. I would
look for something in /var/lib/mlocate whose name sounds like
it's a lock file.
(b) kernel locks (fcntl, flock, etc). These will go away when the
process that allocated them exits (barring weirdness related to
NFS, but I doubt you have /var on a network filesystem :) ) You
can use fuser(1) to find out which process has an open file
descriptor to mlocate.db (locks are associated with file
descriptors).
> mlocate.db has an mtime
> stamp from Feb 25, so clearly I need to fix something, but what? The
> code of the script /etc/cron.daily/mlocate is exactly the same on all
> three machines. Could a bad execution of 'trap' somehow corrupted an
> OS internal table?
"trap" is a shell command that tells it what to do when it receives
a signal (or a pseudo-signal like EXIT that's internal to the shell).
All things are possible, but it is beyond unlikely that it has
anything to do with what you're seeing.
> How can I check what traps are set?
Type "trap -p" -- but note that because this is a shell command, it
will print nothing outside the shell you set the trap in. (see
"help trap")
> Where is the
> message, that I get, actually being generated?
Probably /usr/bin/updatedb.mlocate.
> Etc.? I suppose I could
> just reboot the machine, but I'd like to understand.
Unless there is an updatedb.mlocate process hanging out somewhere
with a lock on the file (option (b) above), rebooting probably won't
help. If there is, it's easier to track it down and kill it (and find
out why it got stuck, ideally)
Daniel
Reply to: