Beiträge von hchristo

Danke für die Aufklärung! Bestätigt: Nach dem systemctl restart lcpolicyd hat die Datei /var/lib/liveconfig/lcpolicyd.db jetzt korrekt die Spalte:

CREATE TABLE USERS ( U_ID INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, U_USER VARCHAR(255) NOT NULL,  U_LIMIT_1_INTERVAL INTEGER NOT NULL, U_LIMIT_1_LIMIT INTEGER NOT NULL,  U_LIMIT_2_INTERVAL INTEGER NOT NULL, U_LIMIT_2_LIMIT INTEGER NOT NULL,  U_LASTTS INTEGER, U_SEND_STATUS TINYINT DEFAULT 0 NOT NULL,  U_REJECTED_COUNT INTEGER DEFAULT 0 NOT NULL);

(Meine ursprüngliche Annahme, dass es sich um eine fehlende Spalte in der MySQL-Haupt-DB handelt, war falsch — ich hatte dort eine Spalte ergänzt, die keinen Effekt hatte, und habe sie wieder entfernt.)

Zeitlicher Ablauf laut Journal:

• 14:23:17 — lcpolicyd startet zum ersten Mal nach dem Upgrade (kein Fehler im Journal zu diesem Zeitpunkt sichtbar)
• 14:36:41 — erster [ERR] no such column: U_REJECTED_COUNT (offenbar der erste tatsächliche Login-Versuch nach dem Upgrade, ca. 13 Minuten nach dem Start)
• Fehler tritt danach bei jedem Login-Versuch wiederholt auf (mehrfach bis 16:24 Uhr protokolliert)
• 16:27:49 — manueller systemctl restart lcpolicyd → danach keine Fehler mehr, Spalte korrekt vorhanden

Das deutet darauf hin, dass die Migration beim allerersten Start (ausgelöst durchs Paket-Postinst) nicht korrekt durchlief, ein manueller Neustart später aber problemlos funktionierte.

Angeforderter Ausschnitt aus /var/log/apt/term.log (kompletter Log-Block für den Upgrade-Vorgang):

Log started: 2026-08-19  14:23:06
Entfernen von liveconfig (2.19.1-release) ...
Vormals nicht ausgewähltes Paket liveconfig3 wird gewählt.
Vorbereitung zum Entpacken von .../liveconfig3_3.2.4-1.17979_amd64.deb ...
Entpacken von liveconfig3 (3.2.4-1.17979) ...
liveconfig3 (3.2.4-1.17979) wird eingerichtet ...
Created symlink '/etc/systemd/system/multi-user.target.wants/lcbackup.service' → '/usr/lib/systemd/system/lcbackup.service'.
Trigger für man-db (2.13.1-1) werden verarbeitet ...
Trigger für libc-bin (2.41-12+deb13u3) werden verarbeitet ...
Log ended: 2026-08-19  14:23:19

Auffällig: Im Log wird nur der lcbackup.service-Symlink explizit erwähnt, kein Hinweis auf einen lcpolicyd-Neustart durch das Postinst-Skript selbst (der laut journalctl aber trotzdem um 14:23:17 erfolgte — vermutlich durch einen separaten systemctl restart-Aufruf im Postinst, der in diesem Log-Ausschnitt nicht mitgeschrieben wird).

Danke nochmal, insgesamt also kein LiveConfig-weiter Bug, sondern ein einmaliger Migrations-Hänger beim ersten Start nach dem Upgrade, der sich per Neustart beheben ließ.

Umgebung

• LiveConfig-Version: 3.2.4 (Build 17979), Paket liveconfig3
• Vorherige Version: 2.19.1-release (Upgrade von 2.x auf 3.x, kein Neuinstall)
• OS: Debian
• Datenbank: MariaDB (Connector/C 3.4.9)
• Mailsystem: Postfix mit lcpolicyd als Autorisierungs-Policy-Dienst (authorized_submit_users via socketmap:unix:/var/run/lcpolicyd-lookup.sock:user)

Symptom

Nach dem Upgrade auf 3.2.4 schlägt jeder Login im LiveConfig-Panel (Web-UI, POST /liveconfig/app/login) mit folgendem Fehler fehl:

Login failed
An internal server error has occured. Please check the log file for more details.

Root Cause

Beim erfolgreichen Login versucht LiveConfig, eine Sicherheits-Benachrichtigungsmail zu versenden (z. B. "Anmeldung mit neuem Gerät"). Dieser Versand ruft /usr/sbin/sendmail auf, welches über den lcpolicyd-Socket die Absenderberechtigung prüft. Diese Prüfung schlägt fehl:

sendmail: warning: socketmap:unix:/var/run/lcpolicyd-lookup.sock:user socketmap server permanent error: Lookup error. please try again later!
sendmail: fatal: authorized_submit_users: socketmap:unix:/var/run/lcpolicyd-lookup.sock:user: table lookup problem

Der resultierende Exit-Code 75 von sendmail führt zu einer unbehandelten Exception im LiveConfig-Server-Prozess, die den gesamten Login-Request abbricht:

[EMERG] Uncaught exception: /usr/sbin/sendmail returned with exit code 75
[EMERG] METHOD: POST; URL: /liveconfig/app/login
[EMERG] Got exception: std::runtime_error

Im lcpolicyd-Log (/var/log/liveconfig/lcpolicyd.log) findet sich die eigentliche Ursache:

[ERR] no such column: U_REJECTED_COUNT

Die Spalte U_REJECTED_COUNT in der Tabelle liveconfig.USERS fehlt nach dem Upgrade komplett — offenbar wurde der entsprechende Datenbank-Migrations-Patch beim Upgrade von 2.19.x auf 3.2.4 nicht (vollständig) ausgeführt, obwohl der Log beim Start mehrere Patches auflistete (Applying database patch 3.00.00 bis 3.03.01).

Workaround (selbst angewendet, funktioniert)

ALTER TABLE liveconfig.USERS ADD COLUMN U_REJECTED_COUNT INT NOT NULL DEFAULT 0;

Anschließend systemctl restart lcpolicyd (der Dienst hatte die fehlschlagende Query offenbar zwischengespeichert/vorbereitet und musste neu starten, um die neue Spalte zu erkennen).

Nach diesem Fix funktionieren Login und Sicherheits-Benachrichtigungsmails wieder einwandfrei.

Vorschlag

Bitte den Datenbank-Migrationspfad für Upgrades von 2.19.x auf 3.x prüfen — der Patch, der U_REJECTED_COUNT (vermutlich Teil einer neuen Brute-Force-/Rate-Limiting-Funktion für Logins) anlegt, scheint bei bestehenden Installationen mit Upgrade-Historie nicht zuverlässig zu greifen.

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.

Es werden ja gem. Changelog ja viele Fehler ausgemerzt.
Meine Frage ist: Ist liveconfig 3 mittlerweile nutzbar so wie Liveconfig 2 oder sollte man noch die Finger von lassen.

Freue mich auf die Umfrageergebnisse

Zitat von weltmeister

Endlich mal vernünftige Leute hier!

Nicht nur das: Laravel, GIT Integration, PHP Composer, und ne WAF (Web aplication Firewall) wäre geil.

Antrag unterstützt!

@marinal was haste gelöscht und warum?

In der zeit hättest du nen Testkunden anlegen können um das zu Testen.

Hab bereits Roundcube 1.7 im einsatz.

→ H a f t u n g s a u s s c h l u s s ←

Diese Anleitung wurde nach bestem Wissen erstellt und nur auf meinem Eigenen Server getestet und Umgesetzt.

Es gibt jedoch keine Garantie auf Funktion, Sicherheit oder Vollständigkeit.

Die Umsetzung erfolgt auf eigene Gefahr und Verantwortung.

Der Autor übernimmt keine Haftung für Schäden, Datenverluste, Sicherheitsrisiken oder sonstige negative Folgen.

Die Anleitung richtet sich ausschließlich an erfahrene Administratoren.

Wenn du Upgraden möchtest hier meine Config files (im Anhang meines Posts):
Webmail Domain einstellungen:

Meine Mailserver Settings:

Vielleicht hilft das jemanden.

Ladet euch die neuste Version von Roundcube runter, und ersetzt den Ordner "config" und die "composer.json" im Rootverzeichnis von Roundcube durch meine im ZIP Gepackten Dateien.

Ich selber habe Roundcube WebMail nicht als APP in der Installation, ich hab das damals in meinem Webspace verlagert für meine Kunden.
Daher beruht diese "Anleitung" auf eine eigenständige Installation.

Bitte beachtet dass die Verzeichnisrechte danach erneut gesetzt werden müssen, je nach Inhaber, in meinem fall ist das Gruppe/Nutzer: hchristo:hchristo
Ebenfalls müssen für die Datei config.inc.php in dem Ordner config die Datenbankparameter angepasst werden.

Um das in betrieb zu nehmen muss der Composer runtergeladen werden:

1. mit cd /pfad/zu/roundcubemail navigieren wir ins Roundcube Root Verzeichnis.
2. jetzt muss der Composer runtergeladen werden, das geht mit curl -s https://getcomposer.org/installer | php
   Setze die Rechte auf die Datei "composer.phar" entsprechend dem welches auch die Rechte zum Roundcube Root Verzeichnis hat.
3. Anschließend führen wir im Roundcube Root Verzeichnis sudo -u <Verzeichnisinhaber> /opt/php-8.4/bin/php --define apc.enable_cli=1 composer.phar install
   Hinweis: Dadurch werden die Plugins in meiner hinterlegten Roundcube Config aktiv: acl, emoticons, newmail_notifier, password, userinfo, redundant_attachments, zipdownload, markasjunk, managesieve, account_details, libkolab, libcalendaring, calendar, tls_icon, show_folder_size
4. ggf. kann man noch nen Update hinterher hauen sudo -u <Verzeichnisinhaber> /opt/php-8.4/bin/php --define apc.enable_cli=1 composer.phar update
5. Bei fragen, meldet euch gerne dazu bei mir...

Mag sein dass das Team von Liveconfig klein ist. Aber dann sollte auch mal offen gesprochen werden!
Themen zu Ignorieren seitens Liveconfig ist nicht die Lösung des Problems.

Es kann ja gesagt werden: "Die und die Funktion wird nicht umgesetzt!"

Dann kann man sich wenigstens darauf einstellen dass da nichts kommt. Ich bin auch bereit 20 oder 30€ Mon für Liveconfig zu bezahlen, wenn die gewünschten Funktionen von den es in dem Liveconfig Forum massenhaft gibt, auch umgesetzt werden.

Dieses Thema beispielweise: Github, in 2018 angefragt, in 2019 noch mal kurz darauf eingegangen, dann nichts mehr...

Viele Funktionen die andere Systeme schon Ewigkeiten haben, fallen hier aus der reihe.

Zitat von weltmeister

2046 sollte evtl. frühestens damit zu rechnen sein

Wenn <das Böse Wort> nicht so unfassbar Teuer wäre, hätte ich schon laaange von LC zu PLSK gewechselt.

+1

Der Wandel geht immer mehr zu Laravel Entwicklungen mit Deploy zu GitHub/GitLab.
Eine GIT und Laravel Integration wird immer wichtiger!

Mir ist nach dem Upgrade von Debian 12 auf Debian 13 aufgefallen, dass keine TLS-Verbindung mehr möglich war. Ursache war ein fehlendes TLS-Modul.

Falls jemand das gleiche Problem hat, hier die Lösung.

Fehlermeldung (z. B. in WinSCP)

proftpd AUTH not understood

Ursache

Das TLS-Modul mod_tls war nach dem Upgrade nicht mehr installiert bzw. geladen.

Lösung

Zuerst das fehlende Modul nachinstallieren:

apt install proftpd-mod-crypto

Danach in der Datei:

/etc/proftpd/modules.conf

die Raute (#) vor folgender Zeile entfernen:

LoadModule mod_tls.c

Anschließend die Konfiguration neu laden (z. B. über LiveConfig) – danach funktionieren TLS-Verbindungen wieder.

Optional: TLS standardmäßig erzwingen

Wer TLS verpflichtend nutzen möchte, kann zusätzlich in folgender Datei:

/etc/proftpd/tls.conf

die Raute (#) vor dieser Zeile entfernen:

TLSRequired on

Danach ebenfalls die Konfiguration neu schreiben oder den Dienst neu starten:

systemctl restart proftpd

(alternativ: service proftpd restart)

+ 1 Antrag unterstützt

Zitat von weltmeister

der ist es doch noch besser abzuwarten?

Fohes neues Jahr!

Wie geschrieben, ich werde weiterhin warten mit LC3, ich beobachte die LC3 Beiträge & Changelogs.
Wenn ich für mich das gefühl bekomme dass LC "Stable" ist, dann upgrade ich und berichte natürlich auch wieder.

Hallo zusammen,

ich wollte mal meine jüngste Erfahrung beim Upgrade von LC2 auf Debian 13 teilen – vielleicht hilft es ja dem ein oder anderen, der sich auch gerade auf den Sprung wagt.

Also: Upgrade wie immer durchgeführt, brav die Anleitung von Liveconfig befolgt – alles schien sauber zu laufen.

Dann kam der große Schock: apt autoremove hat beschlossen, mir einfach mal ein paar essentielle Pakete zu deinstallieren. Ja, richtig gelesen. Essenzielle Pakete wie:

• apache2

• nginx

• opendkim

• bind9

• proftpd

• clamav

Keine Ahnung, warum. Vielleicht ein „Feature“ von Debian 13, vielleicht ein kleiner Spaß der Paketverwaltung. Hätte ich Prüfen müssen was er deinstalliert: Klar, aber ich hab mich auf die anleitung verlassen!

Fakt ist: Mein Server fühlte sich plötzlich ziemlich nackig an.

Danach musste ich einiges manuell nachinstallieren und hoffen, dass alles wieder stabil läuft.

Besonders spannend bleibt: Ich hoffe inständig, dass Liveconfig seine child Prozesse nicht im Laufe des Tages die Biege macht – die Nerven liegen noch blank.

Fazit bisher: Upgrade technisch machbar, aber autoremove kann dir mitten in der Nacht eine echte Überraschung liefern. Also Augen auf und Backup bereithalten, Leute!

Hat jemand ähnliche Erfahrungen gemacht oder Tipps, wie man das beim nächsten Upgrade sauberer umgeht?

Traue ich mich das Upgrade auf LC3? Im Leben erst mal nicht, ich werde wohl noch bis ende des Jahres warten und den Support für LC2 so lange wir möglich mitzunehmen.

Ohne witz, Ich tendiere mittlerweile echt zu der Etwas teureren Hosting variante dessen name nicht genannt werden darf... Liveconfig fühlt sich Unstabil und sensibel an... oder täuscht das?

Mehr wollte ich nicht, nur nen erfahrungsbericht meiner seits.

kk Sehen Sie was sich Kunden wünschen?
Und das nicht nur heute, sondern Jaaaaaaahhhhhreeeee!

Ich bin parallel zu Liveconfig am Testen, aktuell KeyHelp von Keyweb.

Zur not beiß ich in den Sauren Apfel und Installier Plesk, das bietet wenigstens alles was Liveconfig verpsricht.

Muss ehrlich sagen dass mir Liveconfig langsam überhaupt nicht mehr gefällt. Liveconfig 3 läuft Instabil, Liveconfig 2 is auch nicht das wahre.
Essenzielle Funktionen werden erst jahrzehnte Später implementiert, die WebUI von LC3 sieht aus wie 1995, bei Last (Packen von archiven, Script Basiertes Kopieren von archiven weil LC Backup immer noch kacke ist und keine Externen Backups zuläst unter LC2) stürzen die Child Prozesse ab und allgem läuft das gefühlt extrem Instabil.

Für nen 10er im Monat kann man offensichtlich nicht viel erwarten, ich war zu anfang echt begeistert, aber mittlerweile hat trotz Preiserhöhung die Quallität echt nachgelassen.

Zitat von informant

hi all, ich habe mir ein script gebaut was die passwd datei wieder korrigiert, wer den fehler also auch hat kann sich gern bei mir melden bzgl. des scriptes.

ich hoffe lc findet den fehler, warum nur einige zeilen korrekt in der datei stehen und die anderen falsch.

mfg

Ungetestet (!!!) Aber hier wäre ein von ChatGPT vorgeschlagenes Script

#!/bin/bash
# fix_dovecot_passwd.sh
# Korrigiert falsche Einträge in /etc/dovecot/passwd, bei denen der Mailpfad unvollständig ist.

PASSWD_FILE="/etc/dovecot/passwd"
BACKUP_FILE="/etc/dovecot/passwd.bak_$(date +%Y%m%d_%H%M%S)"

# Backup anlegen
cp "$PASSWD_FILE" "$BACKUP_FILE"
echo "Backup erstellt: $BACKUP_FILE"

# Datei zeilenweise prüfen und korrigieren
awk -F: '
{
    # Prüfen, ob der 6. Feldteil (Home) fehlerhaft ist
    if ($6 == "/var/mail") {
        # Benutzername aus Feld 1 extrahieren (z. B. slu4300/8 aus userdb_mail-Pfad)
        match($0, /userdb_mail=maildir:\/var\/mail\/([^/]+\/[0-9]+)/, m)
        if (m[1] != "") {
            # Homepfad korrekt zusammensetzen
            $6 = "/var/mail/" m[1]
        }
    }
    # korrigierte Zeile ausgeben
    OFS=":"; print $0
}' "$PASSWD_FILE" > "${PASSWD_FILE}.fixed"

# Wenn das neue File gültig ist (nicht leer etc.), ersetzen
if [ -s "${PASSWD_FILE}.fixed" ]; then
    mv "${PASSWD_FILE}.fixed" "$PASSWD_FILE"
    echo "Korrektur abgeschlossen. Datei wurde aktualisiert."
else
    echo "Fehler: Keine gültige Ausgabe erzeugt. Originaldatei bleibt unverändert."
    rm -f "${PASSWD_FILE}.fixed"
fi

Was das Script tut:

• Legt eine Sicherung der Originaldatei an

• Sucht Zeilen, wo $6 == "/var/mail" ist

• Liest aus der userdb_mail=maildir:/var/mail/...-Angabe den korrekten Unterpfad heraus

• Fügt ihn wieder in die 6. Spalte ein

• Schreibt die korrigierte Datei zurück

+1 Antrag unterstützt. Ich habe das auch hin und wieder und das is Ultra nervig. Meistens tritt das auf wenn die großen Daten/Mails oder Datenbanken nicht innerhalb einer gewissen zeit gelöscht werden kann... das ist Ultra nverig