On Mi, 26.02.20 10:39, Michael Biebl ([email protected]) wrote: > Am Mi., 26. Feb. 2020 um 10:13 Uhr schrieb Ulrich Windl > <[email protected]>: > > > > >>> Vito Caputo <[email protected]> schrieb am 25.02.2020 um 01:01 in > > Nachricht > > <7343_1582589314_5e546582_7343_4690_1_20200225000143.nowls5peec5sx...@shells.gnu > > > > 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 question is: why *repeatedly* though? i.e. why does it keep doing that if nothing else happens? journald should not trigger that all the time... Also, there's actually a safety condition in place, the start limit logic: after a service has been attempted to be started too often within a time window we refuse starting it again... So I am a bit puzzled about this. Some logs would be great to have about this... Lennart -- Lennart Poettering, Berlin _______________________________________________ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
