Absturzbericht: liveconfig.service beendet sich beim Shutdown mit SIGABRT (uncaught signal 6)

Kleiner Crashbericht für Liveconfig v2:

Absturzbericht: liveconfig.service beendet sich beim Shutdown mit SIGABRT (Signal 6)

======================================================================================

Umgebung: Debian GNU/Linux 13 (trixie), LiveConfig 2.19.1-release.

Auslöser: regulärer System-Reboot (systemctl reboot), kein Crash im Normalbetrieb.

Zusammenfassung

---------------

Beim Reboot am 2026-08-14 ca. 22:16-22:17 Uhr hat sich liveconfig.service nicht

sauber beendet, sondern nach ca. 60s mit Backtrace und SIGABRT terminiert. Der

Versuch, den Crash-Report an update.liveconfig.com zu senden, schlug fehl, weil

das Netzwerk beim Shutdown bereits abgebaut war.

Ablauf (aus /var/log/liveconfig/liveconfig.log, PID 11366=Haupt-, 11367=Serverkind)

------------------------------------------------------------------------------------

1. 22:15:11 - Serverkind (11367) verliert MySQL-Verbindung, weil MariaDB im

selben Reboot ebenfalls gestoppt wird. Reconnect-Loop mit Backoff startet:

1s -> 2s -> 4s -> 8s -> 16s -> 32s.

2. 22:16:14 - systemd sendet SIGTERM an den Hauptprozess, um den Dienst zu

stoppen. Das Serverkind steckt gerade im 32s-Sleep des Reconnect-Loops und

reagiert nicht.

3. 22:17:14 (60s später) - systemd eskaliert, sendet SIGTERM erneut, diesmal

direkt von PID 1. Das Serverkind terminiert daraufhin mit nicht abgefangenem

Signal 6 (Aborted).

4. Der Hauptprozess loggt einen Backtrace und versucht erfolglos, den Crash

automatisch zu melden (HTTPClient: connection error, state=7), da das

Netzwerk zu dem Zeitpunkt schon gestoppt war. 22:17:18 - "LiveConfig

terminated."

Ursache

-------

Der MySQL-Reconnect-Loop im Serverkind reagiert offenbar nicht auf SIGTERM,

während er in seinem Backoff-Sleep blockiert. Erst nach Ablauf von

TimeoutStopSec (65s) und einem zweiten SIGTERM direkt von PID 1 terminiert der

Prozess - dann aber per uncaught SIGABRT statt sauber.

Ausgelöst wurde es dadurch, dass MariaDB im selben Shutdown praktisch

gleichzeitig mit LiveConfig gestoppt wurde: liveconfig.service hat keine

explizite Abhängigkeit zu mariadb.service, daher lief der Reconnect-Loop noch,

als das Stop-Signal kam.

Häufigkeit: einmaliges Auftreten. Weder das vorherige Log (bis 2026-08-01) noch

die Journal-Historie (zurück bis 2026-07-05) zeigen einen zweiten Fall - alle

anderen Stops liefen sauber in unter 1s durch.

Relevanter Ausschnitt aus liveconfig.service (vor dem Fix)

-------------------------------------------------------------

[Unit]
After=network-online.target
[Service]
Type=forking
ExecStop=/usr/sbin/liveconfig -k stop
TimeoutStopSec=65
KillMode=process

-> Keine Abhängigkeit zu mariadb.service vorhanden.

Log-Auszug (Rohdaten, Zeitstempel/PID-Präfix "[2026/08/14 HH:MM:SS.ffffff] [PID|TID]" gekürzt)

--------------------------------------------------------------------------------------------------

Zitat

22:15:11.863 [11367|6860] Lost connection to MySQL server (mysql_stmt_execute), trying to reconnect...

22:15:11.868 [11367|6860] ...trying again in 1 second(s). Error 2002: Can't connect to server on '127.0.0.1' (115)

22:15:12.868 [11367|6860] ...trying again in 2 second(s)...

22:15:13.554 [11367|11376] ERROR: Releasing db connection, but still have running transaction (-> forcing ROLLBACK)

22:15:31.571 [11367|7514] Lost connection to MySQL server (mysql_stmt_execute), trying to reconnect...

22:16:14.869 [11366|11366] Received SIGTERM (from uid=0, pid=8218), immediately terminating child processes

22:16:14.872 [11367|11367] Lost connection to MySQL server (mysql_prepare), trying to reconnect...

22:16:15.873 [11367|11367] ...trying again in 2 second(s)...

22:16:17.874 [11367|11367] ...trying again in 4 second(s)...

22:16:21.874 [11367|11367] ...trying again in 8 second(s)...

22:16:29.875 [11367|11367] ...trying again in 16 second(s)...

22:16:45.875 [11367|11367] ...trying again in 32 second(s)...

22:17:14.879 [11366|11366] Received SIGTERM (from uid=0, pid=1), immediately terminating child processes

22:17:14.885 [11366|11366] Server child process 11367 terminated; uncaught signal: 6 (Aborted)

22:17:14.886 [11366|11366] Backtrace: (liveconfig/server 2.19.1-release)

[0] 000017e734 [1] 0000121b15

[2] 000003fdf0 libc.so.6 [3] 000009495c libc.so.6

[4] 000003fcc2 libc.so.6 [5] 00000284ac libc.so.6

[6] 00000a1a3d libstdc++.so.6 [7] 00000b344a libstdc++.so.6

[8] 00000a14e3 libstdc++.so.6 [9] 00000b2cb0 libstdc++.so.6

[10] 0000022699 libgcc_s.so.1 [11] 0x7f0c68b8d14d

[12] 00000abc0c [13] 000015920a [14] 0000175964

[15] 00001596a7 [16] 0000175c18 [17] 00000fb716

[18] 00000fb7d9 [19] 0000122a63 [20] 00001211ad

[21] 00000bf03a

[22] 0000029ca8 libc.so.6 [23] 0000029d65 libc.so.6

[24] 00000bf5fa

Data[0]: 'STATS'

22:17:14.887 Sending crash report to https://update.liveconfig.com/

22:17:18.079 HTTPClient: connection error (state=7)

22:17:18.080 LiveConfig terminated.

Alles anzeigen

Getestete, funktionierende Lösung

------------------------------------

systemd-Override für liveconfig.service, ergänzt "After=mariadb.service":

nano /etc/systemd/system/liveconfig.service.d/override.conf

[Unit]
After=mariadb.service

systemd stoppt Dienste in umgekehrter Start-Reihenfolge, LiveConfig wird damit

beim Shutdown zuverlässig VOR MariaDB gestoppt - der Reconnect-Loop läuft dann

gar nicht erst in die Race Condition. Verifiziert per:

systemctl show liveconfig.service -p After

-> ...mariadb.service... (enthalten)

Vorschlag an den Support: "After=mariadb.service" (bzw. die jeweils passende

DB-Unit, z.B. mysql.service) direkt ins offizielle liveconfig.service-Template

aufnehmen, damit alle Installationen mit lokaler DB automatisch profitieren -

zusätzlich wäre wünschenswert, wenn der Reconnect-Loop selbst auf SIGTERM auch

während eines laufenden Backoff-Sleeps reagieren würde.

Für andere Admins: passendes Fix-Script als separater Anhang

(fix-liveconfig-shutdown-order.sh, hier als .txt hochgeladen - vor Ausführung

zu .sh umbenennen). Erkennt den DB-Service automatisch, legt den Override an,

kein Neustart von LiveConfig nötig.

mv fix-liveconfig-shutdown-order.sh.txt fix-liveconfig-shutdown-order.sh
chmod +x fix-liveconfig-shutdown-order.sh
sudo ./fix-liveconfig-shutdown-order.sh

Das Script erkennt automatisch euren laufenden Datenbank-Service (mariadb.service/mysql.service/mysqld.service), legt einen systemd-Override für liveconfig.service an und lädt systemd neu. Kein Neustart von LiveConfig nötig, keine Downtime, gefahrlos mehrfach ausführbar.