What steps will reproduce the problem? 1. In /etc/prosody/prosody.cfg.lua, set the following under the MUC component: restrict_room_creation = true component_admins_as_room_owners = true muc_tombstone_expiry = 86400*9999 (or any time you want, doesn't matter anyway) Globally: muc_restrict_rooms = { { ["*"] = "all" }; } muc_restrict_exceptions = { "community" } muc_restrict_allow_admins = true 2. Restart the service: `rcctl restart prosody` 3. Launch shell: `prosodyctl shell` 4. Delete old channel: `muc:room("abandoned@example.com"):destroy()` (execute twice to truly delete it) 5. Restart the service: `rcctl restart prosody` 6. Launch shell: `prosodyctl shell` 7. Check MUC list: `muc:list("chat.xmpp.076.ne.jp")` What is the expected output? Channel should stay gone. What do you see instead? Deleted channel is back again like if it was never deleted. Results vary, because sometimes it stays gone, and sometimes it's back again. And if it stays gone, it'll come back again within up to 2 weeks. And since Prosody is very buggy on OpenBSD (possibly due to a memory leak?), unfortunately we have to restart the service frequently. What version of the product are you using? On what operating system? Prosody 13.0.1 OpenBSD 7.7 amd64 Please provide any additional information below.

> And since Prosody is very buggy on OpenBSD (possibly due to a memory leak?), unfortunately we have to restart the service frequently. If you mean that Prosody "freezes" every few days, that was already fixed. You can either wait for the next OpenBSD release, or build the luasec port with the patches added in this commit https://github.com/openbsd/ports/commit/b4c26d7403d1b5 If you build luasec, make sure to use lua5.4 as a flavor

This is just part of the problem. The main problem is that channels that have already been deleted get re-created automatically at some daemon restarts. Sometimes restarting Prosody keeps them deleted, and sometimes all the channels that have been deleted are being re-created. Room creation is disabled to all except for the admin account, which is only 1 user. We've been deleting already deleted channels hundreds of times by now.

Thanks for the report. Try not calling room:destroy() twice, see if that helps. Destroying a room leaves a tombstone, which stops other users from recreating the room and informs them that the room has been destroyed. If you destroy the tombstone, as you say you do, this doesn't happen and users who have the room in their auto-join bookmarks will create the room again.

• tags Status-NeedInfo