[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]

B1;3802;0cOn Mon, 09.03.15 19:45, Lennart Poettering (lennart at poettering.net) wrote:

> On Mon, 09.03.15 19:11, Lennart Poettering (lennart at poettering.net) wrote:
> 
> > - plymouth_feedback_handler() is really broken. Is it supposed to read
> >   from a SOCK_STREAM socket? If so, are all messages exactly 6 bytes
> >   long? If not: the parser will be completely confused by multiple
> >   incoming messages which are coalesced... Also, previously it would
> >   read uninitialized data, if the bytes we read are shorter than
> >   6... I "fixed" that now with a safety check, so that we don't
> >   process uninitialized data anymore, but this really needs to be fixed
> >   properly.
> 
> And in a similar way client_progress_handler() is hosed too. Even
> worse: if a client sends messages byte-wise (which is absolutely OK on
> SOCK_STREAM) it will be kicked off the connection.
> 
> This needs to be fixed.

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.

The idea was to keep this all simple, by not bumping off things by too
many processes. 

Gah, I really don't like this all!

Lennart

-- 
Lennart Poettering, Red Hat