Hi all :-) A problem similar to this : <a class="issue-link js-issue-link" data-er

At "sudo journalctl -xeu ejabberd.service" this is the output: <div class="snippet

ejabberd do not start after update from 23.10 to 24.02 about ejabberd HOT 5 OPEN

giostark commented on May 18, 2024

ejabberd do not start after update from 23.10 to 24.02

from ejabberd.

Comments (5)

giostark commented on May 18, 2024

This is the status of the service. Seems that it stay pending the connection.
I don't know how to investigate that "epam" that may cause this stuck.
And do not seems related with other "epam port died" I found on the net.

[arch-nas@arch-nas ~]$ sudo systemctl status ejabberd
● ejabberd.service - XMPP Server
     Loaded: loaded (/etc/systemd/system/ejabberd.service; enabled; preset: disabled)
     Active: activating (start) since Sat 2024-04-13 20:48:18 CEST; 4min 24s ago
   Main PID: 2353 (ejabberdctl)
      Tasks: 34 (limit: 9378)
     Memory: 739.5M (peak: 907.0M)
        CPU: 5min 2.304s
     CGroup: /system.slice/ejabberd.service
             ├─2353 /bin/sh /opt/ejabberd-24.02/bin/ejabberdctl foreground
             ├─2366 /opt/ejabberd-24.02/erts-14.2.2/bin/beam.smp -K true -P 250000 -- -root /opt/ejabberd-24.02 -bindir /opt/ejabberd-24.02/erts-14.2.2/bin -progname erl -- -h>
             ├─2378 /opt/ejabberd-24.02/erts-14.2.2/bin/epmd -daemon
             ├─2382 erl_child_setup 65536
             ├─2407 /opt/ejabberd-24.02/lib/eimp-1.0.22/priv/bin/eimp
             ├─2408 /opt/ejabberd-24.02/lib/eimp-1.0.22/priv/bin/eimp
             ├─2409 /opt/ejabberd-24.02/lib/eimp-1.0.22/priv/bin/eimp
             ├─2410 /opt/ejabberd-24.02/lib/eimp-1.0.22/priv/bin/eimp
             ├─2411 /opt/ejabberd-24.02/lib/epam-1.0.14/priv/bin/epam
             ├─2412 /opt/ejabberd-24.02/erts-14.2.2/bin/inet_gethost 4
             └─2413 /opt/ejabberd-24.02/erts-14.2.2/bin/inet_gethost 4

Apr 13 20:48:21 arch-nas ejabberdctl[2366]:               {child_type,supervisor}]
Apr 13 20:48:21 arch-nas ejabberdctl[2366]: 2024-04-13 20:48:21.216010+02:00 [debug] PROGRESS REPORT:
Apr 13 20:48:21 arch-nas ejabberdctl[2366]:     supervisor: {local,kernel_safe_sup}
Apr 13 20:48:21 arch-nas ejabberdctl[2366]:     started: [{pid,<0.404.0>},
Apr 13 20:48:21 arch-nas ejabberdctl[2366]:               {id,disk_log_server},
Apr 13 20:48:21 arch-nas ejabberdctl[2366]:               {mfargs,{disk_log_server,start_link,[]}},
Apr 13 20:48:21 arch-nas ejabberdctl[2366]:               {restart_type,permanent},
Apr 13 20:48:21 arch-nas ejabberdctl[2366]:               {significant,false},
Apr 13 20:48:21 arch-nas ejabberdctl[2366]:               {shutdown,2000},
Apr 13 20:48:21 arch-nas ejabberdctl[2366]:               {child_type,worker}]

from ejabberd.

giostark commented on May 18, 2024

At "sudo journalctl -xeu ejabberd.service" this is the output:

[arch-nas@arch-nas ~]$ sudo journalctl -xeu ejabberd.service
[sudo] password for arch-nas: 
Apr 13 20:58:34 arch-nas ejabberdctl[2870]:               {significant,false},
Apr 13 20:58:34 arch-nas ejabberdctl[2870]:               {shutdown,3000},
Apr 13 20:58:34 arch-nas ejabberdctl[2870]:               {child_type,worker}]
Apr 13 20:58:34 arch-nas ejabberdctl[2870]: 2024-04-13 20:58:34.647473+02:00 [debug] PROGRESS REPORT:
Apr 13 20:58:34 arch-nas ejabberdctl[2870]:     supervisor: {local,mnesia_kernel_sup}
Apr 13 20:58:34 arch-nas ejabberdctl[2870]:     started: [{pid,<0.396.0>},
Apr 13 20:58:34 arch-nas ejabberdctl[2870]:               {id,mnesia_subscr},
Apr 13 20:58:34 arch-nas ejabberdctl[2870]:               {mfargs,{mnesia_subscr,start,[]}},
Apr 13 20:58:34 arch-nas ejabberdctl[2870]:               {restart_type,permanent},
Apr 13 20:58:34 arch-nas ejabberdctl[2870]:               {significant,false},
Apr 13 20:58:34 arch-nas ejabberdctl[2870]:               {shutdown,3000},
Apr 13 20:58:34 arch-nas ejabberdctl[2870]:               {child_type,worker}]
Apr 13 20:58:34 arch-nas ejabberdctl[2870]: 2024-04-13 20:58:34.661363+02:00 [debug] PROGRESS REPORT:
Apr 13 20:58:34 arch-nas ejabberdctl[2870]:     supervisor: {local,mnesia_kernel_sup}
Apr 13 20:58:34 arch-nas ejabberdctl[2870]:     started: [{pid,<0.397.0>},
Apr 13 20:58:34 arch-nas ejabberdctl[2870]:               {id,mnesia_locker},
Apr 13 20:58:34 arch-nas ejabberdctl[2870]:               {mfargs,{mnesia_locker,start,[]}},
Apr 13 20:58:34 arch-nas ejabberdctl[2870]:               {restart_type,permanent},
Apr 13 20:58:34 arch-nas ejabberdctl[2870]:               {significant,false},
Apr 13 20:58:34 arch-nas ejabberdctl[2870]:               {shutdown,3000},
Apr 13 20:58:34 arch-nas ejabberdctl[2870]:               {child_type,worker}]
Apr 13 20:58:34 arch-nas ejabberdctl[2870]: 2024-04-13 20:58:34.670528+02:00 [debug] PROGRESS REPORT:
Apr 13 20:58:34 arch-nas ejabberdctl[2870]:     supervisor: {local,mnesia_kernel_sup}
Apr 13 20:58:34 arch-nas ejabberdctl[2870]:     started: [{pid,<0.398.0>},
Apr 13 20:58:34 arch-nas ejabberdctl[2870]:               {id,mnesia_recover},
Apr 13 20:58:34 arch-nas ejabberdctl[2870]:               {mfargs,{mnesia_recover,start,[]}},
Apr 13 20:58:34 arch-nas ejabberdctl[2870]:               {restart_type,permanent},
Apr 13 20:58:34 arch-nas ejabberdctl[2870]:               {significant,false},
Apr 13 20:58:34 arch-nas ejabberdctl[2870]:               {shutdown,180000},
Apr 13 20:58:34 arch-nas ejabberdctl[2870]:               {child_type,worker}]
Apr 13 20:58:34 arch-nas ejabberdctl[2870]: 2024-04-13 20:58:34.752914+02:00 [debug] PROGRESS REPORT:
Apr 13 20:58:34 arch-nas ejabberdctl[2870]:     supervisor: {local,kernel_safe_sup}
Apr 13 20:58:34 arch-nas ejabberdctl[2870]:     started: [{pid,<0.403.0>},
Apr 13 20:58:34 arch-nas ejabberdctl[2870]:               {id,disk_log_sup},
Apr 13 20:58:34 arch-nas ejabberdctl[2870]:               {mfargs,{disk_log_sup,start_link,[]}},
Apr 13 20:58:34 arch-nas ejabberdctl[2870]:               {restart_type,permanent},
Apr 13 20:58:34 arch-nas ejabberdctl[2870]:               {significant,false},
Apr 13 20:58:34 arch-nas ejabberdctl[2870]:               {shutdown,1000},
Apr 13 20:58:34 arch-nas ejabberdctl[2870]:               {child_type,supervisor}]
Apr 13 20:58:34 arch-nas ejabberdctl[2870]: 2024-04-13 20:58:34.753550+02:00 [debug] PROGRESS REPORT:
Apr 13 20:58:34 arch-nas ejabberdctl[2870]:     supervisor: {local,kernel_safe_sup}
Apr 13 20:58:34 arch-nas ejabberdctl[2870]:     started: [{pid,<0.404.0>},
Apr 13 20:58:34 arch-nas ejabberdctl[2870]:               {id,disk_log_server},
Apr 13 20:58:34 arch-nas ejabberdctl[2870]:               {mfargs,{disk_log_server,start_link,[]}},
Apr 13 20:58:34 arch-nas ejabberdctl[2870]:               {restart_type,permanent},
Apr 13 20:58:34 arch-nas ejabberdctl[2870]:               {significant,false},
Apr 13 20:58:34 arch-nas ejabberdctl[2870]:               {shutdown,2000},
Apr 13 20:58:34 arch-nas ejabberdctl[2870]:               {child_type,worker}]

from ejabberd.

giostark commented on May 18, 2024

I tried to substitute the "/opt/ejabberd-24.02/lib/epam-1.0.14/priv/bin/epam" with the old one 1.0.12 from the 23.10 installation but of course it do not worked ...

from ejabberd.

badlop commented on May 18, 2024

As you use the internal (mnesia) database, I guess you made a backup of its files before updating the program.

What happens if you uninstall ejabberd 24.02, recover back the old mnesia directory, install ejabberd 23.10 and start it: does it start correctly?

from ejabberd.

giostark commented on May 18, 2024

Hi Lop !
Thanks for the patience to read all this :-)
I try to explain as I do operate with my hardware. Maybe is useful...
I have an Asustor NAS in which I installed Arch (instead of using the stock software) I have two MX500 1TB (and other two disk but not relevant in this case).
The main disk is just one , the second is passive. (not auto cloning software or similar stuff) .
From time to time I update the system , reboot the machine to check everything is working and then update the ejabberd using the .run file.
I install it as root and it place all the files in opt.
If the update of jabber end fine and it work without errors of any kind I power off the machine , using a USB installation pen of Arch I clone with dd the entire first disk to the second disk. Like this I have a working backup but not subjected at those kind of errors.
And right now I'm running this backup with the 23.10 installed ! I'm using this backup made nearly one month ago.
On the first disk I tried to install and configure prosody and it after some hours of learning curve (i'm a noob) ended working fine but of course with its limitation for some defective modules.

I tried as you suggested and the errors became like this:


2024-04-17 22:46:15.105809+02:00 [error] <0.457.0>@proc_lib:crash_report/4:584 CRASH REPORT:
  crasher:
    initial call: ejabberd_commands:init/1
    pid: <0.457.0>
    registered_name: []
    exception exit: {aborted,{node_not_running,ejabberd@localhost}}
      in function  mnesia:abort/1 (mnesia.erl, line 360)
      in call from ejabberd_commands:init/1 (src/ejabberd_commands.erl, line 111)
      in call from gen_server:init_it/2 (gen_server.erl, line 962)
      in call from gen_server:init_it/6 (gen_server.erl, line 917)
    ancestors: [ejabberd_sup,<0.179.0>]
    message_queue_len: 0
    messages: []
    links: [<0.384.0>]
    dictionary: []
    trap_exit: false
    status: running
    heap_size: 610
    stack_size: 28
    reductions: 206
  neighbours:

2024-04-17 22:46:15.107700+02:00 [error] <0.384.0>@supervisor:start_children/2:398 SUPERVISOR REPORT:
    supervisor: {local,ejabberd_sup}
    errorContext: start_error
    reason: {aborted,{node_not_running,ejabberd@localhost}}
    offender: [{pid,undefined},
               {id,ejabberd_commands},
               {mfargs,{ejabberd_commands,start_link,[]}},
               {restart_type,permanent},
               {significant,false},
               {shutdown,60000},
               {child_type,worker}]

2024-04-17 22:46:15.120800+02:00 [debug] <0.385.0>@ejabberd_systemd:terminate/2:133 Terminating ejabberd_systemd (shutdown)
2024-04-17 22:46:15.121057+02:00 [debug] <0.385.0>@ejabberd_systemd:cancel_timer/1:177 Cancelling watchdog timer
2024-04-17 22:46:15.121569+02:00 [critical] <0.179.0>@ejabberd_app:start/2:68 Failed to start ejabberd application: {error,
                                       {shutdown,
                                        {failed_to_start_child,
                                         ejabberd_commands,
                                         {aborted,
                                          {node_not_running,
                                           ejabberd@localhost}}}}}

I also performed an entire OPT substitution but it still fail to start.
Boh , I don't know if something is gone corrupted during the last update and have damaged some libraries .
Everything appeared flawless and the system appear to work fine. (I switched to the first disk for all the tests and I'm writing from it) .
I tried also to reinstall all the apps and libraries mentioned in the dependencies of ejabberd (as if I would install it from source).
I tried to install it also from source and it fail again.
I fear to touch this disk that work. But , I can operate as follow: Use dd to backup again the old working disk.
Despite the regression I'll have two working disk and then operate again the update of everything.
But this time with the option to bump a copy of the database. (to a mysql extension for example).
I'll proceed like this and I will report the result :-)

from ejabberd.

ejabberd do not start after update from 23.10 to 24.02 about ejabberd HOT 5 OPEN

Comments (5)

Related Issues (20)

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent