Re: updatedb.mlocate
On Sun, Apr 10, 2022 at 06:03:13AM -0400, gene heskett wrote:
> 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...
The mlocate package includes a /lib/systemd/system/mlocate.timer file.
It's static content. If the package maintainer wanted to randomize the
contents, they would need to write code in the mlocate.postinst script
to change the static file -- which is a really BAD idea. A slightly
better idea: don't include the static file at all, but include code in
the mlocate.postinst which generates a randomized mlocate.timer file.
The mlocate.postinst script is not a bash script. It's an sh script.
So, the "obvious" way to do it in bash (a here document with $((RANDOM%...))
expressions in it) won't work. They would need to call out to some
external process (perhaps awk) to generate some random numbers, store
those in variables, and then use the variables in the here document.
They would also need to arrange for the randomized mlocate.timer file
to be cleaned up when the package is removed, so that's even more code
to write.
Kind of a pain in the ass.
Even if randomizing the times is more trouble than it's worth, I wonder
how much support might exist for simply specifying a different static time
for each package that currently runs at midnight. E.g. have mlocate
run at 00:05, have man-db run at 00:10, have logrotate run at 00:15,
and so on. I don't know how many different timers all run at midnight --
just the ones that *I* happen to have. There are probably lots more.
Reply to: