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