apt-daily.service running too early in boot process

Bug #1667769 reported by mapatma
40
This bug affects 8 people
Affects Status Importance Assigned to Milestone
apt (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

System: ubuntu mate 16.04 with apt version 1.2.19

Problem:

On a desktop system I noticed that the package lists were being updated very infrequently. This is apparently because on most days the apt-daily.service is triggered early in the boot process when the network is not up. Since the timer is set to run approximately every 12 hours, and the system is only on for a few days, the timer tends to lapse over night and is then triggered as soon as the system is booted the following day.

Also, `apt-get update` returns true regardless of whether there is a network connection, so the apt.systemd.daily script reports success and updates the timestamp file regardless. This means that if the system is only used for a few hours per day the package list may not be updated for many days until the timer lapses while the system happens to be already switched on.

System journal showing typical output during boot process:

Feb 10 14:38:13 desktop systemd[1]: Starting Daily apt activities...
Feb 10 14:38:13 desktop apt.systemd.daily[3679]: verbose level 3
...
[truncated]
...
Feb 10 14:38:14 desktop apt.systemd.daily[3679]: + apt-get -y update
Feb 10 14:38:14 desktop apt.systemd.daily[3679]: Err:1 http://security.ubuntu.com/ubuntu xenial-security InRelease
Feb 10 14:38:14 desktop apt.systemd.daily[3679]: Temporary failure resolving 'security.ubuntu.com'
Feb 10 14:38:14 desktop apt.systemd.daily[3679]: Err:2 http://ppa.launchpad.net/ubuntu-mate-dev/welcome/ubuntu xenial InRelease
Feb 10 14:38:14 desktop apt.systemd.daily[3679]: Temporary failure resolving 'ppa.launchpad.net'
Feb 10 14:38:14 desktop apt.systemd.daily[3679]: Err:3 http://gb.archive.ubuntu.com/ubuntu xenial InRelease
Feb 10 14:38:14 desktop apt.systemd.daily[3679]: Temporary failure resolving 'gb.archive.ubuntu.com'
Feb 10 14:38:14 desktop apt.systemd.daily[3679]: Err:4 http://gb.archive.ubuntu.com/ubuntu xenial-updates InRelease
Feb 10 14:38:14 desktop apt.systemd.daily[3679]: Temporary failure resolving 'gb.archive.ubuntu.com'
Feb 10 14:38:14 desktop apt.systemd.daily[3679]: Err:5 http://gb.archive.ubuntu.com/ubuntu xenial-backports InRelease
Feb 10 14:38:14 desktop apt.systemd.daily[3679]: Temporary failure resolving 'gb.archive.ubuntu.com'
Feb 10 14:38:17 desktop apt.systemd.daily[3679]: Reading package lists...
Feb 10 14:38:17 desktop apt.systemd.daily[3679]: W: Failed to fetch http://gb.archive.ubuntu.com/ubuntu/dists/xenial/InRelease Temporary fa
Feb 10 14:38:17 desktop apt.systemd.daily[3679]: W: Failed to fetch http://gb.archive.ubuntu.com/ubuntu/dists/xenial-updates/InRelease Temp
Feb 10 14:38:17 desktop apt.systemd.daily[3679]: W: Failed to fetch http://gb.archive.ubuntu.com/ubuntu/dists/xenial-backports/InRelease Te
Feb 10 14:38:17 desktop apt.systemd.daily[3679]: W: Failed to fetch http://security.ubuntu.com/ubuntu/dists/xenial-security/InRelease Tempo
Feb 10 14:38:17 desktop apt.systemd.daily[3679]: W: Failed to fetch http://ppa.launchpad.net/ubuntu-mate-dev/welcome/ubuntu/dists/xenial/InR
Feb 10 14:38:17 desktop apt.systemd.daily[3679]: W: Some index files failed to download. They have been ignored, or old ones used instead.
Feb 10 14:38:17 desktop apt.systemd.daily[3679]: + debug_echo download updated metadata (success).

Work-around:

I have worked around this by creating a file /etc/systemd/system/apt-daily.service.d/network.conf containing the following options:

Wants=network-online.target
After=network-online.target

Maybe there is a better way to specify unit dependencies or to edit the timer so it will delay on startup, but this seems to fix the issue for me.

Related bug:

This other bug might be related, but it states that it causes apt-get to hang indefinitely, which I have not seen on my system.
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1636049

Tags: xenial
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in apt (Ubuntu):
status: New → Confirmed
Revision history for this message
Julian Andres Klode (juliank) wrote :

Unfortunately for us, systemd provides no good interface to improve things. There's the ability to wait on network, but AFAIUI that does not really help much, as it does not deal with resume. Also waiting on the network could time out, and the service would then be marked as failed and also run 12 hours later.

The best solution would be to have a service that runs while the machine is online and that other units can bind to: Then you could bind the timer (!) to the online-ness of the system.

That said, Wants=network-online.target and After=network-online.target or similar are probably better than nothing.

Changed in apt (Ubuntu):
importance: Undecided → Medium
status: Confirmed → Triaged
tags: added: rls-z-incoming xenial
tags: removed: rls-z-incoming
Revision history for this message
Julian Andres Klode (juliank) wrote :

This was fixed in 1.4.2 (and the 1.3.? and 1.2.? SRUs) but I forgot to mention the bug in the changelog. Aargh.

Changed in apt (Ubuntu):
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.