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
