fstrim: add random delay to systemd timer
PATCH 1/1 fstrim: add random delay to systemd timer
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.
--- sys-utils/fstrim.timer | 1 + 1 file changed, 1 insertion(+)
sys-utils/fstrim.timer +1 -0
@@ -5,6 +5,7 @@ Documentation=man:fstrim [Timer] OnCalendar=weekly AccuracySec=1h +RandomizedDelaySec=1h Persistent=true [Install]
Quoted 14 lines · 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 <[email protected]>--- sys-utils/fstrim.timer | 1 + 1 file changed, 1 insertion(+)sys-utils/fstrim.timer +0
-0
sys-utils/fstrim.timer Documentation=man:fstrim · line 8
Quoted 4 lines
sys-utils/fstrim.timer +1
-0@@ -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
Ruediger Meier <[email protected]> on Mon, 2018/12/17 21:45:
Quoted 24 lines · Christian Hesse
Quoted 14 lines
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 <[email protected]>--- sys-utils/fstrim.timer | 1 + 1 file changed, 1 insertion(+)sys-utils/fstrim.timer +0
-0sys-utils/fstrim.timer Documentation=man:fstrim · line 8
Quoted 4 lines
sys-utils/fstrim.timer +1
-0@@ -5,6 +5,7 @@ Documentation=man:fstrim [Timer] OnCalendar=weekly AccuracySec=1h +RandomizedDelaySec=1hLooks 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.
Quoted 2 lines
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.
Signature · 2 lines
Schoene Gruesse Chris
Quoted 25 lines · Christian Hesse
Ruediger Meier <[email protected]> on Mon, 2018/12/17 21:45:
Quoted 24 lines · Christian Hesse
Quoted 14 lines
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 <[email protected]>--- sys-utils/fstrim.timer | 1 + 1 file changed, 1 insertion(+)sys-utils/fstrim.timer +0
-0sys-utils/fstrim.timer Documentation=man:fstrim · line 8
Quoted 4 lines
sys-utils/fstrim.timer +1
-0@@ -5,6 +5,7 @@ Documentation=man:fstrim [Timer] OnCalendar=weekly AccuracySec=1h +RandomizedDelaySec=1hLooks 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.
Quoted 8 lines
Quoted 2 lines
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.
Quoted 2 lines
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
Karel Zak
maintainerQuoted 4 lines · Ruediger Meier
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?
Quoted 6 lines
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
Signature · 2 lines
Karel Zak <[email protected]> http://karelzak.blogspot.com