[systemd-devel] fsckd needs to go

[Martin Pitt]

Hello Lennart, all,

Lennart Poettering [2015-04-03 14:58 +0200]:
> To start with, the code is really wrong, it should never have been
> merged in its current state, the read/write logic for the sockets is
> completely borked (I cannot even boot my own machine reliably with
> it!).

This is surprising indeed. If that's not just the journald/logind/D-Bus
corruption (which we still haven't tracked down properly), do you have
a journal of a hung boot? We never saw a boot failure due to fsck so
far, so I'm naturally very interested in seeing what's wrong.

> And to my knowledge there has been no attempt to fix all of that,
> even though I asked for it.

As far as I see, every point that came up during reviews, including
your recent one about "don't route fsck output through systemd-fsck"
got addressed (that latter patch hasn't been committed though, I
thought you wanted to review it yourself).

> It also doesn't do at all what I suggested initially, as the flow of
> data is now fsck → systemd-fsck → systemd-fsckd → plymouth, and
> that's just crazy, that's two steps too many.

With the above patch it's fsck -> systemd-fsckd → plymouth, and I
don't see how to eliminate yet another step?

> Then, there's my general reservation with fsckd at all: file systems
> that still require offline fsck are certainly not the future, but we
> develop stuff for the future

I do agree with the sentiment; let me assure you that we don't easily
spend days on such stuff in vain, but it's because there are millions
of existing installations out there which still do have ext4 and fsck.
If systemd upstreams say "we don't care about existing products, only
about a future with just btrfs" that's your prerogative of course, but
distros need to have a more product-oriented focus :-/

> systemd-fsckd would try to connect to some AF_UNIX/SOCK_STREAM socket
> in the fs, after forking and before execing fsck in the child, and
> pass the connected socket to fsck via the -C switch. If the socket is
> not connectable it would avoid any -C switch. With this simple change
> you can make this work for you: simply write a daemon (outside of
> systemd) that listens on that sockets and reads the progress data from
> it. Using SO_PEERCRED you can query which fsck PID this is from and
> use it to kill it. You could even add this to ply natively if you
> wish, since it's kinda strange to bump this all off another daemon in
> the middle, unnecessarily.
> 
> Changing this would actually make it very close to my initial
> suggestion, except that we would not have the receiving side for the
> progress data in systemd, you'd have to maintain that externally (or
> in ply). 
> 
> I hope such a solution is acceptable?

The data flow is very similar to what we have now, so this mostly
amounts to maintaining fsckd in the systemd sources vs. maintaining it
separately in Debian/Ubuntu. I'd be interested in what
RHEL/SUSE/Arch/etc. want to do.

Martin

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)