#1091 mod_muc does not handle storage driver connection failure on startup

Reporter Kane Valentine
Owner Zash
Created
Updated
Stars ★ (1)  
Tags
  • Milestone-0.10
  • Type-Defect
  • Status-Fixed
  • Priority-High
  1. 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. :)

  2. Zash on

    Changes
    • tags Status-Accepted Milestone-0.10
  3. Zash on

    Changes
    • tags Priority-High
  4. 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
    • owner Zash
    • tags Status-Started
    • title mod_muc ignorant of storage driver connection failure mod_muc does not handle storage driver connection failure on startup
  5. Zash on

    Abort 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.

    Changes
    • tags Status-Fixed
  6. M. Lampe on

    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.

  7. 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.

  8. M. Lampe on

    No, there is no traceback. Everything is working anyway. Thanks.

New comment

Not published. Used for spam prevention and optional update notifications.