Flawed implementation of automated e2scrub?

[yellowfinch]

After discovering this service, I ended up with the question “What happens if e2scrub_all finds errors? Or if it can’t run because there is not enough unallocated space?”

But this time, rather than tell a story, I decided that a few bullet lists should suffice.

MY OBSERVATIONS:

• According to systemctl list-timers, the e2scrub_all.service script is set to run every Sunday at 3:10 AM, with a randomization of 60 seconds. (More precisely, the scheduling data is found in the file /usr/lib/systemd/system/e2scrub_all.timer.)

• This being a systemd timer schedule, if the system was powered off or suspended at 3:10 AM on Sunday (±1 minute), the job will run as soon as you next log in, or just about. (Not 10 minutes after login, as is the case for anacron weekly jobs.)

• The e2scrub@service script contains: OnFailure=e2scrub_fail@%i.service.

• The e2scrub_fail script merely sends a mail message to root.

• mailutils is not installed by default, so the script will detect that the sendmail command is not available and simply “echo” that it wasn’t found.

• AFAIK, fsck is already run upon booting, before mounting filesystems whose “Filesystem state” is not “clean”, i.e. after an abnormal termination of the OS, for example. That’s all. The default used to be set for an fsck every 30 mounts, but that has since been changed to “never”, as explained in the man page of tune2fs.

MY DEDUCTIONS:

• If e2scrub cannot run (because it finds that the computer is running on battery, or there isn’t at least 256MiB of unallocated space in the volume group, for example), at most there will be a “sendmail program not found” line in some log file.

• If I installed mailutils but e2scrub cannot run, then I’ll know about it only if I manually type the mail command in terminal. (A “new mail” message is probably displayed somewhere along the bootup process but... that usually gets completely hidden or else (if the “quiet” option was omitted) rolls by very quickly.)

• If e2scrub runs properly but finds “corruption” in one of the mounted ext[234] filesystems, I’ll only know about it if I installed the mailutils package and use the mail command at some point before the next reboot. Otherwise, the only hint that there had been some corruption (at least in the filesystem’s metadata) will be that the bootup process will take that much longer, because of the fsck and, presumably, its repair job.

MY TENTATIVE CONCLUSION:
Something is wrong in this design, because...

The man page for the e2scrub command mentions that, if errors are found, “the filesystem should be taken offline and e2fsck run as soon as possible.”

One would first have to know that errors were found!

Does anyone have additional or contrary conclusions?

[fabien]

Hello yellowfinch, welcome to the forums!
You have asked yourself the right questions that every admin of their own system should ask themselves.

• mailutils is not installed by default, so the script will detect that the sendmail command is not available and simply “echo” that it wasn’t found.

sendmail is provided by the providers of the mail-transport-agent virtual package (exim4-daemon-light or postfix for example), and not by the mailutils package.

I’ll know about it only if I manually type the mail command in terminal.

I used to configure Thunderbird to check system emails, but due to a poor decision, this is no longer an option. Thanks to your topic, I see that they have now backpedaled on their decision. For now, I use Balsa for this, and an applet notifies me if there are new system emails. This is how I do it, it's up to you to choose the way that suits you, /bin/mail can be one of them. It's also possible to configure your MTA to send emails to an external email service. Each part does its job and only its job and does it well.

[yellowfinch]

@fabien: Thanks for highlighting the difference between mail and sendmail.

However, I was rather hoping that my post would elicit a discussion of the fundamental issue, i.e. having an integrity verification system that, by default, tells nobody when it finds errors.

Should I understand that you don’t agree it’s a flaw?

The change in question has made its way to all Debian derivatives (I discovered it in Linux Mint, which derives from Ubuntu) so it concerns millions of installations.

[CwF]

Should I understand that you don’t agree it’s a flaw?

only if you take not configured as a flaw.