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