Ejabberd crashes after 2.1.5 -> 16.09 upgrade

Hello everyone
I'm trying to upgrade old ejabberd to recent version.

I installed new server (as old server is very old), installed ejabberd 16.09 and checked that most things work
Then I stopped server, cloned old spool to new server and started new ejabberd

Ejabberd logged that it was upgrading tables and converting passes to SCRAM
At first glance everything looked ok.

First question: on every restart ejabberd logs this:
> 2016-10-25 15:23:39.827 [info] <0.38.0>@ejabberd_auth_mnesia:scram_passwords:438 Converting the stored passwords into SCRAM bits
> 2016-10-25 15:24:44.295 [info] <0.38.0>@ejabberd_auth_mnesia:scram_passwords:438 Converting the stored passwords into SCRAM bits
Is that OK? Or it should appear only during spool upgrade?

Another problem: I'm trying to backup ejabberd:
> ejabberdctl backup file
Ejabberd creates backup file of about 1M size and then hangs. It eats all available memory (I increased mem to 10G, process ate it all). After ~5mins server starts creating crash dump file

Is there something I can do to troubleshoot and fix it?

> Is that OK? Or it should

> Is that OK? Or it should appear only during spool upgrade?

It's OK in the sense that the code works that way: if the SCRAM option is set, then it traverses all the passwd table to convert to SCRAM any plaintext password it finds. Do you have many users? And does it take too long to start ejabberd due to that (almost unnecessary) step?

> ejabberdctl backup file... Ejabberd creates backup file of about 1M size and then hangs.

Do you have many users? Maybe mnesia backup is not efficient for backing up so many users. Also check which mnesia tables are bigger (you can see with "mnesia info", or in the WebAdmin.

If you see nothing abnormal in your tables sizes (no signs of spammers or abusers), then you better forget about that backup method. Instead simply copy the spool files, preferably with ejabberd stopped or when there's low access to the database (for example on sunday at 4 AM).

> Do you have many users? And

> Do you have many users? And does it take too long to start ejabberd due to that (almost unnecessary) step?
About 15000 registered users. Start takes about 3-4 minutes

> Do you have many users? Maybe mnesia backup is not efficient for backing up so many users. Also check which mnesia tables are bigger (you can see with "mnesia info", or in the WebAdmin.
Largest tables:
> offline_msg : with 89441 records occupying 73924455 bytes on disc
> roster : with 48611 records occupying 3323591 words of mem

> then you better forget about that backup method.
I'm afraid that if backup fails, then it may be the sign of a larger problem that can pop up later after I upgrade prod server

Merlyel wrote: > Do you have

Merlyel wrote:

> Do you have many users? And does it take too long to start ejabberd due to that (almost unnecessary) step?
About 15000 registered users. Start takes about 3-4 minutes

You can try to disable that scram step, that may improve your start time:

--- a/src/ejabberd_auth_mnesia.erl
+++ b/src/ejabberd_auth_mnesia.erl
@@ -367,7 +367,7 @@ update_table() ->
     case mnesia:table_info(passwd, attributes) of
         Fields ->
             convert_to_binary(Fields),
-            maybe_scram_passwords(),
+            %%maybe_scram_passwords(),
             ok;
         _ ->
             ?INFO_MSG("Recreating passwd table", []),
Merlyel wrote:

> Do you have many users? Maybe mnesia backup is not efficient for backing up so many users. Also check which mnesia tables are bigger (you can see with "mnesia info", or in the WebAdmin.
Largest tables:
> offline_msg : with 89441 records occupying 73924455 bytes on disc
> roster : with 48611 records occupying 3323591 words of mem

> then you better forget about that backup method.
I'm afraid that if backup fails, then it may be the sign of a larger problem that can pop up later after I upgrade prod server

Those sound reasonable numbers for 15000 registered accounts. You can try to purge old useless information with commands like delete_old_users and delete_old_messages.

Also, it may happen that mnesia (as a default internal database for basic usage) is not able to handle your present or future requirements. If you expect the amount of users to increase shortly, you should try to use a SQL storage, which is anyway recommended for large databases. Another benefit is that you probably already know how your prefered SQL server works and how to administer it, compared to a Mnesia database.

I'm ok with that start time.

I'm ok with that start time. I just was not sure if ejabberd should check these passwords every restart or no. If it needs it, then let it be so

About users - I don't think there gonna be great increase, so I did not plan to move to another storage engine.

Syndicate content