[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

[Lennart Poettering]

On Tue, 10.03.15 08:39, Didier Roche (didrocks at ubuntu.com) wrote:

> 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).

Use SO_PEERCRED from the systemd-fsckd side to identify the PID of the
connected fsck instance. Then, send the SIGTERM directly to
it. There's no need to proxy this off systemd-fsck.

Lennart

-- 
Lennart Poettering, Red Hat