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

[Lennart Poettering]

On Mi, 26.02.20 10:39, Michael Biebl (mbiebl at gmail.com) wrote:

> 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.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