[systemd-devel] fsckd needs to go

[Lennart Poettering]

Heya,

so we discussed the whole fsckd situation a bit more here in Berlin,
and we came to the conclusion that fsckd really should not exist the
way it does in systemd.

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!). And to my knowledge there has been no attempt to fix all of
that, even though I asked for it. 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. systemd is supposed to be a few components playing well
together, but certainly not a baroque network of components where data
is passed though four hoops before it reaches the destination...

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, and the idea to kill an fsck process
while it is running is also very very questionnable. There's a reason
why such functionality never existed on Fedora or RHEL: it's risky. I
mean, it's all good allowing people to shoot themselves in the foot,
but there's really *no* point in making that easy and giving it a
fancy UI with support in the graphical boot splash. Shooting yourself
in the foot should be possible, but not *easily*! And certainly not be
allowed without prior authentication like you are doing it right now
with the plymouth support.

Thus, we decided to remove fsckd again entirely from systemd. However,
if Ubuntu really wants to implement this anyway (I strongly
believe that this is an absolute misfeature!), then I'd be willing to
add the following for you:

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?

Lennart

-- 
Lennart Poettering, Red Hat