Le 10/03/2015 08:33, Martin Pitt a écrit :
Lennart Poettering [2015-03-09 19:11 +0100]:
Oh, and I am only realizing now that the whole thing doesn't do *at
all* what we discussed. The idea was to invoke the actual fsck tools
with their stdout connected directly to fsckd. Instead the old
systemd-fsck tool still is the one that parses the fsck output and
which now simply forwards that info.
That didn't actually come up during review, but that sounds like a
nice idea! I see two structures:
- s-fsck runs fsck and forwards its stdout/err fds to fsckd, and then
fsckd does all the parsing. This would also automatically eliminate
the intermediate socket handling from above.
We will still need the cancel message back socket (so below).
Or, more radically:
- eliminate the current functionality of s-fsck and just make that
send a request to s-fsckd to check a new device name. s-fsckd
would then spawn off /usr/sbin/fsck by itself and start parsing its
output. That's more complex handling of its children (but not too
bad), and completely avoids passing around data through sockets,
and s-fsck would be a trivial five-liner.
Just a note if we go that path, then systemd-fsck*.service would always
be successful as only passing the request, but then, any cancellation of
a fsck in progress or worse, any fsck failing won't mark the
corresponding systemd-fsck@ instance as failed.
Cheers,
Didier
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
