On Mon, Jun 14, 2021 at 04:16:28PM -0000, Robie Basak wrote:
> > I'm keen to try and avoid handling any more complex (arbitrary)
> customisations
>
> I agree! I think I prefer adding a random sleep for the SRU for this
> reason, even if the appropriate fix for the development release that
> landed in Groovy was to switch to a systemd timer. However a long random
> sleep in cron.weekly will hold up other cron.weekly jobs, so given that
> /usr/lib/ubuntu-release-upgrader/release-upgrade-motd already gates with
> a timestamp, perhaps backgrounding a shorter random delay would be
> preferable if that would be acceptable to Canonical IS?
>
We could try with a shorter random delay and see if it helps spread
the load.
The 'update-notifier-common' cron.weekly job is usually last so
wouldn't really hold up that many other cron.weekly jobs. If a shoter
random delay/sleep doesn't help, we could consider renaming it to
something like 'zzupdate-notifier-common' and increasing the delay
then.
On Mon, Jun 14, 2021 at 04:16:28PM -0000, Robie Basak wrote: ubuntu- release- upgrader/ release- upgrade- motd already gates with
> > I'm keen to try and avoid handling any more complex (arbitrary)
> customisations
>
> I agree! I think I prefer adding a random sleep for the SRU for this
> reason, even if the appropriate fix for the development release that
> landed in Groovy was to switch to a systemd timer. However a long random
> sleep in cron.weekly will hold up other cron.weekly jobs, so given that
> /usr/lib/
> a timestamp, perhaps backgrounding a shorter random delay would be
> preferable if that would be acceptable to Canonical IS?
>
We could try with a shorter random delay and see if it helps spread
the load.
The 'update- notifier- common' cron.weekly job is usually last so notifier- common' and increasing the delay
wouldn't really hold up that many other cron.weekly jobs. If a shoter
random delay/sleep doesn't help, we could consider renaming it to
something like 'zzupdate-
then.