* Soren Stoutner <so...@debian.org> [2025-04-04 17:22]:
Before attempting the update
MnesiaCore.ejabberd@mail_1743_810526_689352 was 0.3 MB. After
attempting the update, the file size had ballooned to 235 MB.
However, before the update archive_msg.DAT was 285 MB, and ballooned
to over 300 MB during the failed update.
Do these file sizes seem large to you? It is perhaps a timeout trying
to process the database because of the size? Is there some way to
compact/purge the database?
Ah, thanks. Yes, this clearly indicates that the Mnesia table used for
storing the server-side message archive is borked (there's a max. size
limit of 2 GiB), and it's most probably the reason ejabberd fails to
start up.
There's nothing the Debian package (maintainer) could do to address
this, I'm afraid. The problem is that Mnesia is not designed for
persistent storage of non-trivial amounts of data (it's more of a Redis
replacement than an SQL replacement). It's still ejabberd's default
storage backend for historical reasons. Back in the days, there was no
server-side archive. But when using it for this kind of data, breakage
can happen (e.g., when upgrading Erlang). That's the reason you'll see
a warning to not use Mnesia in the logs during startup, and in the
default configuration. I've been advocating for removing Mnesia support
altogether and switching to SQLite by default, but we didn't get round
to that, yet (upstream, I mean).
So, for cases such as yours, I see no proper fix, and would instead
suggest one of the following two options:
1) Remove Mnesia's archive table (i.e., all messages stored server-side)
and maybe also the PubSub tables before upgrading. The remaining tables
will probably survive the upgrade, and fresh archive/PubSub tables will
be usable after the upgrade (until the next breakage, at least).
2) Convert to SQL before upgrading (strongly recommended).
I could help with either (e.g., in the ejabberd support channel), but
maybe that's out of scope here?
