#1091 mod_muc does not handle storage driver connection failure on startup
Reporter
Kane Valentine
Owner
Zash
Created
Updated
Stars
★ (1)
Tags
Priority-High
Status-Fixed
Type-Defect
Milestone-0.10
Kane Valentine
on
What steps will reproduce the problem?
1. Connect your Prosody server to a SQL storage backend
2. Set up a MUC room, do some configuration etc
3. Reboot the server, if Prosody comes up before your SQL then bad things happen to your MUC rooms...
What is the expected output?
Everything to be exactly the way I left it at reboot.
What do you see instead?
Whoever connects to the MUCs first generally becomes owner of it, configs are reset etc etc.
What version of the product are you using? On what operating system?
Prosody 10 on Debian 9.
Please provide any additional information below.
N/A, Zash told me to make this issue, so he understands it. :)
Zash
on
Changes
tags Status-Accepted Milestone-0.10
Zash
on
Changes
tags Priority-High
Zash
on
Let's limit the scope of this issue to the data loss on startup.
The problem is that on startup, a list of all persistent rooms are loaded. If no data is returned or if there's a storage failure, the list is initialized to an empty list.
Rooms that are not in this list are treated as non-existent, so creating new ones that overwrite them is allowed.
Ideally one would want to retry loading that list, but that looks like a major refactoring. Incidentally, trunk has already had that refactoring, so I think the initial fix in 0.10 will be to abort loading of mod_muc, requiring a reload or restart.
Changes
titlemod_muc ignorant of storage driver connection failure mod_muc does not handle storage driver connection failure on startup
I'm using the sqlite backend and I don't have any persistent rooms. After updating to 10.1 I get
May 24 03:58:46 sql error Error in SQL transaction: commit failed
May 24 03:58:46 sql error Error in SQL transaction: commit failed
May 24 03:58:46 conference.durus.gcsc.uni-frankfurt.de:muc error Error loading list of persistent rooms from storage. Reload mod_muc or restart to recover.
in prosody.err every time prosody is restarted. Reverting to 0.10 gets rid of these again.
Zash
on
The error message is unfortunately also printed in case there are no persistent rooms. If there is no traceback following it, it can be ignored until we correct this.
The "commit failed" are unrelated to this issue, see #1064.
M. Lampe
on
No, there is no traceback. Everything is working anyway. Thanks.
What steps will reproduce the problem? 1. Connect your Prosody server to a SQL storage backend 2. Set up a MUC room, do some configuration etc 3. Reboot the server, if Prosody comes up before your SQL then bad things happen to your MUC rooms... What is the expected output? Everything to be exactly the way I left it at reboot. What do you see instead? Whoever connects to the MUCs first generally becomes owner of it, configs are reset etc etc. What version of the product are you using? On what operating system? Prosody 10 on Debian 9. Please provide any additional information below. N/A, Zash told me to make this issue, so he understands it. :)
Let's limit the scope of this issue to the data loss on startup. The problem is that on startup, a list of all persistent rooms are loaded. If no data is returned or if there's a storage failure, the list is initialized to an empty list. Rooms that are not in this list are treated as non-existent, so creating new ones that overwrite them is allowed. Ideally one would want to retry loading that list, but that looks like a major refactoring. Incidentally, trunk has already had that refactoring, so I think the initial fix in 0.10 will be to abort loading of mod_muc, requiring a reload or restart.
Changesmod_muc ignorant of storage driver connection failuremod_muc does not handle storage driver connection failure on startupAbort module load: https://hg.prosody.im/0.10/rev/7e7aa0f770c7 Lock individual rooms that can't be loaded: https://hg.prosody.im/0.10/rev/416b8ae3857d Testing these would be appreciated.
ChangesI'm using the sqlite backend and I don't have any persistent rooms. After updating to 10.1 I get May 24 03:58:46 sql error Error in SQL transaction: commit failed May 24 03:58:46 sql error Error in SQL transaction: commit failed May 24 03:58:46 conference.durus.gcsc.uni-frankfurt.de:muc error Error loading list of persistent rooms from storage. Reload mod_muc or restart to recover. in prosody.err every time prosody is restarted. Reverting to 0.10 gets rid of these again.
The error message is unfortunately also printed in case there are no persistent rooms. If there is no traceback following it, it can be ignored until we correct this. The "commit failed" are unrelated to this issue, see #1064.
No, there is no traceback. Everything is working anyway. Thanks.