Comment 13 for bug 1615482

On Fri, Apr 21, 2017 at 06:55:45PM -0000, Julian Andres Klode wrote:
> While we're at it, we could also push the times 2 hours more outside, to
> 4 and 20. So, something like this would probably be an improvement:

> [Unit]
> Description=Daily apt activities
> After=network.target
>
> [Timer]
> OnCalendar=*-*-* 4,20:00
> RandomizedDelaySec=30m
> AccuracySec=5m
> Persistent=true

I don't see why this is an "improvement". The designed experience for this
on Ubuntu is for these jobs to run between 6am and 7am local time, with a
single run per day and a random delay within the 1-hour window.

On Fri, Apr 21, 2017 at 06:48:59PM -0000, Julian Andres Klode wrote:

> We can of course add After=network.target but this gives no real guarantee
> that internet is available. For waiting with catch up runs during boot,
> that's tracked in systemd's bug tracker at
> https://github.com/systemd/systemd/issues/5659.

As discussed on IRC, this should be After=network-online.target /
Wants=network-online.target. If we're not online, there's no point in doing
an apt update AFAICS. (Ok, in an extreme case you might have a
sneakernet-connected apt repository which you rotate by hand... but I'm not
sure anyone who uses apt that way cares about the daily timer.)

> The boot argument with short runtime should be ignored. We can't help
> everyone. People are already complaining that the job runs during boot
> and want us to delay it during boot.

I think that should clearly be regarded as 'wontfix'. The default
experience should ensure that security updates are applied in a timely
manner to every instance of Ubuntu, regardless of its power on/off cycle.