erlang October 2014

erlang@lists.fedoraproject.org

9 participants
104 discussions

[Bug 1148444] New: logrotation fails
by Red Hat Bugzilla 01 Oct '15

01 Oct '15

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.

1 16

[Bug 1153839] New: CVE-2014-8760 ejabberd: clients can unexpectedly connect without encryption
by Red Hat Bugzilla 31 Jul '15

31 Jul '15

https://bugzilla.redhat.com/show_bug.cgi?id=1153839 Bug ID: 1153839 Summary: CVE-2014-8760 ejabberd: clients can unexpectedly connect without encryption Product: Security Response Component: vulnerability Keywords: Security Severity: medium Priority: medium Assignee: security-response-team(a)redhat.com Reporter: mmcallis(a)redhat.com CC: erlang(a)lists.fedoraproject.org, extras-orphan(a)fedoraproject.org, jkaluza(a)redhat.com, lemenkov(a)gmail.com, martin(a)laptop.org, mmahut(a)redhat.com It was reported that clients could unexpectedly connect without encryption: http://mail.jabber.org/pipermail/operators/2014-October/002438.html Upstream fix (master): https://github.com/processone/ejabberd/commit/7bdc1151b References: http://seclists.org/oss-sec/2014/q4/312 -- You are receiving this mail because: You are on the CC list for the bug.

1 6

[Bug 1144100] New: rabbitmq restarts fail randomly
by Red Hat Bugzilla 07 Jul '15

07 Jul '15

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/f6c001faf6ac5728e07c6bbdaa… 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-3.… 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.

1 10

[Bug 1138213] New: Rabbitmq cluster remains partitioned after short network partition incident
by Red Hat Bugzilla 29 Jun '15

29 Jun '15

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.

1 3

[Bug 1098806] New: [abrt] couchdb: __pthread_mutex_lock(): couchjs killed by SIGSEGV
by Red Hat Bugzilla 29 Jun '15

29 Jun '15

https://bugzilla.redhat.com/show_bug.cgi?id=1098806 Bug ID: 1098806 Summary: [abrt] couchdb: __pthread_mutex_lock(): couchjs killed by SIGSEGV Product: Fedora Version: 20 Component: couchdb Assignee: lemenkov(a)gmail.com Reporter: fedorabugs(a)aylett.co.uk QA Contact: extras-qa(a)fedoraproject.org CC: erlang(a)lists.fedoraproject.org, lemenkov(a)gmail.com Description of problem: Running the built-in installation verification, after adding an SELinux rule to work around #1098802. After the crash, one of the Erlang processes seemed to get stuck in a restart loop. Version-Release number of selected component: couchdb-1.5.0-1.fc20 Additional info: reporter: libreport-2.2.2 backtrace_rating: 4 cmdline: /usr/bin/couchjs /usr/share/couchdb/server/main.js crash_function: __pthread_mutex_lock executable: /usr/lib64/erlang/lib/couch-1.5.0/priv/couchjs kernel: 3.14.3-200.fc20.x86_64 runlevel: N 5 type: CCpp uid: 984 Truncated backtrace: Thread no. 1 (8 frames) #0 __pthread_mutex_lock at ../nptl/pthread_mutex_lock.c:66 #1 PR_Lock at ../../../nspr/pr/src/pthreads/ptsynch.c:177 #2 AutoLockGC at jscntxt.h:2601 #3 finish at jsgc.cpp:2048 #4 js_FinishGC at jsgc.cpp:869 #5 JSRuntime::~JSRuntime at jsapi.cpp:696 #6 JS_Finish at jsapi.cpp:763 #7 JS_Init at jsapi.cpp:753 -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1098802] New: SELinux alerts starting and running couchdb
by Red Hat Bugzilla 29 Jun '15

29 Jun '15

https://bugzilla.redhat.com/show_bug.cgi?id=1098802 Bug ID: 1098802 Summary: SELinux alerts starting and running couchdb Product: Fedora Version: 20 Component: couchdb Assignee: lemenkov(a)gmail.com Reporter: fedorabugs(a)aylett.co.uk QA Contact: extras-qa(a)fedoraproject.org CC: erlang(a)lists.fedoraproject.org, lemenkov(a)gmail.com Created attachment 896832 --> https://bugzilla.redhat.com/attachment.cgi?id=896832&action=edit Output of `sudo grep type=AVC /var/log/audit/audit.log` Description of problem: After installing couchdb in F20, when starting the service you get SELinux alerts. The web UI runs, but the internal self-test fails. Version-Release number of selected component (if applicable): Installed: couchdb.x86_64 0:1.5.0-1.fc20 Dependency Installed: erlang-asn1.x86_64 0:R16B-03.5.fc20 erlang-compiler.x86_64 0:R16B-03.5.fc20 erlang-crypto.x86_64 0:R16B-03.5.fc20 erlang-erts.x86_64 0:R16B-03.5.fc20 erlang-et.x86_64 0:R16B-03.5.fc20 erlang-gs.x86_64 0:R16B-03.5.fc20 erlang-hipe.x86_64 0:R16B-03.5.fc20 erlang-ibrowse.x86_64 0:2.2.0-8.fc20 erlang-inets.x86_64 0:R16B-03.5.fc20 erlang-kernel.x86_64 0:R16B-03.5.fc20 erlang-mnesia.x86_64 0:R16B-03.5.fc20 erlang-mochiweb.x86_64 0:2.4.2-3.fc20 erlang-oauth.x86_64 0:1.4.0-1.fc20 erlang-observer.x86_64 0:R16B-03.5.fc20 erlang-os_mon.x86_64 0:R16B-03.5.fc20 erlang-otp_mibs.x86_64 0:R16B-03.5.fc20 erlang-public_key.x86_64 0:R16B-03.5.fc20 erlang-runtime_tools.x86_64 0:R16B-03.5.fc20 erlang-sasl.x86_64 0:R16B-03.5.fc20 erlang-snappy.x86_64 0:1.0.3-0.5.git80db168.fc20 erlang-snmp.x86_64 0:R16B-03.5.fc20 erlang-ssl.x86_64 0:R16B-03.5.fc20 erlang-stdlib.x86_64 0:R16B-03.5.fc20 erlang-syntax_tools.x86_64 0:R16B-03.5.fc20 erlang-tools.x86_64 0:R16B-03.5.fc20 erlang-webtool.x86_64 0:R16B-03.5.fc20 erlang-wx.x86_64 0:R16B-03.5.fc20 erlang-xmerl.x86_64 0:R16B-03.5.fc20 lksctp-tools.x86_64 0:1.0.15-2.fc20 How reproducible: sudo systemctl start couchdb Browse to http://127.0.0.1:5984/_utils/verify_install.html and choose to verify your installation. Actual results: Three alerts in the SELinux Alert Browser Expected results: All operations succeed. Additional info: Output of `sudo grep type=AVC /var/log/audit/audit.log` attached. That output suggests there may be a conflict with my install of docker-io? -- You are receiving this mail because: You are on the CC list for the bug.

1 6

[Bug 1067367] New: [abrt] erlang-erts: wxEvtHandler::Disconnect(): beam.smp killed by SIGSEGV
by Red Hat Bugzilla 29 Jun '15

29 Jun '15

https://bugzilla.redhat.com/show_bug.cgi?id=1067367 Bug ID: 1067367 Summary: [abrt] erlang-erts: wxEvtHandler::Disconnect(): beam.smp killed by SIGSEGV Product: Fedora Version: 20 Component: erlang Assignee: lemenkov(a)gmail.com Reporter: razorpeak(a)gmail.com QA Contact: extras-qa(a)fedoraproject.org CC: erlang(a)lists.fedoraproject.org, lemenkov(a)gmail.com, rhbugs(a)n-dimensional.de, skottler(a)redhat.com Version-Release number of selected component: erlang-erts-R16B-03.1.fc20 Additional info: reporter: libreport-2.1.12 backtrace_rating: 4 cmdline: /usr/lib64/erlang/erts-5.10.4/bin/beam.smp -- -root /usr/lib64/erlang -progname erl -- -home /home/bikram -- -pa ebin -pa ../../deps/bullet/ebin ../../deps/cowboy/ebin ../../deps/dderloci/ebin ../../deps/erlimem/ebin ../../deps/erloci/ebin ../../deps/goldrush/ebin ../../deps/imem/ebin ../../deps/jsx/ebin ../../deps/lager/ebin ../../deps/mimetypes/ebin ../../deps/node_package/ebin ../../deps/proper/ebin ../../deps/ranch/ebin ../../deps/sqlparse/ebin -name dderl(a)WKS01.k2informatics.ch -setcookie zdss4d2_6tP -s dderl -dderl port 8443 -imem tcp_port 8125 -imem erl_cluster_mgr '\'dderl(a)WKS01.k2informatics.ch\'' -imem mnesia_schema_name dderlstag crash_function: wxEvtHandler::Disconnect executable: /usr/lib64/erlang/erts-5.10.4/bin/beam.smp kernel: 3.12.9-301.fc20.x86_64 runlevel: N 5 type: CCpp uid: 1000 Truncated backtrace: Thread no. 1 (10 frames) #0 wxEvtHandler::Disconnect at src/common/event.cpp:1376 #1 WxeApp::wxe_dispatch at gen/wxe_funcs.cpp:122 #2 WxeApp::dispatch at wxe_impl.cpp:398 #3 WxeApp::dispatch_cmds at wxe_impl.cpp:351 #4 wxEvtHandler::ProcessEventIfMatches at src/common/event.cpp:1239 #5 wxEvtHandler::SearchDynamicEventTable at src/common/event.cpp:1421 #6 wxEvtHandler::ProcessEvent at src/common/event.cpp:1297 #7 wxAppBase::ProcessIdle at src/common/appcmn.cpp:449 #8 wxapp_idle_callback at src/gtk/app.cpp:213 #13 gtk_main at gtkmain.c:1257 -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1064577] New: [abrt] erlang-erts: beam.smp killed by SIGSEGV
by Red Hat Bugzilla 29 Jun '15

29 Jun '15

https://bugzilla.redhat.com/show_bug.cgi?id=1064577 Bug ID: 1064577 Summary: [abrt] erlang-erts: beam.smp killed by SIGSEGV Product: Fedora Version: 20 Component: erlang Assignee: lemenkov(a)gmail.com Reporter: redhat(a)astekk.se QA Contact: extras-qa(a)fedoraproject.org CC: erlang(a)lists.fedoraproject.org, lemenkov(a)gmail.com, rhbugs(a)n-dimensional.de, skottler(a)redhat.com Description of problem: I used the debugger ( im() from eshell). and had a lot of processes breaking, w auto attach on break enabled. The gui got pretty unresponsive then, so I'm not entirely sure what I may have done to it, to cause this. Version-Release number of selected component: erlang-erts-R16B-03.1.fc20 Additional info: reporter: libreport-2.1.12 backtrace_rating: 3 cmdline: /usr/lib64/erlang/erts-5.10.4/bin/beam.smp -P 10000000 -K true -- -root /usr/lib64/erlang -progname erl -- -home /home/kaos -- -pa /home/kaos/src/zotonic/ebin /home/kaos/src/zotonic/deps/bear/ebin /home/kaos/src/zotonic/deps/bert/ebin /home/kaos/src/zotonic/deps/dh_date/ebin /home/kaos/src/zotonic/deps/edown/ebin /home/kaos/src/zotonic/deps/eiconv/ebin /home/kaos/src/zotonic/deps/elog/ebin /home/kaos/src/zotonic/deps/emqtt/ebin /home/kaos/src/zotonic/deps/folsom/ebin /home/kaos/src/zotonic/deps/gen_smtp/ebin /home/kaos/src/zotonic/deps/goldrush/ebin /home/kaos/src/zotonic/deps/lager/ebin /home/kaos/src/zotonic/deps/meck/ebin /home/kaos/src/zotonic/deps/mimetypes/ebin /home/kaos/src/zotonic/deps/mochiweb/ebin /home/kaos/src/zotonic/deps/parse_trans/ebin /home/kaos/src/zotonic/deps/sendfile/ebin /home/kaos/src/zotonic/deps/ua_classifier/ebin /home/kaos/src/zotonic/deps/webzmachine/ebin /home/kaos/src/zotonic/deps/z_stdlib/ebin /home/kaos/src/zotonic/modules/mod_oauth/deps/erlang-oauth/ebin /home/kaos/src/zotonic/priv/modules/*/deps/*/ebin /home/kaos/src/zotonic/priv/sites/*/deps/*/ebin /home/kaos/src/zotonic/priv/sites/*/modules/*/deps/*/ebin -sname zotonic001@cypher -boot start_sasl -config /home/kaos/src/zotonic/priv/erlang.config -sasl errlog_type error -s zotonic executable: /usr/lib64/erlang/erts-5.10.4/bin/beam.smp kernel: 3.12.9-301.fc20.x86_64 runlevel: N 5 type: CCpp uid: 1000 Truncated backtrace: Thread no. 1 (10 frames) #0 ?? #1 WxeApp::wxe_dispatch at gen/wxe_funcs.cpp:8951 #2 WxeApp::dispatch at wxe_impl.cpp:398 #3 WxeApp::dispatch_cmds at wxe_impl.cpp:351 #4 wxEvtHandler::ProcessEventIfMatches at src/common/event.cpp:1239 #5 wxEvtHandler::SearchDynamicEventTable at src/common/event.cpp:1421 #6 wxEvtHandler::ProcessEvent at src/common/event.cpp:1297 #7 wxAppBase::ProcessIdle at src/common/appcmn.cpp:449 #8 wxapp_idle_callback at src/gtk/app.cpp:213 #13 gtk_main at gtkmain.c:1257 Potential duplicate: bug 1013431 -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1153840] New: CVE-2014-8760 ejabberd: clients can unexpectedly connect without encryption [fedora-all]
by Red Hat Bugzilla 05 Jun '15

05 Jun '15

https://bugzilla.redhat.com/show_bug.cgi?id=1153840 Bug ID: 1153840 Summary: CVE-2014-8760 ejabberd: clients can unexpectedly connect without encryption [fedora-all] Product: Fedora Version: 20 Component: ejabberd Keywords: Security, SecurityTracking Severity: medium Priority: medium Assignee: lemenkov(a)gmail.com Reporter: mmcallis(a)redhat.com 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 Blocks: 1153839 (CVE-2014-8760) This is an automatically created tracking bug! It was created to ensure that one or more security vulnerabilities are fixed in affected versions of Fedora. For comments that are specific to the vulnerability please use bugs filed against the "Security Response" product referenced in the "Blocks" field. For more information see: http://fedoraproject.org/wiki/Security/TrackingBugs When submitting as an update, use the fedpkg template provided in the next comment(s). This will include the bug IDs of this tracking bug as well as the relevant top-level CVE bugs. Please also mention the CVE IDs being fixed in the RPM changelog and the fedpkg commit message. NOTE: this issue affects multiple supported versions of Fedora. While only one tracking bug has been filed, please correct all affected versions at the same time. If you need to fix the versions independent of each other, you may clone this bug as appropriate. [bug automatically created by: add-tracking-bugs] Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1153839 [Bug 1153839] CVE-2014-8760 ejabberd: clients can unexpectedly connect without encryption -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1148604] New: rabbitmq-server does not start due to missing symbols
by Red Hat Bugzilla 17 Mar '15

17 Mar '15

https://bugzilla.redhat.com/show_bug.cgi?id=1148604 Bug ID: 1148604 Summary: rabbitmq-server does not start due to missing symbols Product: Fedora Version: 21 Component: rabbitmq-server Assignee: lemenkov(a)gmail.com Reporter: lars(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 Trying to start rabbitmq-server (rabbitmq-server-3.1.5-9.fc21.noarch) yields the following: # /sbin/service rabbitmq-server start Redirecting to /bin/systemctl start rabbitmq-server.service Job for rabbitmq-server.service failed. See 'systemctl status rabbitmq-server.service' and 'journalctl -xn' for details. Running "journalctl -u rabbitmq-server" yields: Oct 01 20:16:53 f21-os-test systemd[1]: Starting RabbitMQ broker... Oct 01 20:16:53 f21-os-test systemd[1]: rabbitmq-server.service: Got notification message from PID 14545, but reception only permitted for main PID 14532 Oct 01 20:16:53 f21-os-test systemd[1]: rabbitmq-server.service: Got notification message from PID 14547, but reception only permitted for main PID 14532 Oct 01 20:16:53 f21-os-test systemd[1]: rabbitmq-server.service: Got notification message from PID 14571, but reception only permitted for main PID 14532 Oct 01 20:16:53 f21-os-test systemd[1]: rabbitmq-server.service: Got notification message from PID 14572, but reception only permitted for main PID 14532 Oct 01 20:16:54 f21-os-test rabbitmq-server[14532]: RabbitMQ 3.1.5. Copyright (C) 2007-2013 GoPivotal, Inc. Oct 01 20:16:54 f21-os-test rabbitmq-server[14532]: ## ## Licensed under the MPL. See http://www.rabbitmq.com/ Oct 01 20:16:54 f21-os-test rabbitmq-server[14532]: ## ## Oct 01 20:16:54 f21-os-test rabbitmq-server[14532]: ########## Logs: /var/log/rabbitmq/rabbit(a)f21-os-test.log Oct 01 20:16:54 f21-os-test rabbitmq-server[14532]: ###### ## /var/log/rabbitmq/rabbit(a)f21-os-test-sasl.log Oct 01 20:16:54 f21-os-test rabbitmq-server[14532]: ########## Oct 01 20:16:55 f21-os-test rabbitmq-server[14532]: Starting broker... completed with 0 plugins. Oct 01 20:18:23 f21-os-test systemd[1]: rabbitmq-server.service start operation timed out. Terminating. Oct 01 20:18:23 f21-os-test systemd[1]: Failed to start RabbitMQ broker. Oct 01 20:18:23 f21-os-test systemd[1]: Unit rabbitmq-server.service entered failed state. /var/log/rabbitmq/hostname.log contains: =INFO REPORT==== 1-Oct-2014::20:16:54 === Starting RabbitMQ 3.1.5 on Erlang 17 Copyright (C) 2007-2013 GoPivotal, Inc. Licensed under the MPL. See http://www.rabbitmq.com/ =INFO REPORT==== 1-Oct-2014::20:16:54 === node : rabbit@f21-os-test home dir : /var/lib/rabbitmq cookie hash : PZPVSneawENzOO4Ft5aeuA== log : /var/log/rabbitmq/rabbit(a)f21-os-test.log sasl log : /var/log/rabbitmq/rabbit(a)f21-os-test-sasl.log database dir : /var/lib/rabbitmq/mnesia/rabbit@f21-os-test =INFO REPORT==== 1-Oct-2014::20:16:55 === Limiting to approx 924 file handles (829 sockets) =INFO REPORT==== 1-Oct-2014::20:16:55 === Memory limit set to 1581MB of 3953MB total. =INFO REPORT==== 1-Oct-2014::20:16:55 === Disk free limit set to 1000MB =INFO REPORT==== 1-Oct-2014::20:16:55 === msg_store_transient: using rabbit_msg_store_ets_index to provide index =INFO REPORT==== 1-Oct-2014::20:16:55 === msg_store_persistent: using rabbit_msg_store_ets_index to provide index =WARNING REPORT==== 1-Oct-2014::20:16:55 === msg_store_persistent: rebuilding indices from scratch =INFO REPORT==== 1-Oct-2014::20:16:55 === started TCP Listener on [::]:5672 =WARNING REPORT==== 1-Oct-2014::20:16:55 === The on_load function for module sd_notify returned {error, {load_failed, "Failed to load NIF library: '/usr/lib64/erlang/lib/sd_notify-0.1/priv/sd_notify_drv.so: undefined symbol: sd_notify'"}} =INFO REPORT==== 1-Oct-2014::20:16:55 === Server startup complete; 0 plugins started. -- You are receiving this mail because: You are on the CC list for the bug.

1 14

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

erlang October 2014