FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian User

 
 
LinkBack Thread Tools
 
Old 03-02-2009, 02:37 PM
Paul E Condon
 
Default Need help understanding this message

The help I need is what I might call 'deep' help. I know 'who'
is sending the message, and why, but how do I fix the problem?

Included is an email that I get from the daily cron job on a
host that I have named 'gq'. I have two other machines that never send
this message. All are similarly configured Lenny installations.
This is the text of the email, including a few headers:
############################## start
From: Cron Daemon <root@gq.lan.gnu>
Date: Mon, 02 Mar 2009 04:41:00 -0700
To: root@gq.lan.gnu
Subject: Cron <root@gq> test -x /usr/sbin/anacron || ( cd / && run-parts
--report /etc/cron.daily )

/etc/cron.daily/mlocate:
/usr/bin/updatedb.mlocate: `/var/lib/mlocate/mlocate.db' is locked (probably by
+an earlier updatedb)
run-parts: /etc/cron.daily/mlocate exited with return code 1
################################################## ###(END)

I include here, for reference a copy of cron.daily/mlocate:
############################## start
#! /bin/bash

set -e

[ -x /usr/bin/updatedb.mlocate ] || exit 0

##

LOCKFILE="/var/lib/mlocate/daily.lock"

trap "rm -f $LOCKFILE" EXIT

if [ -e "$LOCKFILE" ]; then
echo >&2 "Warning: $LOCKFILE present, not running today."
exit 1
else
touch "$LOCKFILE"
fi

##

# See ionice(1)
if [ -x /usr/bin/ionice ] &&
/usr/bin/ionice -c3 true 2>/dev/null; then
IONICE="/usr/bin/ionice -c3"
fi

$IONICE /usr/bin/updatedb.mlocate
################################################## ###(END)

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. 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? How can I check what traps are set? Where is the
message, that I get, actually being generated? Etc.? I suppose I could
just reboot the machine, but I'd like to understand.

TIA
--
Paul E Condon
pecondon@mesanetworks.net


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 03-02-2009, 02:55 PM
Daniel Burrows
 
Default 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


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 01:10 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org