[systemd-devel] [systemd-commits] 9 commits - configure.ac .gitignore Makefile.am Makefile-man.am man/systemd-fsckd.service.xml man/systemd-fsck at .service.xml po/de.po po/el.po po/fr.po po/hu.po po/it.po po/pl.po po/POTFILES.in po/pt_BR.po po/ru.po po/sv.po po/uk.po src/fsck src/fsckd src/shared test/mocks units/.gitignore units/systemd-fsckd.service.in units/systemd-fsckd.socket units/systemd-fsck-root.service.in units/systemd-fsck at .service.in

[Didier Roche]

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