[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
didrocks at ubuntu.com
Tue Mar 10 00:39:44 PDT 2015
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.
More information about the systemd-devel