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