On Sun, 5 Jan 2020 15:41:57 -0500 "Theodore Y. Ts'o" <ty...@mit.edu> wrote:
> On Sat, Jan 04, 2020 at 07:57:16PM -0800, Josh Triplett wrote:
> > Package: e2fsprogs
> > Version: 1.45.4-1
> > Severity: important
> >
> > The e2fsprogs package installs a service and timer to run e2scrub. That
> > service sleeps for 2 seconds before exiting, delaying the boot by 2
> > seconds.
>
> It's not necessarily 2 seconds, and it's not directly sleeping.
$ grep sleep /sbin/e2scrub*
/sbin/e2scrub: # We have to sleep 2 seconds here because journald uses the pid
to
/sbin/e2scrub: sleep 2
/sbin/e2scrub: sleep 0.5
/sbin/e2scrub: sleep 0.5
/sbin/e2scrub_all: # We have to sleep 2 seconds here because journald uses
the pid to
/sbin/e2scrub_all: sleep 2
$ systemd-analyze blame | grep e2scrub
2.012s e2scrub_all.service
> It's
> however long it takes to spin up any storage devices, caused by
> running lvs. The bulk of the time of running "e2scrub_all -A -r" is
> the time to run 'lsblk' and 'lvs'.
That's an *additional* delay, on top of the sleeps above. The two-second
sleep in the "exitcode" function seems like the primary culprit. Note
that I don't even have lvm2-tools installed.
> > Second, please use ConditionPathExists or similar to check for the tools
> > e2scrub needs (lsblk and lvcreate), rather than running a script that
> > checks for them and then exits.
>
> That's not the cause of most of the time needed to run e2scrub_all.
> We also need to run these sanity checks when e2scrub_all is run by
> hand, or run out of cron.
It is when I'm trying to boot a system in ~100ms. I want to avoid
launching the service and its shell script *at all*.
> > And third, please consider *not* enabling this by default.
>
> It wasn't enabled by default.
I just installed a fresh system, and it definitely *is* enabled by
default, both via a systemd timer and via cron. I noticed that while
debugging the boot process on that fresh system, which also led me to
find it enabled on my laptop, where it similarly delays the boot process
by two seconds.
It's possible that we're talking past each other here. There's an
enabled systemd timer unit and an enabled cron job that run a shell
script. That shell script then sources its configuration file, just to
find out that it isn't actually configured, and then sleeps before
exiting. That's still enabled. (And even if it didn't have the sleep in
it, it's still enabled.)
This is the equivalent of an /etc/default/foo file with an ENABLED=0
flag or similar, which has similar problems and shouldn't ever happen
either. The right way to have a disabled-by-default service is to
disable it, and tell people how to enable it. One way to do that would
be to disable the service/timer and tell people how to enable it via
systemctl or similar; another way would be to remove the sample
/etc/e2scrub.conf and then use ConditionPathExists=/etc/e2scrub.conf .
Personally, I would suggest the latter.
(Along the same lines, e2scrub_fail should have a ConditionPathExists on
sendmail, because it can't do anything useful if sendmail doesn't
exist.)
- Josh Triplett
