[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Gnats database locked error

From: Chad Walstrom
Subject: Re: Gnats database locked error
Date: Wed, 24 May 2006 11:00:41 -0500

"Walter Faleiro" <address@hidden>  wrote:
> We have been using gnats-3.1.113 for our bug tracking for a while.
> Of late the gnats database gets locked. When a user tries to create
> or edit a PR, it gives the messages GNATS database is locked. It
> unlocks after we execute the command pr-edit --unlockdb.  Is there
> any way to test maybe via a script run at intervals, to test if the
> Database is locked and if yes then execute the command pr-edit
> --unlockdb.  That said, I am also eager to know the cause of this
> frequent lock.
> Thanks and regards --Walter

Sorry about the long delay in replying, Walter.  I would suggest
writing a simple cron script that attempts to lock and unlock the
database, or perhaps just run the check-db script more often than once
per day.

If you're trying to avoid having to unlock the DB manually, I would
urge you to reconsider.  The problem with arbitrarily unlocking the
database is that you run the risk of corrupting data (mainly the index
file generation script, gen-index).  The database gets locked usually
for maintenance operations.  When editing a PR, only the PR itself
gets locked.

check-db attempts to lock the DB, and if it cannot, emails the
administrator.  If it can lock the DB, it checks to see if there are
locks on any PR's, reports on them.  Next, it regenerates the index
file.  Finally, it unlocks the DB and allows new PR's to be entered.

If you know check-db isn't running and gen-index isn't running, it is
probably safe to unlock the DB, even if you don't know what's creating
it.  Try this for tracking down the problem.  Look at the timestamp of
the database lock file, and compare that to your syslog entries for
cron.  If it looks like it coincides with runs from check-db, then
perhaps you could run check-db manually with the "-x" switch to trace
each step in the shell and find out where it fails.

Chad Walstrom <address@hidden> 
           assert(expired(knowledge)); /* core dump */

reply via email to

[Prev in Thread] Current Thread [Next in Thread]