[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

[Martin Pitt]

Lennart Poettering [2015-03-09 19:11 +0100]:
> Anyway, please look into fixing this, I am kinda relying on patches
> for this, as I don't use this myself. Fedora isn't set up for it, nor
> do I use a file system that still requires fsck at boot...

Yep, we'll fix those. But for the record, this can be tested easily
anywhere by replacing /usr/sbin/fsck with test/mocks/fsck (I'm on
btrfs myself..)

Lennart Poettering [2015-03-09 19:45 +0100]:
> 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.

We did talk about using a SOCK_DGRAM socket, but for some reason they
can only be used in a connectionless mode on the server, i. e. you
cannot listen() on them. This means that s-fsckd will never know in a
timely fashion when a client disconnected or died, so you can only
stop doing stuff after some generously long timeout. That's why this
uses a SOCK_STREAM, but it does use send() and recv() to send messages
in one block. To guard against broken/malicious clients, fsckd kicks
connections which send malformed data.

This could potentially made more explicit by using SOCK_SEQPACKET;
we'd still need to check for short/malformed data of course, so that
check can't go away entirely. But it at least stops clients trying to
open in stream mode and send characters. But the only client here is
our own s-fsck, so this is all internal anyway..

Lennart Poettering [2015-03-09 19:47 +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.

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.

Does that sound better/easier?

Thanks,

Martin

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)