Bug 485429
| Summary: | qpidd stopped by critical Broker start-up failed: Cannot lock ... Resource temporarily unavailable | ||
|---|---|---|---|
| Product: | Red Hat Enterprise MRG | Reporter: | Frantisek Reznicek <freznice> |
| Component: | qpid-cpp | Assignee: | Andrew Stitcher <astitcher> |
| Status: | CLOSED NOTABUG | QA Contact: | Frantisek Reznicek <freznice> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 1.1 | CC: | esammons, gsim, jonathan.robie |
| Target Milestone: | 1.3 | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2010-09-29 12:50:44 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Frantisek Reznicek
2009-02-13 15:30:16 UTC
Did this occur on an NFS filesystem? I managed to trigger this on mrg2, launching qpidd with & instead of -d: /usr/sbin/qpidd -p 6672& /usr/sbin/qpidd -p 7672& /usr/sbin/qpidd -p 8672& ./runSample.sh org.apache.qpid.example.jmsexample.direct.Listener& ./runSample.sh org.apache.qpid.example.jmsexample.direct.Producer 1000000& sleep 1 /usr/sbin/qpidd -p 5672 -q sleep 1 /usr/sbin/qpidd -p 7672 -q sleep 1 /usr/sbin/qpidd -p 6672 -q sleep 1 /usr/sbin/qpidd -p 5672& sleep 1 /usr/sbin/qpidd -p 8672 -q Changing this to the following solved the problem: /usr/sbin/qpidd -p 6672 -d /usr/sbin/qpidd -p 7672 -d /usr/sbin/qpidd -p 8672 -d Reporting in case this gives any useful hints ... The only feasible way you can get this error is if there is already a running qpidd which has the lock file locked already. So, given that if the taking the lock fails the broker startup immediately fails it might be that there is a slow to exit broker still running. It may be that we're not using the best available lock file approach. The issue has been not seen for couple of months. The posts above and my observation leads me to the conclusion that multiple qpidd were run on the same data-directory. Anyone against for CLOSE/NOTABUG? I think there is a very good chance that this bug was fixed by checkin r824894. Before this was fixed it was much more likely that tests started a new broker in the same data dir before the previous one had actually exited. So I'm changing to MODIFIED My understanding of the scenarios from description and comment 2 is that in both cases there are run multiple brokers (in non-daemon mode) on the same data-dir directory. I believe this is incorrect. The long term test shows that - single instance run in non-daemon mode on background - single instance run in daemon mode are able to start-up / stop (qpidd -q / kill) from existing / non-existing data-dir. Multiple qpidd instances cannot share the same data-dir and thus I'm proposing CLOSED/NOTABUG as the issue resolution. Could someone review my above lines, please? The review with Gordon proved that my understanding is correct. Therefore every qpidd instance should have it's dedicated data-dir storage. An attempt for running multiple qpidd instances on same data-dir rirectory causes "critical Broker start-up failed: Cannot lock .../lock: Resource temporarily unavailable" which is corrent behavior. Examination of above issue cases shows that multiple brokers were run on the same data-dir directory, which is incorrect. Testing proved that qpidd broker starts / stops well from empty / clean qpidd data-dir. I believe the above facts allow to close this defect as NOT-A-BUG. -> CLOSED/NOTABUG No release note required as there was no real bug fixed here |