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).
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 öö
Attachment:
pgp5l3XtShW16.pgp
Description: PGP signature