Re: updatedb.mlocate
On Sunday, 10 April 2022 05:33:53 EDT Linux-Fan wrote:
> Greg Wooledge writes:
> > On Sat, Apr 09, 2022 at 09:26:58PM -0600, Charles Curley wrote:
> > > Two of my machines have their database files dated at midnight or
> > > one
> > > minute after.
> > >
> > > Possibly because updatedb is run by a systemd timer, not cron.
>
> [...]
>
> > # skip in favour of systemd timer
> > if [ -d /run/systemd/system ]; then
> >
> > exit 0
> >
> > fi
> > [...]
> >
> > Wow. That's incredibly annoying!
>
> It provides a mechanism that adjusts to the init system at runtime.
> Maybe there are better ways to do it, but it seems to work OK?
>
> > 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?
>
> Try
>
> # 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.
>
> 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.
>
> > Oh well. It clearly isn't bothering me (I'm usually in bed before
> > midnight, though not always), so I never had to look into it. I'm
> > sure someone felt it was a "good idea" to move things from perfectly
> > normal and well-understood crontab files into this new systemd timer
> > crap that nobody understands, and that I should respect their
> > wisdom, but I don't see the advantages at this time.
>
> I think systemd tries to provide an alternative for all the `...tab`
> files that used to be the standard (/etc/inittab, /etc/crontab,
> /etc/fstab come to mind). IMHO the notable advantage over the
> traditional method is that on systemd-systems one can query all the
> status information with a single command: `systemctl status
> <name-of-unit>`. Similarly, the lifecycle of start/stop/enable/disable
> can all be handled by the single command `systemctl
> start/stop/enable/disable <name-of-unit>`. All stdout/stderr outputs
> available via `journalctl -u <name-of-unit>`. In theory this could
> eliminate the need to know about or remember the individual services'
> log file names.
>
> 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).
Thats fine, as long as the systemd stuff is disabled by finding an entry
in the presently logged in users ~/.config, but I do not consider that as
a user item. thats (updatedb) sysadmin stuff, and much of this hoohah
could be prevented by setting the trigger time at install time with a
random time between 1 and 4 AM when most users are inactive anyway. How
many lines of bash code would it take to do that, 3? 4? IDK but it could
be done...
> IMHO systemd's interface is not the best design-wise and in terms of
> its strange defaults, formats and names (paged output by default is
> one of the things I disable all the time, INI-derivatives are really
> not my favorite configuration syntax, binary logfiles, semantics of
> disable/mask can be confusing...). IMHO it does provide a lot of
> useful features that were missing previously, though.
>
> YMMV
> Linux-Fan
>
> öö
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: