[Bug 1160810] New: rabbitmq-server package should install sample config files
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1160810
Bug ID: 1160810
Summary: rabbitmq-server package should install sample config
files
Product: Fedora
Version: rawhide
Component: rabbitmq-server
Keywords: EasyFix, ZStream
Severity: low
Priority: low
Assignee: lemenkov(a)gmail.com
Reporter: jeckersb(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: afazekas(a)redhat.com, apevec(a)redhat.com,
dyocum(a)redhat.com, erlang(a)lists.fedoraproject.org,
hubert.plociniczak(a)gmail.com, jeckersb(a)redhat.com,
lars(a)redhat.com, lemenkov(a)gmail.com, lhh(a)redhat.com,
rhos-flags(a)redhat.com, rjones(a)redhat.com,
rohara(a)redhat.com, s(a)shk.io, sgordon(a)redhat.com,
yeylon(a)redhat.com
Depends On: 1134956
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1134956
[Bug 1134956] rabbitmq-server package should install sample config files
--
You are receiving this mail because:
You are on the CC list for the bug.
8 years, 5 months
[Bug 1104843] New: rabbitmqctl doesn't work
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1104843
Bug ID: 1104843
Summary: rabbitmqctl doesn't work
Product: Fedora
Version: 20
Component: rabbitmq-server
Severity: high
Priority: urgent
Assignee: hubert.plociniczak(a)gmail.com
Reporter: jeckersb(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: apevec(a)redhat.com, erlang(a)lists.fedoraproject.org,
fdinitto(a)redhat.com, hubert.plociniczak(a)gmail.com,
jeckersb(a)redhat.com, lemenkov(a)gmail.com,
lhh(a)redhat.com, rjones(a)redhat.com, s(a)shk.io
Depends On: 1104193
Blocks: 1083890
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1104193
[Bug 1104193] rabbitmqctl doesn't work
--
You are receiving this mail because:
You are on the CC list for the bug.
8 years, 6 months
[Bug 1148444] New: logrotation fails
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1148444
Bug ID: 1148444
Summary: logrotation fails
Product: Fedora EPEL
Version: epel7
Component: rabbitmq-server
Assignee: lemenkov(a)gmail.com
Reporter: Jan.van.Eldik(a)cern.ch
QA Contact: extras-qa(a)fedoraproject.org
CC: erlang(a)lists.fedoraproject.org,
hubert.plociniczak(a)gmail.com, jeckersb(a)redhat.com,
josh(a)fornwall.com, lemenkov(a)gmail.com,
rjones(a)redhat.com, s(a)shk.io
Description of problem:
Logrotation fails 100% because of old-style post-rotate command
Version-Release number of selected component (if applicable):
rabbitmq-server-3.1.5-7.el7.noarch
How reproducible:
100%
Steps to Reproduce:
[root@jcentos7-01 tmp]# logrotate -f /etc/logrotate.conf
The service command supports only basic LSB actions (start, stop, restart,
try-restart, reload, force-reload, status). For other actions, please try to
use systemctl.
error: error running shared postrotate script for '/var/log/rabbitmq/*.log '
[root@jcentos7-01 tmp]# cat /etc/logrotate.d/rabbitmq-server
/var/log/rabbitmq/*.log {
weekly
missingok
rotate 20
compress
delaycompress
notifempty
sharedscripts
postrotate
/sbin/service rabbitmq-server rotate-logs > /dev/null
endscript
}
[root@jcentos7-01 tmp]# /sbin/service rabbitmq-server rotate-logs > /dev/null
The service command supports only basic LSB actions (start, stop, restart,
try-restart, reload, force-reload, status). For other actions, please try to
use systemctl.
[root@jcentos7-01 tmp]# echo $?
2
--
You are receiving this mail because:
You are on the CC list for the bug.
8 years, 6 months
[Bug 1144100] New: rabbitmq restarts fail randomly
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1144100
Bug ID: 1144100
Summary: rabbitmq restarts fail randomly
Product: Fedora EPEL
Version: epel7
Component: rabbitmq-server
Assignee: lemenkov(a)gmail.com
Reporter: bnemec(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: bnemec(a)redhat.com, erlang(a)lists.fedoraproject.org,
extras-qa(a)fedoraproject.org,
hubert.plociniczak(a)gmail.com, imcleod(a)redhat.com,
jeckersb(a)redhat.com, josh(a)fornwall.com,
lemenkov(a)gmail.com, lnie(a)redhat.com,
ohadlevy(a)redhat.com, rjones(a)redhat.com, s(a)shk.io
Depends On: 1059028
+++ This bug was initially created as a clone of Bug #1059028 +++
This still appears to be a problem in the EPEL version of rabbitmq-server.
Description of problem:
I originally encountered this issue when installing OpenStack via devstack but
have since been able to reproduce it by simply executing commands inside of a
fresh F20 install.
Version-Release number of selected component (if applicable):
rabbitmq-server-3.1.5-1.fc20.noarch
How reproducible:
Occurs regularly but not 100% of the time
Steps to Reproduce:
/sbin/service rabbitmq-server stop
/sbin/service rabbitmq-server start
rabbitmqctl change_password guest newpassword
Actual results:
About half the time, on a freshly installed F20, this will fail, claiming the
node cannot be contacted. A typical error message:
[root@cob-dell5 ~]# rabbitmqctl change_password guest ozrootpw
Changing password for user "guest" ...
Error: unable to connect to node 'rabbit@cob-dell5': nodedown
DIAGNOSTICS
===========
nodes in question: ['rabbit@cob-dell5']
hosts, their running nodes and ports:
- cob-dell5: [{rabbitmqctl2648,48609}]
current node details:
- node name: 'rabbitmqctl2648@cob-dell5'
- home dir: /var/lib/rabbitmq
- cookie hash: 8DNoVu56TqDYWypW7YXDJw==
Expected results:
Changing password for user "guest" ...
...done.
--- Additional comment from Ian McLeod on 2014-01-28 21:36:45 EST ---
See the following thread on rdo-list for another example of this issue:
https://www.redhat.com/archives/rdo-list/2013-December/msg00058.html
As well as this more recent one, indicating tha the problem persists:
https://www.redhat.com/archives/rdo-list/2014-January/msg00164.html
--- Additional comment from Ian McLeod on 2014-02-27 17:51:21 EST ---
Note to anyone following. The devstack installer has a commit that attempts to
workaround this issue by retrying the rabbitmq restart:
https://github.com/openstack-dev/devstack/commit/f6c001faf6ac5728e07c6bbd...
Still, it would be nice to sort this out on the rabbitmq side eventually.
--- Additional comment from Fedora Admin XMLRPC Client on 2014-07-01 13:58:36
EDT ---
This package has changed ownership in the Fedora Package Database. Reassigning
to the new owner of this component.
--- Additional comment from Fedora Update System on 2014-08-10 04:14:16 EDT ---
rabbitmq-server-3.1.5-9.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/rabbitmq-server-3.1.5-9.fc20
--- Additional comment from lnie on 2014-08-11 03:00:36 EDT ---
rabbitmq-server-3.1.5-9.fc20 works
--- Additional comment from Fedora Update System on 2014-08-14 22:35:38 EDT ---
Package rabbitmq-server-3.1.5-9.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing rabbitmq-server-3.1.5-9.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-9337/rabbitmq-server-...
then log in and leave karma (feedback).
--- Additional comment from Fedora Update System on 2014-08-15 20:28:02 EDT ---
rabbitmq-server-3.1.5-9.fc20 has been pushed to the Fedora 20 stable
repository. If problems still persist, please make note of it in this bug
report.
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1059028
[Bug 1059028] rabbitmq restarts fail randomly
--
You are receiving this mail because:
You are on the CC list for the bug.
8 years, 9 months
[Bug 1164006] New: wrong default EJABBERD_DOC_PATH
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1164006
Bug ID: 1164006
Summary: wrong default EJABBERD_DOC_PATH
Product: Fedora
Version: 20
Component: ejabberd
Severity: low
Assignee: lemenkov(a)gmail.com
Reporter: honza(a)slunceweb.cz
QA Contact: extras-qa(a)fedoraproject.org
CC: erlang(a)lists.fedoraproject.org, jkaluza(a)redhat.com,
lemenkov(a)gmail.com, martin(a)laptop.org
Description of problem:
Default EJABBERD_DOC_PATH in /usr/bin/ejabberdctl is /usr/share/doc/ejabberd,
but the documentation is in /usr/share/doc/ejabberd-doc.
Version-Release number of selected component (if applicable):
ejabberd-2.1.13-7.fc20.x86_64
How reproducible:
Always
Actual results:
Broken links in ejabberd Web Admin.
--
You are receiving this mail because:
You are on the CC list for the bug.
8 years, 9 months
[Bug 1138213] New: Rabbitmq cluster remains partitioned after short network partition incident
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1138213
Bug ID: 1138213
Summary: Rabbitmq cluster remains partitioned after short
network partition incident
Product: Fedora
Version: 20
Component: rabbitmq-server
Assignee: lemenkov(a)gmail.com
Reporter: jprovazn(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: erlang(a)lists.fedoraproject.org,
hubert.plociniczak(a)gmail.com, jeckersb(a)redhat.com,
lemenkov(a)gmail.com, rjones(a)redhat.com, s(a)shk.io
Description of problem:
In 3-node rabbitmq cluster after network partition happens and then when 3
nodes can communicate again, then cluster remains partitioned if
"pause_minority" policy is used.
This happens if network outage is short enough (~60secs), for longer outages
(>3 minutes) cluster was reconstructed properly. Very similar issue was
reported here:
http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2014-March/034639.html
This issue seems to be fixed in upstream already (not sure in which version
exactly, but 3.3.5 works fine).
Version-Release number of selected component (if applicable):
rabbitmq-server-3.1.5-9.fc20.noarch
Steps to Reproduce:
1. create 3-node cluster, use "pause_minority" no-quorum policy
2. stop networking on one of nodes and wait until the node is seen as shutdown
on other nodes
3. start networking on the node again
Actual results:
Cluster remains partitioned:
[root@overcloud-controller1-csugetg5pjql ~]# rabbitmqctl cluster_status
Cluster status of node 'rabbit@overcloud-controller1-csugetg5pjql' ...
[{nodes,
[{disc,
['rabbit@overcloud-controller0-o6yt2gtaxk6g',
'rabbit@overcloud-controller1-csugetg5pjql',
'rabbit@overcloud-controller2-z3tswnamdzhq']}]},
{running_nodes,
['rabbit@overcloud-controller0-o6yt2gtaxk6g',
'rabbit@overcloud-controller1-csugetg5pjql']},
{partitions,
[{'rabbit@overcloud-controller0-o6yt2gtaxk6g',
['rabbit@overcloud-controller2-z3tswnamdzhq']},
{'rabbit@overcloud-controller1-csugetg5pjql',
['rabbit@overcloud-controller2-z3tswnamdzhq']}]}]
...done.
Expected results:
no partitiones after the node is up again
Additional info:
only related message in log:
Mnesia('rabbit@overcloud-controller0-o6yt2gtaxk6g'): ** ERROR ** mnesia_event
got {inconsistent_database, running_partitioned_network,
'rabbit@overcloud-controller2-z3tswnamdzhq'}
--
You are receiving this mail because:
You are on the CC list for the bug.
8 years, 9 months