[arch-general] Many timers now running at boot. How to make them run later?
After not booting an Arch box for several days, the first few minutes seem quite MS like lately with a flurry of processes running to the point after I enter my username at the console, it may be 10-20 sec before the password prompt is displayed. Since it's all timers now and not cron running things quietly at 4:00 am, this loads sever processes right at boot that cause the problem. For example, boot just now was crawling and checking systemctl timers shows: (leading columns snipped) LAST PASSED UNIT ACTIVATES n/a n/a systemd-tmpfiles-clean.timer systemd-t> Thu 2019-11-21 03:33:43 CST 11min ago logrotate.timer logrotate> Thu 2019-11-21 03:33:43 CST 11min ago man-db.timer man-db.se> Thu 2019-11-21 03:33:43 CST 11min ago shadow.timer shadow.se> 4 timers listed. Pass --all to see loaded but inactive timers, too. This impacts being able to get thins from a computer in a hurry and reminds me of the unpleasant waits waiting for windows to run all of its on-boot checks. What is the best way to modify this scheme to prevent, e.g. logrotate.time, man-db.timer and shadow.timer all trying to run on boot? I'd rather set them up to run a 5:00 localtime as I would with cronnie. But I do want to use the systemd timer, so what is the best way to configure the systemd timer to schedule these things to run at a convenient time instead of all firing on boot? -- David C. Rankin, J.D.,P.E.
Hi David,
What is the best way to modify this scheme to prevent, e.g. logrotate.time, man-db.timer and shadow.timer all trying to run on boot? I'd rather set them up to run a 5:00 localtime as I would with cronnie. But I do want to use the systemd timer, so what is the best way to configure the systemd timer to schedule these things to run at a convenient time instead of all firing on boot?
Whilst you await a better answer, ‘RandomizedDelaySec=’ in systemd.timer(5) may be of interest. -- Cheers, Ralph.
"David C. Rankin" <drankinatty@suddenlinkmail.com> on Thu, 2019/11/21 04:08:
[...]
What is the best way to modify this scheme to prevent, e.g. logrotate.time, man-db.timer and shadow.timer all trying to run on boot? I'd rather set them up to run a 5:00 localtime as I would with cronnie. But I do want to use the systemd timer, so what is the best way to configure the systemd timer to schedule these things to run at a convenient time instead of all firing on boot?
I've created systemd configuration overlay snippets for this, for example /etc/systemd/system/man-db.timer.d/RandomizedDelaySec.conf: [Timer] RandomizedDelaySec=30min Create a file for every timer you want to delay. -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}
On 11/21/2019 05:53 AM, Christian Hesse wrote:
I've created systemd configuration overlay snippets for this, for example /etc/systemd/system/man-db.timer.d/RandomizedDelaySec.conf:
[Timer] RandomizedDelaySec=30min
Create a file for every timer you want to delay.
Thank you Ralph & Christian, I'll do that. Something to just keep them all from firing when I boot would be nice. I wonder why systemd doesn't do this by default? As more an more things have been turned over to systemd timer, it should have become evident that they were all going to start stacking up on boot.... Bad Juju... Logrotate and man-db can be run at 4:00 am and be fine. If I update a slew of man-pages, I'll call it directly. I see what I can do with RandomizedDelaySec=. Thanks again. -- David C. Rankin, J.D.,P.E.
On Thu, 21 Nov 2019 at 18:13, David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
On 11/21/2019 05:53 AM, Christian Hesse wrote:
I've created systemd configuration overlay snippets for this, for example /etc/systemd/system/man-db.timer.d/RandomizedDelaySec.conf:
[Timer] RandomizedDelaySec=30min
Create a file for every timer you want to delay.
Thank you Ralph & Christian,
I'll do that. Something to just keep them all from firing when I boot would be nice.
Can't you make these services depend on another one which you write to start a certain number of minutes after boot? Regards, NTS
On Thu, 21 Nov 2019 at 21:02, NTS <nts@gyatso.de> wrote:
On Thu, 21 Nov 2019 at 18:13, David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
On 11/21/2019 05:53 AM, Christian Hesse wrote:
I've created systemd configuration overlay snippets for this, for
example
/etc/systemd/system/man-db.timer.d/RandomizedDelaySec.conf:
[Timer] RandomizedDelaySec=30min
Create a file for every timer you want to delay.
Thank you Ralph & Christian,
I'll do that. Something to just keep them all from firing when I boot would be nice.
Can't you make these services depend on another one which you write to start a certain number of minutes after boot?
Regards, NTS
You could, but if you're going to modify the services anyway, then a randomized delay seems betters. That way, they are not only delayed, they are also spread out. -- Maarten
On Thu, 21 Nov 2019 21:36:36 +0100 Maarten de Vries via arch-general <arch-general@archlinux.org> wrote: <snip>
Can't you make these services depend on another one which you write to start a certain number of minutes after boot?
You could, but if you're going to modify the services anyway, then a randomized delay seems betters. That way, they are not only delayed, they are also spread out.
Yes, with a high probability. They might still run simultaneously sometimes, though. Cheers.
-- Maarten
-- Merlin Büge
"David C. Rankin" <drankinatty@suddenlinkmail.com> on Thu, 2019/11/21 12:13:
I wonder why systemd doesn't do this by default?
It's not systemd to blame. The timer unit files are shipped by the respective projects, like util-linux, man-db, mlocate, shadow, logrotate, ... -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}
On 11/21/2019 01:01 PM, Christian Hesse wrote:
"David C. Rankin" <drankinatty@suddenlinkmail.com> on Thu, 2019/11/21 12:13:
I wonder why systemd doesn't do this by default?
It's not systemd to blame. The timer unit files are shipped by the respective projects, like util-linux, man-db, mlocate, shadow, logrotate, ...
That makes perfect sense... I'll have to look back at what the scheme was when things would just get dropped in /etc/cron.daily {.hourly, .monthly, .weekly}, etc.. It really has been until the last 9-12 months or so that I've notice the delays growing at boot. It would really be nice if there was a setting in /etc/systemd/system.conf (or one of the other .conf file) that would simply let you set the hour of the day for the default timers of this type to run. That way you could just set something like 0400 and solve the problem for not only current timers, but all future ones as well. I'll drop a note if I find anything else that may be helpful as I paw my way though the documentation. -- David C. Rankin, J.D.,P.E.
Hi Chris,
David C. Rankin wrote:
I wonder why systemd doesn't do this by default?
It's not systemd to blame. The timer unit files are shipped by the respective projects, like util-linux, man-db, mlocate, shadow, logrotate, ...
systemd.timer(5) says AccuracySec= ... Within this time window, the expiry time will be placed at a host-specific, randomized, but stable position that is synchronized between all local timer units. This is done in order to optimize power consumption to suppress unnecessary CPU wake-ups. So I think it is systemd's `fault' that they all collide. I think its theory is flawed. The CPU here will happily move from doing nothing to doing slightly less for a unit and back again without getting hot and altering the fan speed. But ig the typical timer units collide then the fan speed moves up through the gears and keeps going at more than idle speed for some time, long after the units have finished and the CPU clocked back down. That must impact power consumption too. -- Cheers, Ralph.
participants (6)
-
Christian Hesse
-
David C. Rankin
-
Maarten de Vries
-
Merlin Büge
-
NTS
-
Ralph Corderoy