Unattended upgrades should work on roaming laptops

[Robin]

For many if not most laptop computers, Unattended Upgrades seems all but useless by design.

For upgrades to happen, with default config, 3 conditions must be met:

- an internet connection must be up and running when the timer or cron or anacron tries the unattended upgrade
- the connection must not be metered, whatever that means (Skip-Updates-On-Metered-Connections "true")
- the computer must be plugged in (OnlyOnACPower "true")

These are insurmountable problems for many laptops on the go. Inevitably, security upgrades will almost never run unattended on such computers. I discovered with shock that Unattended Upgrades had almost never run on my laptop. I tried all possible config tweaks. Nothing worked reliably and in the end I gave up and wrote a upgrade script which uses Network Manager's connection-up hook. Unattended Upgrades needs to do something like this out of the box. Users should not need to write scripts to ensure security upgrades.

Unattended upgrades is an excellent project for servers. But it really needs to work, out of the box, on laptops too.

[Balint Reczey (rbalint)]

Those options can be overridden to match your preference. I for example enable u-u on metered connections because the plan I use allows enough traffic for that.

[Robin (tezaro)]

@rbalint As I detailed, the problems cannot *all* be resolved by config. The biggest one, the first above, is still there. If you turn on a laptop when (1) an update is overdue and (2) there is not yet an internet connection, then the update will not run even if the connection becomes available 5 minutes later. This is an **absolutely typical** situation when on the go and connecting to new wifi networks.

Perhaps this is anacron's fault, or systemd's or something, I am not sure. What is certain is that, in the real world, in this common situation, unattended upgrades does not upgrade Ubuntu unattended.

I believe that is a significant problem.

[Balint Reczey (rbalint)]

It is actually APT that triggers the u-u runs, so if there is anything that can be fixed around timing that can be done on APT.
I agree that it would be desired to download packages even on roaming laptops.

[Julian Andres Klode (juliank)]

This is not going to happen in apt. It's a question for desktop how to do that, probably disabling the downloading in apt, and using gnome's package kit refresh stuff instead.

[Sebastien Bacher (seb128)]

@Julian, the issue isn't really a desktop one, or we need to fix every desktop out there to do their own integration which doesn't make sense. Also some users do work from a VT and they should also be able to get security updates

[Julian Andres Klode (juliank)]

We'll eventually get a retry support in apt, if updating failed, but there are no plans to react to connection state changes.

The retry will be linear every 10 minutes or so I suppose, but can't be sure, we'll have to see - I'd do exponential, but systemd does not give us an option for that.

Any change is not suitable for backporting to old releases.

Tthis is a tough topic, but our behavior wrt to updating is not different from other major platforms - e.g. Android only installs updates in the same conditions. It just gets the service triggered automatically if it missed it due to conditions, but systemd does not retrigger nor does it know about network state.

FWIW, I believe that all desktops do have their own integration, because they need to for every other distribution, because that's how PackageKit works.

[Robin (tezaro)]

Just an update, for what it's worth.

I solved this problem with a shell script triggered by Network Manager's "up" hook. Because UU does not update the package list, I had to resort to a `apt-get update && apt-get dist-upgrade` with `DEBIAN_FRONTEND=noninteractive` and a whole bunch of options to make sure everything runs reliably in the background. Convoluted and laborious.

But now my Ubuntu is *always* up to date. Before, it regularly went *months* without a security update.

Putting aside whose fault it is, this absolutely IS a problem.

[Julian Andres Klode (juliank)]

@Robin You should be able to just run `systemctl start apt-daily.service apt-daily-upgrade.service` from the hook. This will start those two services - which run update / upgrade - in the same transaction, and hence ordering will work correctly.

The timer will still run again, so it's not _optimal_, but oh well. An optimal solution would just make the timer "catch up" when the conditions apply. We'll be able to simulate that I guess by moving away from ConditionACPower=true to checking battery state ourself, then exiting with a special error code and retrying on that.

systemd at least was fixed to allow retrying oneshot units a while ago, but we've not had the chance to rework the apt integration to do retries.

[Robin (tezaro)]

@Julian Thanks for the explanation and the tip. Auto-retries would be a really beneficial feature but I get that you have a lot on your plate. Thanks for your work.