Debian12 - systemd-quotacheck bug? [SOLVED]

[Ralph]

Debian12 / KVM
KH 23.2.1

Mir fällt seit ein paar Tagen ein systemd-quotacheck Problem auf, vor 5 Wochen als Testsystem sind diese Fehler noch nicht aufgetreten, vermutlich durch ein Debian Update verursacht.

quotacheck: Quota for users is enabled on mountpoint / so quotacheck might damage the file.

Code: Select all

# cat /etc/fstab
UUID=xxxxx     /     ext4     noatime,rw,errors=remount-ro,usrquota,grpquota     0     1

Kurzfristige Lösung, hält nur bei reboot aber nicht nach einem Boot wenn der Server vorher runtergefahren wurde:
mount -o remount /
systemctl daemon-reload
quotacheck -avugm
quotaon -avug

Code: Select all

systemd-quotacheck[36858]: (quotacheck) failed with exit status 6.
systemd[1]: systemd-quotacheck.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: systemd-quotacheck.service: Failed with result 'exit-code'.
systemd[1]: Failed to start systemd-quotacheck.service - File System Quota Check.

folgendes habe ich dazu gefunden:
https://github.com/systemd/systemd/issues/29901

Kann das jemand bestätigen ... ist das ein systemd Bug?

Code: Select all

systemctl status systemd-quotacheck

[Ralph]

hmm, das geile ist ja wenn ich danach einen reboot auslöse dann ist der Status meistens wieder OK
hab vorhin mal haveged installiert, dann für 10min gestoppt, gestartet und momentan ist der Status OK ....

Code: Select all

# systemctl status systemd-quotacheck
● systemd-quotacheck.service - File System Quota Check
     Loaded: loaded (/lib/systemd/system/systemd-quotacheck.service; static)
     Active: active (exited) since Mon 2023-11-13 15:04:28 CET; 3min 31s ago
       Docs: man:systemd-quotacheck.service(8)
    Process: 462 ExecStart=/lib/systemd/systemd-quotacheck (code=exited, status=0/SUCCESS)
   Main PID: 462 (code=exited, status=0/SUCCESS)
        CPU: 4ms

im dmesg nichts auffälliges gefunden ... aber an haveged hat es wohl eher nicht gelegen, ist vermutlich gerade nur ein Zufall

was mir aufgefallen ist, wenn ich nur eine Kleinigkeit in der fstab ändere (nach status fail) z.b. noatime hinzufüge oder rausnehme, dann ist nach einem reboot alles bestens ... scheint irgendwo im systemd mit der Aktualisierung aus der fstab etwas zu tun zu haben ...

[Tobi]

Ich liebe deine Threads in denen du dich mit dir selbst über deine Probleme unterhältst.

[OlliTheDarkness]

Ich liebe deine Threads in denen du dich mit dir selbst über deine Probleme unterhältst.

Er weiß halt wie es geht.
Man unterhält sich halt nur mit kompetenten Menschen.

[Ralph]

Ich liebe deine Threads in denen du dich mit dir selbst über deine Probleme unterhältst.

haha, ich auch
aber läuft jetzt wieder, war doch noch ein filesystem fehler vorhanden

[Jolinar]

aber läuft jetzt wieder, war doch noch ein filesystem fehler vorhanden

Wenn du jetzt noch offenbaren würdest, wie du dein Problem gelöst hast, dann wäre das u.U. auch hilfreich für Leute mit ähnlichen/gleichen Problemen, wenn sie irgendwann mal auf der Suche nach einer Lösung für ihr Problem auf diesen Thread stoßen...

[Ralph]

Wenn du jetzt noch offenbaren würdest, wie du dein Problem gelöst hast, dann wäre das u.U. auch hilfreich für Leute mit ähnlichen/gleichen Problemen, wenn sie irgendwann mal auf der Suche nach einer Lösung für ihr Problem auf diesen Thread stoßen...

Nun denn ...
Letzte Woche mußte ich einen hard reset durchführen, weil eines meiner cron scripts fehlerhaft war (dummer tippfehler) ...
Jedenfalls ist das Problem dann sporadisch aufgetreten, bei Debian11 oder 10 wäre die Kiste vermutlich erst gar nicht hochgefahren ohne fsck, Debian12 setzt das remount-ro in der fstab wohl strikt um.
Bin dann gestern Abend 2 Mal in den rescue mode gestartet und hab einen fsck durchgeführt

Code: Select all

e2fsck -f -y /dev/sda1

Das Boot Verhalten wie bei Debian12 kannte ich wie gesagt vorher nicht, früher blieben die verdammten Kisten einfach hängen ...
Hell yeah