On Tue, Jan 13, 2015 at 10:57:32AM +0100, Cedric Ware wrote:
>
> Thank you. Indeed, I wasn't sure where to file this bug; I chose e2fsck
> because it had suffered from a similar one, and it seemed easier to fix
> as you did than to replace systemd-fsck's "while(!feof) { fscanf }" loop
> with something much more complicated...
>
> OTOH, thinking about it, other filesystems' fsck utilities might be
> affected too, not just e2fsck.
Well, the -C option is to date only honored by e2fsck. In fact
/sbin/fsck will only pass the -C option to fsck.ext[234].
systemd-fsck replaces /sbin/fsck, as part of systemd's "we will
reimplement the entire low-level stack, incompatibly" mission
statement, but I don't know of any other fsck programs which are using
this feature.
For that matter, I wasn't aware that anyone other than Ubuntu's
graphical boot is using it --- I have no idea why systemd-fsck would
care about the progress bar information, and how or why it might be
using it in the first place. If I have time I'll have take a look at
the systemd-fsck sources, but that's neither here nor there.
> > This isn't an RC bug by any means (I don't think it even rates
> > "important") since very few people are using the e2fsck.conf logging
> > capabilities --- most debian users pre-systemd have been been using
> > /var/log/fsck/*, and systemd will do its own journalctl thing.
>
> I'm not as well-versed as I'd like in the various logging mechanisms, but
> given that /var/log/fsck isn't mounted RW at this stage of the boot,
> doesn't logging there require e2fsck.conf logging?
Well, /etc/init.d/chroot{fs,root}.* both use the logsave command,
which is esparate from the e2fsck.conf logging. I'll be honest; the
original reason why I implemented e2fsck.conf logging was for Google's
internal use, because we wanted separate log files for each file
system that was being checked. It's not something I've really
advertised, and given that logcheck has existed for years and years,
my expectation was that most of the distributions had beenusing
logcheck and weren't going to be using the e2fsck.conf logging scheme.
If Jessie hadn't gone systemd, I probably would have some point tried
to submit patches to transfer the logging from the init.d scripts and
ssyte logsave to the e2fsck.conf system, but in the mean time, systemd
happened, and systemd has its own way of trapping all stdout
information from various init scripts and system daemons.
(Which leads to another problem, which is some daemons are extremely
chatty because they didn't expect their stdout to be captured, leading
to /var/log/journal bloat and excessive SSD wear, but that's an issue
for another day. And since we aren't enabling persistent journalctl
logs in Jessie, it's doesn't affect Debian yet.)
In any case, this unfortunate interaction between the -C option and
e2fsck.conf logging is only really going to affect those users who
found the logging scheme described in the e2fsck.conf man page and
decided to use it that would be affected by this bug in Jessie.
Granted, there may be people who didn't know about /var/log/fsck,
and/or haven't figured out how to extract this information from
journalctl, but I expect it to be a relatively small number.
My understanding is that the release team is trying very hard to get
Jessie out the door, and so I don't want to try to push things,
especially since most debian users probably won't have discovered this
particular e2fsck.conf feature.
BTW, logsave has the same bug, but systemd-fsck doesn't use logsave,
and it's harder to fix in logsave because (a) it's supposed to be a
general purpose program, and having it sniff argv[] of its child would
be a rather unfortunate abstraction layer, and (2) it turns out
portably closing all file descriptors which are open is actually quite tricky:
http://stackoverflow.com/questions/1315382/closing-all-open-files-in-a-process
http://stackoverflow.com/questions/899038/getting-the-highest-allocated-file-descriptor
- Ted
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
