Re: updatedb.mlocate
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.
Reply to: