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) _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel