[systemd-devel] Antw: Re: Antw: [EXT] Infinite loop at startup on var fsck failure

[Ulrich Windl]

>>> Michael Biebl <mbiebl at gmail.com> schrieb am 26.02.2020 um 10:39 in Nachricht
<CAGWsdOgAep0+kVNsmsnLaLTNZB9sLUGHMmXDU2+UhgOO0SroOw at mail.gmail.com>:
> Am Mi., 26. Feb. 2020 um 10:13 Uhr schrieb Ulrich Windl
> <Ulrich.Windl at rz.uni-regensburg.de>:
>>
>> >>> Vito Caputo <vcaputo at pengaru.com> schrieb am 25.02.2020 um 01:01 in
>> Nachricht
>> 
> <7343_1582589314_5E546582_7343_4690_1_20200225000143.nowls5peec5sxg7v at 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