>>> Michael Biebl <mbiebl@xxxxxxxxx> schrieb am 26.02.2020 um 10:39 in Nachricht <CAGWsdOgAep0+kVNsmsnLaLTNZB9sLUGHMmXDU2+UhgOO0SroOw@xxxxxxxxxxxxxx>: > Am Mi., 26. Feb. 2020 um 10:13 Uhr schrieb Ulrich Windl > <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx>: >> >> >>> Vito Caputo <vcaputo@xxxxxxxxxxx> schrieb am 25.02.2020 um 01:01 in >> Nachricht >> > <7343_1582589314_5E546582_7343_4690_1_20200225000143.nowls5peec5sxg7v@shells.g > nu >> >> eneration.com>: >> > Hello list, >> > >> > Today I experienced an unclean shutdown due to battery dying unexpectedly, >> > and it left my /var in a state requiring a manual fsck to repair errors. >> >> I wonder: Shouldn't be a fsck just be a journal reply these days? For ext >=3 >> this should be quite fast. ReiserFS was rather slow several years ago (it > did >> replay too much IMHO), but haven't used it the last five years. >> >> > >> > The normal startup process failed and dropped me to a rescue shell after >> > asking for my root password. But I was unable to immediately run fsck >> > manually, because systemd was endlessly trying to fsck /var. >> >> That's not a problem of fsck. > > > I suspect that the real problem is, that fsck failed to fix the file > system, so as a result, systemd tried repeatedly to start the fsck job > for /var as var.mount was pulled in as a dependency (e.g. for > journald). The exit code should help: The exit code returned by fsck is the sum of the following conditions: 0 - No errors 1 - File system errors corrected 2 - System should be rebooted 4 - File system errors left uncorrected 8 - Operational error 16 - Usage or syntax error 32 - Fsck canceled by user request 128 - Shared library error _______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel