Description of problem: We have an environment where Satellite has 127.0.0.1 and ::1 on lo interface and something along the lines of fd::/64 on eth0. In this environment, qpidd listens on ::1 only. In /etc/hosts we have 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 If we set candlepin.amqp.connect to localhost[1] in /etc/candlepin/candlepin.conf, candlepin goes into suspended mode. Version-Release number of selected component (if applicable): candlepin-2.9.14-1.el7.noarch How reproducible: Always Steps to Reproduce: 1. Make qpidd listen on ::1 only 2. Set candlepin.amqp.connect to tcp://localhost:5671?ssl='true'&ssl_cert_alias='amqp-client' 3. Restart tomcat 4. watch /var/log/candlepin/candlepin.log Actual results: After a while these lines appear in the log org.candlepin.audit.QpidConnection - Connection to Qpid was lost! Cleaning up current connection! org.candlepin.controller.ModeManagerImpl - Entering new mode SUSPEND for the following reasons: [QPID_DOWN] org.candlepin.controller.ModeManagerImpl - Candlepin is entering suspend mode for the following reasons: [QPID_DOWN] Expected results: Candlepin can talk to qpidd, these lines appear in log org.candlepin.audit.QpidConnection - Attempting to connect to QPID due to status change: UNKNOWN --> CONNECTED org.candlepin.audit.QpidConnection - AMQP connection factory created. org.candlepin.audit.QpidConnection - AMQP session created successfully... Additional info: If I drop "localhost" from the line starting with 127.0.0.1, it suddenly starts working. It seems as if candlepin resolves the name to 127.0.0.1 and doesn't retry with ::1 on failure. [1] - The exact line is: tcp://localhost:5671?ssl='true'&ssl_cert_alias='amqp-client'
Created redmine issue https://projects.theforeman.org/issues/28693 from this bug
From IRC, to duplicate: "interface=::1" into /etc/qpidd.conf and restarting qpidd should work [01/08 10:30] <aruzicka> eh, /etc/qpid/qpidd.conf
IMO this can be closed due to the reasons mentioned by Chris. Also, Artemis is not external to Candlepin like QPid is, so I don't think the same problem would be present.
The version of Candlepin (3.1) to be included in Satellite 6.8 will no longer require Qpidd but instead rely on an internal Artemis instance. For this reason, this bug will no longer be an issue. As such closing as nextrelease. If there is any disagreement with this decision please reopen this bug providing additional details so we may continue the discussion. Thank you for your use of Satellite!