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
_______________________________________________
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
