Bug 458466 - RHEL5: qpidd server fails to start -- Data directory is locked by another process:
RHEL5: qpidd server fails to start -- Data directory is locked by another pro...
Status: CLOSED ERRATA
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: qpid-cpp (Show other bugs)
1.0
x86_64 Linux
urgent Severity high
: 1.0.1
: ---
Assigned To: Ted Ross
Kim van der Riet
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-08-08 13:00 EDT by Ted Ross
Modified: 2008-10-06 15:08 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-10-06 15:08:58 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 Ted Ross 2008-08-08 13:00:20 EDT
+++ This bug was initially created as a clone of Bug #458401 +++

Description of problem:
Startup of the qpidd service fails with:

[root@xxx]: /etc/init.d/qpidd start
Starting Qpid AMQP daemon: Daemon startup failed: Data directory is locked by another process: /var/lib/qpidd
                                                           [FAILED]
[root@xxx]: 

Version-Release number of selected component (if applicable):
qpidd-0.2.667603-2.fc8.x86_64

How reproducible:
100%

Steps to Reproduce:
1. 'service qpidd start'
2. reach over and un-plug the machine (force a crash)
3. after re-booting, the qpidd service refuses to start
  
Expected results:
The init scripts should somehow (?) realize that its a stale lock.

--- Additional comment from ed@eh3.com on 2008-08-08 10:15:52 EDT ---

After reading "src/qpid/DataDir.cpp" its obvious that:

  rm /var/lib/qpidd/lock

is a work-around for this problem.  But its *not* an actual fix.  Most 
users are not prepared to read C++ to figure out how to get the qpidd 
running after a system crash.

I think the real fix is to modify the /etc/init.d/qpidd startup script 
so that:

  0) it uses the $pidfile so it *knows* whether a qpidd process is 
     actually running or not
  1) if qpidd is not running, then delete the /var/lib/qpidd/lock
     before trying to start a new one
Comment 2 Frantisek Reznicek 2008-09-12 06:04:24 EDT
Verified manually and also using RHTS test (MRG_Messaging/qpid_start_fails_bz458466) which proves it on different machines. (ON_QA->VERIFIED)
Comment 4 errata-xmlrpc 2008-10-06 15:08:58 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2008-0640.html

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