Opened 2 years ago

Closed 2 years ago

#248 closed defect (fixed)

Neustarts des XMPP-Servers aufklären und abstellen

Reported by: Jens Kubieziel Owned by: Admins für XMPP
Priority: major Component: Dienste/Prosody
Keywords: Cc: berhsi

Description

Derzeit startet der Prosody immer wieder neu:

Jul 20 06:55:44 blaukraut systemd[1]: prosody.service: Main process exited, code=killed, status=9/KILL
Jul 21 06:05:04 blaukraut systemd[1]: prosody.service: Main process exited, code=killed, status=9/KILL
Jul 21 07:00:15 blaukraut systemd[1]: prosody.service: Main process exited, code=killed, status=9/KILL
Jul 21 07:29:34 blaukraut systemd[1]: prosody.service: Main process exited, code=killed, status=9/KILL
Jul 21 17:04:58 blaukraut systemd[1]: prosody.service: Main process exited, code=killed, status=9/KILL
Jul 21 17:11:40 blaukraut systemd[1]: prosody.service: Main process exited, code=killed, status=9/KILL
Jul 21 23:13:06 blaukraut systemd[1]: prosody.service: Main process exited, code=killed, status=9/KILL
Jul 22 03:31:05 blaukraut systemd[1]: prosody.service: Main process exited, code=killed, status=9/KILL
Jul 22 07:25:10 blaukraut systemd[1]: prosody.service: Main process exited, code=killed, status=9/KILL
Jul 22 17:40:18 blaukraut systemd[1]: prosody.service: Main process exited, code=killed, status=9/KILL
Jul 22 21:18:31 blaukraut systemd[1]: prosody.service: Main process exited, code=killed, status=9/KILL
Jul 22 21:57:53 blaukraut systemd[1]: prosody.service: Main process exited, code=killed, status=9/KILL
Jul 23 17:30:46 blaukraut systemd[1]: prosody.service: Main process exited, code=killed, status=9/KILL
Jul 24 08:48:04 blaukraut systemd[1]: prosody.service: Main process exited, code=killed, status=9/KILL
Jul 24 08:50:46 blaukraut systemd[1]: prosody.service: Main process exited, code=killed, status=9/KILL

Bernd hat herausgefunden, dass es unmittelbar vorher eine große Zahl an Verbindungen von jabber.no-sense.net gibt:

grep -a "Jul 23 17:2" /var/log/prosody/prosody.log | grep jabber.no-sense | wc -l
35404
grep -a "Jul 24 08:4" /var/log/prosody/prosody.log | grep jabber.no-sense | wc -l
28784

Daher ist die aktuelle Arbeitshypothese, dass es Probleme mit diesem Server gibt. Wir haben versucht, mittels iptables Verbindungen zu dem Host zu verwerfen. Ziel ist es, herauszufinden, ob der XMPP-Server weiterhin abstürzt.

Im Allgemeinen müssen wir untersuchen, woher das Problem kommt und die richtigen Schritte einleiten.

Change History (4)

comment:1 by Jens Kubieziel, 2 years ago

So als Datenpunkt:

qbi@blaukraut:~$ (sudo iptables -L -v; sudo ip6tables -L -v) | grep jabber.no-sense.net
    3   180 REJECT     all  --  any    any     jabber.no-sense.net  anywhere             reject-with icmp-port-unreachable
    2   160 REJECT     all      any    any     jabber.no-sense.net  anywhere             reject-with icmp6-port-unreachable
qbi@blaukraut:~$ sudo systemctl status prosody.service  | grep Active:
   Active: active (running) since Fri 2020-07-24 08:50:47 CEST; 1 day 16h ago

Das heißt, es wurden je zwei Pakete verworfen innerhalb des letzten Tages verworfen und es ist noch kein Restart zu beobachten.

comment:2 by Jens Kubieziel, 2 years ago

qbi@blaukraut:~$ (sudo iptables -L -v; sudo ip6tables -L -v) | grep jabber.no-sense.net
    8   480 REJECT     all  --  any    any     jabber.no-sense.net  anywhere             reject-with icmp-port-unreachable
    7   560 REJECT     all      any    any     jabber.no-sense.net  anywhere             reject-with icmp6-port-unreachable
qbi@blaukraut:~$ sudo systemctl status prosody.service  | grep Active:
   Active: active (running) since Fri 2020-07-24 08:50:47 CEST; 1 weeks 1 days ago

comment:3 by Jens Kubieziel, 2 years ago

Ich habe versucht, zu dem Admin des Servers Kontakt aufzunehmen. Bisher gab es keine Rückmeldung.

comment:4 by Jens Kubieziel, 2 years ago

Resolution: fixed
Status: newclosed

Das Problem hat sich mit der obigen Lösung erledigt. Sinnvollerweise sollte man das mit Kommunikation mit dem anderen XMPP-Server klären. Bisher sind die Versuche ohne Erfolg damit mache ich das Ticket erstmal zu. Die Reboots lagen offensichtlich an dem obigen Problem und sind mit der Sperrung verschwunden.

Note: See TracTickets for help on using tickets.