Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 589683 - Broker misconfiguration causes broker stop to fail
Broker misconfiguration causes broker stop to fail
Status: CLOSED UPSTREAM
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: qpid-cpp (Show other bugs)
Development
All Linux
medium Severity medium
: 1.3
: ---
Assigned To: Kim van der Riet
MRG Quality Engineering
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-06 13:10 EDT by Kim van der Riet
Modified: 2011-07-15 15:15 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-07-15 15:15:20 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 Kim van der Riet 2010-05-06 13:10:31 EDT
If the broker configuration file /etc/qpidd.conf is misconfigured, the broker will start, but it cannot be stopped again (using service stop).

Starting with clean /var/lib/qpidd and /var/run/qpidd dirs:

[root@mrg10 ~]# cat /etc/qpidd.conf 
cluster-mechanism=ANONYMOUS
auth=no
log-enable=info+
log-to-file=test.log
[root@mrg10 ~]# service qpidd start
Starting Qpid AMQP daemon: 2010-05-06 12:50:27 info Loaded Module: /usr/lib64/qpid/daemon/replication_exchange.so
2010-05-06 12:50:27 info Loaded Module: /usr/lib64/qpid/daemon/msgstore.so
2010-05-06 12:50:27 info Loaded Module: /usr/lib64/qpid/daemon/acl.so
2010-05-06 12:50:27 info Loaded Module: /usr/lib64/qpid/daemon/replicating_listener.so
                                                           [  OK  ]
Unexpected error: Can't open log file: test.log
[root@mrg10 ~]# service qpidd stop
Stopping Qpid AMQP daemon:                                 [FAILED]
[root@mrg10 ~]# ps -eaf | grep qpidd
qpidd     4870     1  0 12:50 ?        00:00:00 /usr/sbin/qpidd --daemon --pid-dir /var/run/qpidd --data-dir /var/lib/qpidd
root      4899  3322  0 12:52 pts/0    00:00:00 grep qpidd

NOTE 1: In spite of the broker error above, the log file is in fact created in the defualt directory (/var/lib/qpidd/test.log).

NOTE 2: Changing the config file to an absolute path (log-to-file=/var/lib/qpidd/test.log) fixes the broker startup error; in this case the service stop works ok.

NOTE 3: Both these cases place a pid file /var/run/qpidd/qpidd.5672.pid which contains a binary PID number. However, if the config file is fixed as in NOTE 2, then in addition a second pid file is created: /var/run/qpidd.pid which contains a string representation of the PID. It is likely this second file which causes the service stop to fail.
Comment 1 Kim van der Riet 2010-05-06 13:12:23 EDT
Tested on RHEL-6 using qpid-cpp-server-0.7.935473-1.el6.x86_64 and its dependents.
Comment 2 Kim van der Riet 2010-06-10 15:49:55 EDT
This is a much narrower, but more complex case than I initially thought.

The use of the "log-to-file" option in the config file is the source of this error. Genuine configuration file errors are either ignored or result in a failure to start the daemon in the first place.

When the broker daemon is started, it reads the config file and opens the log file as expected. This also creates an empty pid file. The startup script then uses "qpidd --check" to get the PID and write it into the empty pid file. This instance of qpidd reads the same config file and then attempts to open the same log file as the broker itself, causing it to fail with the message "Unexpected error: Can't open log file: test.log" (in the example above). This failure in turn leaves the pid file empty, and hence the use of "service stop" fails.

There is no simple solution to this that is not "hacky".

Ideally, this should be solved within qpidd itself - for instance if the daemon service options --quit or --check are used, then logging and module loading should be disabled.
Comment 3 Kim van der Riet 2010-06-11 08:53:30 EDT
Ignore analysis in comment #2 above - incorrect conclusion.

Absolute paths work ok. It turns out that using log-to-file without an absolute path causes the "qpidd --check" to run in the incorrect directory and for which it does not have permissions to write, hence the failure.

Adding a "-" to the runuser in the command solves the problem, ie changing

runuser -s /bin/sh qpidd -c "/usr/sbin/$prog --check > $pidfile"

to

runuser - -s /bin/sh qpidd -c "/usr/sbin/$prog --check > $pidfile"

(thanks, Gordon!)

Fixed in r.953687

[Upstream jira QPID-2666]

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