Here are some regression scenarios: Someone has taken control of all scheduled tasks on a load-critical server by either disabling cron, adjusting the cron.weekly job, or adjusting this particular weekly job in cron. Switching to a systemd timer and enabling it by default would disrupt such a user.
Someone doesn't want the outbound traffic (eg. on privacy grounds) and has disabled the job via cron. Again, this might have happened at various points in cron's configuration. > 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? I would want to refer to other SRU team members before making a decision. If somebody is opposed to the random delay method, a systemd timer can still work, but in that case breaking the above use cases should be deliberate and documented. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1836475 Title: [SRU] update-notifier-common weekly cron job runs at the same time for all computers across the globe To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/1836475/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
