On Sunday, 10 April 2022 10:04:53 EDT Greg Wooledge wrote: > On Sun, Apr 10, 2022 at 11:33:53AM +0200, Linux-Fan wrote: > > Greg Wooledge writes: > > > unicorn:~$ less /lib/systemd/system/mlocate.timer > > > [Unit] > > > Description=Updates mlocate database every day > > > > > > [Timer] > > > OnCalendar=daily > > > AccuracySec=24h > > > Persistent=true > > > > > > [Install] > > > WantedBy=timers.target > > > > > > ... it doesn't even say when it runs? What silliness is this? > > I was mistaken: it *does* say when it runs, but only if you've read at > least two different man pages. > > systemd.timer(5) says that OnCalendar= specifies a "calendar event > expression", and refers to systemd.time(7) to explain what that means. > > systemd.time(7) says that a "calendar event" defines one or more points > in time, and then gives some examples. By reading these examples, one > may infer that this thing specifies when the timer will trigger. > > It also explains that the keyword "daily" doesn't just mean "once a > day". It actually says: > > daily → *-*-* 00:00:00 > > In other words, "daily" explicitly means "once a day at local > midnight", assuming you can infer that "*-*-*" means "once a day". > > So, apparently it's the Debian developers who decided to make a bunch > of jobs all run at the same time (local midnight), either by making a > bad choice, or by being lazy. > > > # systemctl list-timers > > NEXT LEFT LAST > > PASSED UNIT ACTIVATES Mon 2022-04-11 > > 00:00:00 CEST 12h left Sun 2022-04-10 00:00:01 CEST 11h ago > > mlocate.timer mlocate.service > > > > It shows that at least on my system, it is going to run on 00:00 > > local time. > Yeah, but... it doesn't say *why* or how to change it. See above. > > > I can imagine that the idea behind not specifying the actual time in > > the individual unit allows you to configure the actual time of > > invocation somehwere else. This way if you have a lot of machines > > all online you can avoid having bursts of activity in the entire > > network/datacenter just as the clock turns to 00:00. > > Indeed, the Debian developers have passed that burden on to the local > system administrator. Worse, they didn't give any guidance or even a > cargo-cultable example for how to override it. Users are expected to > figure it out themselves. > > > Specifically in the case of `cron`, I think it is an improvement that > > user- specific timers are now kept in the user's home directory > > (~/.config/systemd/user directory) rather than a system directory > > (/var/spool/cron/crontabs). > > I am extremely skeptical of how useful it is to specify a systemd timer > at the --user level. They'll only run when the systemd --user service > manager is running, which is only when the user is logged in. > > What kind of jobs would you schedule in a timer, that you would want > to run *only* when you are logged in? I can't really think of any. > Most scheduled jobs would be things I would want to trigger regardless > of whether I'm logged in (cleaning up logs and temp files, retrieving > email from a remote mail server). I guess *some* things could be > deferred until login, like randomizing an email .signature file, but > those would be the exceptions. > > Now, let's see if I can figure out how to override the time at which > mlocate runs its update. I'll apply some previous systemd knowledge > that I happen to possess already, which is that in order to override > the getty@.service configuration, one must create a directory named > /etc/systemd/system/getty@.service.d and put *.conf files in it. > > So, extrapolating from that, let's try creating... > > unicorn:~$ sudo mkdir -p /etc/systemd/system/mlocate.timer.d > [sudo] password for greg: > unicorn:~$ sudo vi /etc/systemd/system/mlocate.timer.d/time.conf > unicorn:~$ cat /etc/systemd/system/mlocate.timer.d/time.conf > [Timer] > OnCalendar= > OnCalendar=04:20 > > I created a three-line override file which clears out the previous > OnCalendar= event(s), and then sets up a new event that runs the thing > at 04:20 each day, instead of midnight each day. > > unicorn:~$ sudo systemctl daemon-reload > unicorn:~$ systemctl list-timers | grep mlocate > Mon 2022-04-11 04:20:00 EDT 18h left Sun 2022-04-10 09:58:20 EDT 16s > ago mlocate.timer mlocate.service > > Slight oops -- after I updated the daemon, the new time for the timer > had already expired, so it ran immediately. That's definitely not how > cron works (changing the time on a cron job doesn't cause an immediate > job execution). I wonder how one would go about changing the time on > a systemd timer *without* triggering an immediate execution in the > middle of the work day. > > . anacron?
Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
