Holger, On Tuesday, April 1, 2025 4:16:57 AM Mountain Standard Time Holger Weiß wrote: > * Soren Stoutner <[email protected]> [2025-03-31 13:42]: > >2025-03-31 12:19:20.471345-07:00 [error] <0.148.0> External eimp > >process (pid=972861) has terminated unexpectedly, restarting in a > >few seconds > > eimp is a small helper process, we should try to figure out why it > terminates. > > Can you call /usr/lib/erlang/lib/p1_eimp*/priv/bin/eimp manually? > (It's supposed to run without producing any output; if that works, > just press Ctrl+C to terminate it.)
When calling it manually, it runs without producing output.
However, I did get this interesting bit of information in the log:
2025-04-04 16:48:46.882266-07:00 [error] <0.228.0>
Mnesia(ejabberd@mail): ** ERROR ** (core dumped to file: "/var/lib/
ejabberd/MnesiaCore.ejabberd@mail_1743_810526_689352")
** FATAL ** mnesia_tm crashed: {badarg,
[{erlang,unlink,
[undefined],
[{error_info,
#{module => erl_erts_errors}}]},
{mnesia_controller,
release_schema_commit_lock,0,
[{file,"mnesia_controller.erl"},
{line,333}]},
{mnesia_dumper,update,3,
[{file,"mnesia_dumper.erl"},{line,
301}]},
{mnesia_tm,do_commit,3,
[{file,"mnesia_tm.erl"},{line,
1846}]},
{mnesia_tm,recover_coordinator,2,
[{file,"mnesia_tm.erl"},{line,
646}]},
{mnesia_tm,handle_exit,3,
[{file,"mnesia_tm.erl"},{line,
623}]},
{mnesia_sp,init_proc,4,
[{file,"mnesia_sp.erl"},{line,
35}]},
{proc_lib,init_p_do_apply,3,
[{file,"proc_lib.erl"},{line,
329}]}]} state: [<0.230.0>]
2025-04-04 16:48:56.690142-07:00 [error]
<0.471.0>@supervisor:do_restart/3:1300 SUPERVISOR REPORT:
supervisor: {local,ejabberd_backend_sup}
errorContext: child_terminated
reason: killed
offender: [{pid,<0.475.0>},
{id,ejabberd_router_mnesia},
{mfargs,{ejabberd_router_mnesia,start_link,[]}},
{restart_type,transient},
{significant,false},
{shutdown,5000},
{child_type,worker}]
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?
> May AppArmor or similar prevent eimp from running? Maybe just
> `systemctl stop apparmor` and try again just to rule that out?
Stopping AppArmor made no difference. In fact, it was already stopped
because with my last update to testing a few weeks ago some other
package borked my AppArmor installation. I haven’t looked deeply into
it. I assume it will fix itself with the next batch of updates I plan
to install next week. But just in case it is important for this bug
report:
Apr 04 16:54:40 mail apparmor.systemd[4134057]: Restarting AppArmor
Apr 04 16:54:40 mail apparmor.systemd[4134057]: Reloading AppArmor
profiles
Apr 04 16:54:40 mail apparmor.systemd[4134161]: Skipping profile in /
etc/apparmor.d/disable: usr.bin.thunderbird
Apr 04 16:54:40 mail apparmor.systemd[4134170]: profile has merged
rule with conflicting x modifiers
Apr 04 16:54:40 mail apparmor.systemd[4134170]: ERROR processing
regexs for profile su, failed to load
Apr 04 16:54:40 mail apparmor.systemd[4134057]: Error: At least one
profile failed to load
Apr 04 16:54:40 mail systemd[1]: apparmor.service: Main process
exited, code=exited, status=1/FAILURE
--
Soren Stoutner
[email protected]
signature.asc
Description: This is a digitally signed message part.
