[systemd-devel] fsckd needs to go

[Didier Roche]

Le 03/04/2015 14:58, Lennart Poettering a écrit :
> Heya,

Hey Lennart,
>
> 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...
I misunderstood first what you wanted in 2011, reading back from the 
mailing list. You would have noted that no comment (even on the first 
review which were made) raised those points in the multiple reviews that 
occured, hence it was merged. It's weird that it doesn't even boot your 
own machine reliably, as we have the first implementation running on all 
vivid machines by default, and it seems from the bug reports, reliably.

However, I'm a bit surprised about the statement that no attempt has 
been done to fix it. I think you saw I have always been responsive, 
prioritizing your suggestions over other work to fix them. When you did 
your first public personal reserves about fsckd on the mainling list and 
I understood what flow you wanted[1], I posted fixes *the day after* 
(with some back and force review) to address your comments.

All of them were merged by other systemd hackers and some even by 
ourself, but the biggest one, which directly addressed and implemented 
the flow of data you explicitly asked for is still waiting: 
http://lists.freedesktop.org/archives/systemd-devel/2015-March/029309.html 
(Note that this was proposed less than 48 hours after your complain 
about the data flow). Knowing that you were on holidays, I didn't push 
others too much, but Martin and I pinged you on IRC about it when you 
were back. Am I missing anything?

>
> 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.
I can understand those points, just a little bit disappointed that 
wasn't stated months ago, when we started to work on it and before the 
whole refactoring…

>
> 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).
Not sure we are going so close to vivid finale, changing it again. We 
did implement all your suggestions and fixed it to match those. I'm 
feeling a little bit uneasy about how all this turned out, showing such 
good willing to get it contributed upstream we put into it, but if 
that's the fate of it…

Didier


[1] 
http://lists.freedesktop.org/archives/systemd-devel/2015-March/029186.html