On Sun 10 Apr 2022 at 10:04:53 (-0400), 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".
To be fair, man systemd.time is extremely comprehensive, with abundant examples (* is expressly defined). So I'm not surprised that it's hived off into a separate man page to avoid repeating it elsewhere. > > 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. I don't think it's in the nature of systemd to be proscriptive. One of its advantages is its extreme, almost overwhelming, flexibility. > 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. I'm guessing two possibilities might be worth trying: systemctl disable mlocate.service before you fiddle with its configuration, then enable it afterwards. touch /var/lib/systemd/timers/stamp-mlocate.timer with a time in the future, so that systemd thinks it has already been run. I don't think they're mutually exclusive. Cheers, David.
