Score:0

What will make unattended-upgrades run reliably on a laptop?

cn flag

I have been struggling with in various forms, year after year. See here and here. Either I am configuring something wrong (unlikely), or I am using my computer in a bizarre way (I don't see it).

My computer is a laptop:

  1. Before, I turned it off at night - as a result the unattended-upgrade could often not connect to the internet when it wanted to. Result: my computer was left un-upgraded and insecure for months on end.
  2. These days I mostly stay logged in, but the hotspot connection is unavailable at night. So now, the unattended-upgrade runs but finds nothing to update, apparently because apt update has not been able to run successfully. Result: my computer is left un-upgraded and insecure for months on end.

How can I ensure the systemd timer for apt update does not go weeks and months between runs?

Typical output of /var/log/unattended-upgrades/unattended-upgrades.log

2022-02-09 06:30:27,331 INFO Starting unattended upgrades script
2022-02-09 06:30:27,334 INFO Allowed origins are: o=Ubuntu,a=focal, o=Ubuntu,a=focal-security, o=UbuntuESMApps,a=focal-apps-security, o=UbuntuESM,a=focal-infra-security, o=UbuntuESM,a=focal-security
2022-02-09 06:30:27,335 INFO Initial blacklist: 
2022-02-09 06:30:27,336 INFO Initial whitelist (not strict): 
2022-02-09 06:30:40,279 INFO No packages found that can be upgraded unattended and no pending auto-removals

sudo systemctl status apt-daily:

* apt-daily.service - Daily apt download activities
     Loaded: loaded (/lib/systemd/system/apt-daily.service; static; vendor preset: enabled)
     Active: inactive (dead)
TriggeredBy: * apt-daily.timer
  Condition: start condition failed at Wed 2022-02-09 20:42:17 EET; 4h 17min ago
             └─ ConditionACPower=true was not met
       Docs: man:apt(8)

Feb 09 20:42:17 tbox systemd[1]: Condition check resulted in Daily apt download activities being skippe>
lines 1-9/9 (END)

sudo systemctl list-timers apt-daily:

NEXT                        LEFT     LAST                        PASSED       UNIT            ACTIVATES>
Thu 2022-02-10 16:15:14 EET 15h left Wed 2022-02-09 20:42:17 EET 4h 22min ago apt-daily.timer apt-daily>

1 timers listed.
Pass --all to see loaded but inactive timers, too.
lines 1-5/5 (END)

NB: there was a reboot a few hours ago. Not plugged in but was connected to network.

FINAL CONCLUSION. Going with version of the accepted solution below, shifting the apt-daily.timer to a time when the internet connection is more likely to be available. Thanks for those who helped. The end.

Organic Marble avatar
us flag
Why not just run upgrades manually once a week?
Nmath avatar
ng flag
I'm not sure what the problem is. Your device can't update when it's suspended or otherwise not connected to the internet. Also, unattended-upgrades only updates for security and critical bugs. You still need to perform regular maintenance, so the fact that your system isn't updated for months at a time isn't a fault of unattended-upgrades.
us flag
How can you say that turning off the laptop during the time updates are scheduled to be run or turning off the internet connection is the problem of the OS? Can Canonical know when your internet is active? Modify the systemd timer to align when you know the network connection is up or run the updates manually.
Sqerstet avatar
cn flag
@OrganicMarble Because "just" babysitting a personal computer to get security updates seems suboptimal, or do you disagree?
Organic Marble avatar
us flag
I disagree that taking maybe 30 minutes once a week is "babysitting". At least for my babies.
Sqerstet avatar
cn flag
@Nmath The three questions are related but different: here I am homing in specifically on how to fix the root of the issue which seems to be the `apt update` timer - I believe UU should do this, hence title. If you really do not see that all this is a problem, well, I don't know what to say. Since when did Joe Ubuntu User also need to "perform regular maintenance" on his laptop when security updates are turned on? Am I missing something? I know that UU works great on servers but I think I have established that it does not on an end-user laptop.
Sqerstet avatar
cn flag
@doneal24 Obviously we do not agree about what a consumer OS should do. I believe it should keep a laptop secure. By definition laptops are not always plugged in or connected to the internet. This is an absolutely banal and ordinary scenario, and Ubuntu cannot handle it. BTW there is a bug posted on the Canonical tracker - their line, roughly, is that they are looking into it but meanwhile it's "apt's fault". If you could expand your last tip into an actionable answer, that might be very helpful.
us flag
I would also say that Windows or Mac OS cannot handle intermittent and possibly short internet connections for updates so the problem is not limited to Ubuntu. Consumer OS's do not keep laptops secure unless you can keep them connected to the update servers. I don't have an Ubuntu system handy so I can't say how to modify the systemd timer - easy enough to research. Manual updating weekly is not a major chore.
Sqerstet avatar
cn flag
@doneal24 Well we will continue to disagree. Asking ordinary users to remember to do security updates on a consumer PC is to me a disastrous Windows-98-level security hole. Mac OS can't do this? If you say so. Oddly, my sync client *can* do it. No matter how unauthorized my laptop habits get - plugging in and out, wifi and no wifi, all kinds of craziness! - my photos are always there the next day. It just works. Unattended Upgrades does not.
Sqerstet avatar
cn flag
@Nmath And yet there is in fact a question there. It makes more sense than many others on the site. Do you have an answer?
user535733 avatar
cn flag
Where is the Unattended Upgrades log output? Where is the timestamp output? Where is the systemctl status for apt-daily-upgrade? We can solve a lot of problems, but we are not psychic -- we need data to work with.
Sqerstet avatar
cn flag
@user535733 Added UU typical log output. Where is the apt-daily-upgrade log?
user535733 avatar
cn flag
Your log shows that Unattended Upgrades ran properly at 06:30. It found no security upgrades to download today. That looks like normal behavior. What leads you to believe that something different is going on? Did you review the rest of this month? Did you review last month, too? It only takes a moment. I had a big security upgrade around Jan 21 (libreoffice on 21.10), and fairly quiet before and after. You're running 20.04, so yours might be different...and quieter.
Sqerstet avatar
cn flag
@user535733 Well yes of course I did, hence the talk of "months". It finds nothing - as shown - over and over again, because the sources are not updated. When I run `apt update` manually, it works the next time. The problem is that UU and `apt` are not smart enough to listen for an internet connection event - or perhaps to reschedule at random times and increasingly frequently until they get one. And apparently they don't talk to each other. I don't understand the detail, I'm not that technical. Could you tell me where to find the apt-daily-upgrade log?
user535733 avatar
cn flag
You saw it already: "apt-daily-upgrade" is Unattended Upgrades. Now you're saying that apt-daily (not apt-daily-upgrade, not Unattended Upgrades) is the problem. Okay, show us the complete output of `systemctl status apt-daily` and of `systemctl list-timers apt-daily` Those are wide outputs, so make sure your terminal is wide enough to catch the entire output.
Sqerstet avatar
cn flag
@user535733 Done. Terminal was as wide as possible, does seem to be a squeeze.
user535733 avatar
cn flag
Your output shows that apt-daily tried to run at 20:42, and will try again at 16:15 tomorrow. Nothing wrong there. The reason it didn't connect to the network was that the system was on battery: `ConditionACPower=true was not met`. You can change that setting, if you wish, by commenting out the appropriate line in `/lib/systemd/system/apt-daily.service`
Sqerstet avatar
cn flag
@user535733 OK this is very useful, thanks.
Score:1
jp flag

Checking a stock Ubuntu Server 20.04 install, it looks like unattended-upgrade runs are triggered by apt-daily-upgrade.timer. This triggers daily at 6am with a random delay up to an hour.

root@ubuntu:~# systemctl cat apt-daily-upgrade.timer
# /lib/systemd/system/apt-daily-upgrade.timer
[Unit]
Description=Daily apt upgrade and clean activities
After=apt-daily.timer

[Timer]
OnCalendar=*-*-* 6:00
RandomizedDelaySec=60m
Persistent=true

[Install]
WantedBy=timers.target

A potentially simple solution is to override the OnCalendar setting so the timer triggers at a time more likely to be online. For example

mkdir /etc/systemd/system/apt-daily-upgrade.timer.d
cat <<EOF >/etc/systemd/system/apt-daily-upgrade.timer.d/override.conf
[Timer]
OnCalendar=
OnCalendar=*-*-* 12:00
EOF
systemctl daemon-reload

This will trigger the timer at noon instead. unattended-upgrade should only run once per day by default. That is because of the setting for APT::Periodic::Unattended-Upgrade. Cherry picking a comment from /usr/lib/apt/apt.systemd.daily

#  APT::Periodic::Unattended-Upgrade "0";
#  - Run the "unattended-upgrade" security upgrade script
#    every n-days (0=disabled)

The stock configuration value for this is 1 day.

root@ubuntu:~# apt-config dump APT::Periodic::Unattended-Upgrade
APT::Periodic::Unattended-Upgrade "1";

You can configure the timer to more frequently than once per day by adding apt configuration. The commented link of https://unix.stackexchange.com/a/541426/147262 has several suggestions. Here is a simple example of adding apt configuration

cat <<EOF > /etc/apt/apt.conf.d/90myuu
> APT::Periodic::Unattended-Upgrade "always";
> EOF

If you override the apt-daily-upgrade.timer then you might want to make the same override for apt-daily.timer. This also has a corresponding apt configuration value APT::Periodic::Update-Package-Lists.

EDIT I've changed the suggestion from running hourly to running once per day at a time more likely to be online. I realized that the default setting of running once per day was not affected by whether or not unattended-upgrade actually had any packages to update. Therefore, unattended-upgrade could still continue to only run when not online.

comments

Are there any potential downsides to overclocking the daily timer like that?

The upgrades run overnight by default to avoid interfering with user activity. You will no longer have that convenience.

ConditionACPower=true was not met. You can change that setting

You should change this setting using an override file, not by modifying the package installed service file

mkdir /etc/systemd/system/apt-daily-upgrade.service.d
cat <<EOF > /etc/systemd/system/apt-daily-upgrade.service.d/override.conf
[Unit]
ConditionACPower=false
EOF
systemctl daemon-reload

What would be the reason for, or downsides to, overriding apt-daily.timer too?

apt-daily.timer triggers apt commands to update package information and to download available updates. If these commands continue to run when the network is not available then unattended-upgrade may not update anything because it may not know updates are available.

Sqerstet avatar
cn flag
This is super helpful. Thanks. Are there any potential downsides to overclocking the daily timer like that?
Sqerstet avatar
cn flag
Related: https://unix.stackexchange.com/a/541426/147262
Sqerstet avatar
cn flag
Also necessary to follow advice of @user535733 right?: "The reason it didn't connect to the network was that the system was on battery: ConditionACPower=true was not met. You can change that setting, if you wish, by commenting out the appropriate line in /lib/systemd/system/apt-daily.service"
Sqerstet avatar
cn flag
What would be the reason for, or downsides to, overriding `apt-daily.timer` too?
Andrew Lowther avatar
jp flag
@Sqerstet I've edited to post to modify my suggestion and address your comments.
Sqerstet avatar
cn flag
All becoming much clearer now. Just one last thing I don't get. As, you say, the actual upgrade can run when offlline as long as the sources are already updated. So why not just shift the `apt-daily.timer` to noon, and leave the `apt-daily-upgrade.timer` alone?
Andrew Lowther avatar
jp flag
@Sqerstet I like that idea of just updating `apt-daily.timer`. I had not considered it, but in theory I think that should work for your situation. All of this requires actual testing.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.