Ghost MUC Service

We somehow wound up with a MUC service that won’t go away. Unfortunately, it is also the one selected by default by Spark for the most likely user-facing “Create Conference” options. No one has permissions to create a room in this service, including the built-in admin. We’ve tried deleting in the db and editng properties in the db while the Openfire service is stopped, but when it restarts the service returns, and even when it has settings identical to the other service no one can create a room, including from the admin interface.

For the life of me I can’t find out where Openfire would be storing the information it needs to re-create this service unless it has it stored somewhere in Clearspace but we’ve looked through the properties there and don’t see anything relevant.

Relevant versions:

Openfire 3.6.2

Integrated to Clearspace 2.5.4

Spark 2.5.8

Unclear if it is correlated but there are messages in the logs that appear to map to failed attempts to create such rooms that say: “Clearspace sent an unexpected reply to a get-room-config request. Room:

What in the world is going on? How can I fix or permanently get rid of this ghost service?

Hi geoff howard,

I can’t reproduce you bug, but I only have Openfire 3.6.4 (and no Clearspace) installed. I want to recommend to update your server because of serious security issues, but since I can’t find any items in the changelog regarding your problem this maybe doesn’t solve your problem. If the problem still exist then it sould be a problem of Clearspace and I encourage you to enable debug logging restart your server an post the regarding log.

Best Regards

It’s not a clearspace issue, I also have a ghost service hanging around from when we tried to do SRV records.

I deleted all references to the room but it remains, very annoying.

What version of openfire and db are you running?

Sent from my iPhone

On Oct 29, 2009, at 4:45 PM, hezekiahb <


What’s really strange is it actually disappeared for a day then came back. The issue was not there until we attempted SRV record forwarding & had changed the xmpp domain from to just We reverted because of various issues, features that stopped working, but now the bookmark remains. It doesn’t show in the admin console at all, but it’s there on the clients.

I don’t think we’ve ever messed with SRV records in our system (with

respect to this issue at least), though that’s a clue I can check

into. The fact that you’re having problems on 3.6.4 is helpful - that

means it isn’t fixed by an upgrade. (We’re still on 3.6.3) We did

change the name listed for the MUC service though, so that is

consistent between our situation and yours.

My guess would be that the issue could probably be recreated by simply changing the xmpp domain for a server that already has a conference service published. I thought originally that it was just because the bookmark remained under Client Management, but it remains still though that bookmark was deleted.

I wonder now though if the issue could be the client management plugin.