[Spacewalk-list] OSA Dispatcher "conflict" error [SEC=UNCLASSIFIED]

Andrew Bergman Andrew.Bergman at bom.gov.au
Fri Sep 8 03:18:25 UTC 2017


Additional:

I see the following errors in the logs:

2017/09/08 03:15:11 -00:00 31850 0.0.0.0: osad/jabber_lib.register_callback(<bound method Runner._error_callback of <osad.osa_dispatcher.Runner instance at 0x1ec8710>>, 'error', None, None, None, None)
2017/09/08 03:15:11 -00:00 31850 0.0.0.0: osad/jabber_lib._expire_callbacks_list([[<bound method Runner._error_callback of <osad.osa_dispatcher.Runner instance at 0x1ec8710>>, None, None]], 1504840511.7368159)
2017/09/08 03:15:11 -00:00 31850 0.0.0.0: osad/jabber_lib._expire_callbacks_list([[<bound method Runner._error_callback of <osad.osa_dispatcher.Runner instance at 0x1ec8710>>, None, None]], 1504840511.7537439)
2017/09/08 03:15:11 -00:00 31850 0.0.0.0: osad/jabber_lib._expire_callbacks_list([[<bound method Runner._error_callback of <osad.osa_dispatcher.Runner instance at 0x1ec8710>>, None, None]], 1504840511.7620511)
2017/09/08 03:15:11 -00:00 31850 0.0.0.0: osad/jabber_lib._expire_callbacks_list([[<bound method Runner._error_callback of <osad.osa_dispatcher.Runner instance at 0x1ec8710>>, None, None]], 1504840511.77037)
2017/09/08 03:15:19 -00:00 31850 0.0.0.0: osad/jabber_lib._expire_callbacks_list([[<bound method Runner._error_callback of <osad.osa_dispatcher.Runner instance at 0x1ec8710>>, None, None]], 1504840519.8019159)
2017/09/08 03:15:19 -00:00 31850 0.0.0.0: osad/jabber_lib._expire_callbacks_list([[<bound method Runner._error_callback of <osad.osa_dispatcher.Runner instance at 0x1ec8710>>, None, None]], 1504840519.8847489)
2017/09/08 03:15:19 -00:00 31850 0.0.0.0: osad/jabber_lib._expire_callbacks_list([[<bound method Runner._error_callback of <osad.osa_dispatcher.Runner instance at 0x1ec8710>>, None, None]], 1504840519.8934169)
2017/09/08 03:15:19 -00:00 31850 0.0.0.0: osad/jabber_lib._expire_callbacks_list([[<bound method Runner._error_callback of <osad.osa_dispatcher.Runner instance at 0x1ec8710>>, None, None]], 1504840519.904799)
2017/09/08 03:15:19 -00:00 31850 0.0.0.0: osad/jabber_lib._expire_callbacks_list([[<bound method Runner._error_callback of <osad.osa_dispatcher.Runner instance at 0x1ec8710>>, None, None]], 1504840519.9452281)
2017/09/08 03:15:19 -00:00 31850 0.0.0.0: osad/jabber_lib._expire_callbacks_list([[<bound method Runner._error_callback of <osad.osa_dispatcher.Runner instance at 0x1ec8710>>, None, None]], 1504840519.9523239)
2017/09/08 03:15:19 -00:00 31850 0.0.0.0: osad/jabber_lib._expire_callbacks_list([[<bound method Runner._error_callback of <osad.osa_dispatcher.Runner instance at 0x1ec8710>>, None, None]], 1504840519.9636769)
2017/09/08 03:15:27 -00:00 31850 0.0.0.0: osad/jabber_lib.dispatch(<error><conflict xmlns = 'urn:ietf:params:xml:ns:xmpp-streams'  /></error>,)
2017/09/08 03:15:27 -00:00 31850 0.0.0.0: osad/jabber_lib._expire_callbacks_list([[<bound method Runner._error_callback of <osad.osa_dispatcher.Runner instance at 0x1ec8710>>, None, None]], 1504840527.989017)
2017/09/08 03:15:27 -00:00 31850 0.0.0.0: osad/jabber_lib._get_callbacks(<error><conflict xmlns = 'urn:ietf:params:xml:ns:xmpp-streams'  /></error>,)
2017/09/08 03:15:27 -00:00 31850 0.0.0.0: osad/jabber_lib.dispatch('Calling callback', <bound method Runner._error_callback of <osad.osa_dispatcher.Runner instance at 0x1ec8710>>, <error><conflict xmlns = 'urn:ietf:params:xml:ns:xmpp-streams'  /></error>)
2017/09/08 03:15:27 -00:00 31850 0.0.0.0: osad/jabber_lib._error_callback('ERROR', 'Received an error stanza: ', <error><conflict xmlns = 'urn:ietf:params:xml:ns:xmpp-streams'  /></error>)
2017/09/08 03:15:27 -00:00 31850 0.0.0.0: osad/jabber_lib._error_callback('ERROR', 'Received an conflict. Restarting with new credentials.')

The errors mostly are generic and unlikely to be related but the conflict stuff made me look away from OSA-dispatcher and Spacewalk and at the underlying protocol XMPP.

When investigating what a "conflict" means in XMPP terms I find the following:  https://xmpp.org/rfcs/rfc3921.html

If there is already an active resource of the same name, the server MUST either (1) terminate the active resource and allow the newly-requested session, or (2) disallow the newly-requested session and maintain the active resource. Which of these the server does is up to the implementation, although it is RECOMMENDED to implement case #1. In case #1, the server SHOULD send a <conflict/> stream error to the active resource, terminate the XML stream and underlying TCP connection for the active resource, and return a IQ stanza of type "result" (indicating success) to the newly-requested session. In case #2, the server SHOULD send a <conflict/> stanza error to the newly-requested session but maintain the XML stream for that connection so that the newly-requested session has an opportunity to negotiate a non-conflicting resource identifier before sending another request for session establishment.
Step 2 (alt): Server informs existing active resource of resource conflict (case #1):
<stream:error>
  <conflict xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
Step 2 (alt): Server informs newly-requested session of resource conflict (case #2):
<iq from='example.com' type='error' id='sess_1'>
  <session xmlns='urn:ietf:params:xml:ns:xmpp-session'/>
  <error type='cancel'>
    <conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>
After establishing a session, a client SHOULD send initial presence and request its roster as described below, although these actions are OPTIONAL.
Note: Before allowing the creation of instant messaging and presence sessions, a server MAY require prior account provisioning. Possible methods for account provisioning include account creation by a server administrator as well as in-band account registration using the 'jabber:iq:register' namespace; the latter method is out of scope for this memo, but is documented in [JEP‑0077]<https://xmpp.org/rfcs/rfc3921.html#JEP-0077>, published by the Jabber Software Foundation<https://xmpp.org/rfcs/rfc3921.html#JSF> [JSF].
Have I possibly hit a bug here in osa-dispatcher or jabber?

Regards

Andrew Bergman



From: spacewalk-list-bounces at redhat.com [mailto:spacewalk-list-bounces at redhat.com] On Behalf Of Andrew Bergman
Sent: Friday, 8 September 2017 11:29 AM
To: spacewalk-list at redhat.com
Subject: [Spacewalk-list] OSA Dispatcher "conflict" error [SEC=UNCLASSIFIED]

Hi Spacewalk list,

I am seeing an error on the Spacewalk 2.6 server I am responsible for:

Jabber is running, port 5222 TCP is running from c2s process and is communicable via telnet.   I see no errors in the logs except from osa-dispatcher.

# osa-dispatcher -N –vvvvvvvvvvvv

The last messages are:
--> <presence to='osad-bb7d64e5e1 at sdcvp-spacewalk01.bom.gov.au' type='subscribed' id='presence-fb3eba-37' />

<-- <iq type='result' id='iq-request-c8a784-8'><query xmlns = 'jabber:iq:roster' ><item jid='osad-bb7d64e5e1 at sdcvp-spacewalk01.bom.gov.au' subscription='to' /><item jid='osad-441293a7e7 at sdcvp-spacewalk01.bom.gov.au' subscription='to' /></query></iq>

<-- <iq to='rhn-dispatcher-sat at sdcvp-spacewalk01.bom.gov.au/superclient' type='set' id='zb6g3gnj6oylakzw0ntgapdin3tlgajgmqwq6j9c'><query xmlns = 'jabber:iq:roster' ><item jid='osad-441293a7e7 at sdcvp-spacewalk01.bom.gov.au' subscription='both' /></query></iq>

--> <iq type='get' id='iq-request-c8a784-9'><query xmlns = 'jabber:iq:roster'  /></iq>

<-- <iq to='rhn-dispatcher-sat at sdcvp-spacewalk01.bom.gov.au/superclient' type='set' id='78xisxfsl88wymemq876irn4hjvn340bcyt5w8xh'><query xmlns = 'jabber:iq:roster' ><item jid='osad-bb7d64e5e1 at sdcvp-spacewalk01.bom.gov.au' subscription='both' /></query></iq>

<-- <error><conflict xmlns = 'urn:ietf:params:xml:ns:xmpp-streams'  /></error>

Spacewalk 20123 2017/09/07 06:49:21 -00:00: ('Received an error stanza: ', <error><conflict xmlns = 'urn:ietf:params:xml:ns:xmpp-streams'  /></error>)
Spacewalk 20123 2017/09/07 06:49:21 -00:00: ('Received an conflict. Restarting with new credentials.',)
Spacewalk 20123 2017/09/07 06:49:21 -00:00: ('Error caught:',)

ERROR: unhandled exception occurred: (can't write str to text stream).

This looks similar to:  http://spacewalk-list.redhat.narkive.com/aH2kex2k/osa-dispatcher-problems-no-system-ever-reports

However, I see no SSL errors, my hosts file is fine, with ipv6 ::1 entry for localhost, fully qualified hostname and the system hostname set to FQDN correctly.

Does anyone have any suggestions?

Thanks

Andrew Bergman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20170908/beb99dec/attachment.htm>


More information about the Spacewalk-list mailing list