[PATCH 1/1] fstrim: add random delay to systemd timer

[PATCH 1/1] fstrim: add random delay to systemd timer

[Christian Hesse]

The fstrim timer tends to fire simultaneously with other timers like
updatedb. As fstrim is not time criticaly let's add a random delay of
up to an hour.

Signed-off-by: Christian Hesse <mail@eworm.de>
---
 sys-utils/fstrim.timer | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sys-utils/fstrim.timer b/sys-utils/fstrim.timer
index 3a3762d5c..dd3328e2a 100644
--- a/sys-utils/fstrim.timer
+++ b/sys-utils/fstrim.timer
@@ -5,6 +5,7 @@ Documentation=man:fstrim
 [Timer]
 OnCalendar=weekly
 AccuracySec=1h
+RandomizedDelaySec=1h
 Persistent=true
 
 [Install]

Re: [PATCH 1/1] fstrim: add random delay to systemd timer

[Ruediger Meier]

On Monday 17 December 2018, Christian Hesse wrote:
> The fstrim timer tends to fire simultaneously with other timers like
> updatedb. As fstrim is not time criticaly let's add a random delay of
> up to an hour.
>
> Signed-off-by: Christian Hesse <mail@eworm.de>
> ---
>  sys-utils/fstrim.timer | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/sys-utils/fstrim.timer b/sys-utils/fstrim.timer
> index 3a3762d5c..dd3328e2a 100644
> --- a/sys-utils/fstrim.timer
> +++ b/sys-utils/fstrim.timer
> @@ -5,6 +5,7 @@ Documentation=man:fstrim
>  [Timer]
>  OnCalendar=weekly
>  AccuracySec=1h
> +RandomizedDelaySec=1h

Looks like it could still run simultaneously with other timers at random 
times. So this does not seem to be a real fix for the problem described 
in your commit message.

You may look at /etc/cron.{hourly,daily,weekly,monthly} if you want to 
run such jobs one after the other.

cu,
Rudi

Re: [PATCH 1/1] fstrim: add random delay to systemd timer

[Christian Hesse]

[-- Attachment #1: Type: text/plain, Size: 1476 bytes --]

Ruediger Meier <sweet_f_a@gmx.de> on Mon, 2018/12/17 21:45:
> On Monday 17 December 2018, Christian Hesse wrote:
> > The fstrim timer tends to fire simultaneously with other timers like
> > updatedb. As fstrim is not time criticaly let's add a random delay of
> > up to an hour.
> >
> > Signed-off-by: Christian Hesse <mail@eworm.de>
> > ---
> >  sys-utils/fstrim.timer | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/sys-utils/fstrim.timer b/sys-utils/fstrim.timer
> > index 3a3762d5c..dd3328e2a 100644
> > --- a/sys-utils/fstrim.timer
> > +++ b/sys-utils/fstrim.timer
> > @@ -5,6 +5,7 @@ Documentation=man:fstrim
> >  [Timer]
> >  OnCalendar=weekly
> >  AccuracySec=1h
> > +RandomizedDelaySec=1h  
> 
> Looks like it could still run simultaneously with other timers at random 
> times. So this does not seem to be a real fix for the problem described 
> in your commit message.
> 
> You may look at /etc/cron.{hourly,daily,weekly,monthly} if you want to 
> run such jobs one after the other.

There's no harm when jobs run simultaneously, other than bad user experience:
Consider a user stating his notebook, workstation, whatever on a Monday
morning and system feels bad under high load. This can be avoided (most of
the time) with just a single line in the timer. I think it is worth it.

Anyway... Feel free to deny committing the patch. For now I added a
configuration snipped on my system.
-- 
Schoene Gruesse
Chris

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 1/1] fstrim: add random delay to systemd timer

[Ruediger Meier]

On Monday 17 December 2018, Christian Hesse wrote:
> Ruediger Meier <sweet_f_a@gmx.de> on Mon, 2018/12/17 21:45:
> > On Monday 17 December 2018, Christian Hesse wrote:
> > > The fstrim timer tends to fire simultaneously with other timers
> > > like updatedb. As fstrim is not time criticaly let's add a random
> > > delay of up to an hour.
> > >
> > > Signed-off-by: Christian Hesse <mail@eworm.de>
> > > ---
> > >  sys-utils/fstrim.timer | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/sys-utils/fstrim.timer b/sys-utils/fstrim.timer
> > > index 3a3762d5c..dd3328e2a 100644
> > > --- a/sys-utils/fstrim.timer
> > > +++ b/sys-utils/fstrim.timer
> > > @@ -5,6 +5,7 @@ Documentation=man:fstrim
> > >  [Timer]
> > >  OnCalendar=weekly
> > >  AccuracySec=1h
> > > +RandomizedDelaySec=1h
> >
> > Looks like it could still run simultaneously with other timers at
> > random times. So this does not seem to be a real fix for the
> > problem described in your commit message.
> >
> > You may look at /etc/cron.{hourly,daily,weekly,monthly} if you want
> > to run such jobs one after the other.
>
> There's no harm when jobs run simultaneously, other than bad user
> experience: Consider a user stating his notebook, workstation,
> whatever on a Monday morning and system feels bad under high load.
> This can be avoided (most of the time) with just a single line in the
> timer. I think it is worth it.

Hm, on my file server updatedb needs about 30 minutes. A random delay of 
1 hour means that both jobs will still run simultaneously in 50% of the 
cases.

> Anyway... Feel free to deny committing the patch. For now I added a
> configuration snipped on my system.

Nevermind, I just wanted to rant again about why we are maintaining this 
timer files at all. IMO the distros and/or admins should configure such 
tasks *properly* according their needs. UL upstream is IMHO the wrong 
place.

BTW note that RandomizedDelaySec will produce an annoying warning on 
sytstems where systemd is not up-to date. And to rant again, IMO it's 
questionable whether we should bother users with such warnings or why 
one should update the whole systemd monstrum just to achieve such 
simple improvement which was solved already by cron 30 years ago in a 
better way ;)

cu,
Rudi

Re: [PATCH 1/1] fstrim: add random delay to systemd timer

[Karel Zak]

On Mon, Dec 17, 2018 at 11:13:35PM +0100, Ruediger Meier wrote:
> Nevermind, I just wanted to rant again about why we are maintaining this 
> timer files at all. IMO the distros and/or admins should configure such 
> tasks *properly* according their needs. UL upstream is IMHO the wrong 
> place.

Well, distro still can improve upstream configuration, the files is
just the default hint. It's better to share this code than force all
distro duplicate effort. Perfect is enemy of good :-) The files are
installed (by make install), but not enabled by default -- the
activation is distro/user decision.

And according to feedback it seems people use the fstrim.timer, so why
not share it and work together on better fstrim and timer
configuration?

> BTW note that RandomizedDelaySec will produce an annoying warning on 
> sytstems where systemd is not up-to date. And to rant again, IMO it's 
> questionable whether we should bother users with such warnings or why 
> one should update the whole systemd monstrum just to achieve such 
> simple improvement which was solved already by cron 30 years ago in a 
> better way ;)

Well, I'm not systemd expert, but I guess you can define dependences
between services to avoid unwanted collisions between services.

    Karel


-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com