+++ 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 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
Verified manually and also using RHTS test (MRG_Messaging/qpid_start_fails_bz458466) which proves it on different machines. (ON_QA->VERIFIED)
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-0867.html