Lower Wait Time for Repository Updates – How to Guide

aptupdates

When doing a aptitude update / apt-get update or using the Update Manager to update sometimes I get to a repository link that takes too long. The percent does not end and it takes quite a while before it ignores it.

How can I lower the time so that if a particular repository takes more than 10 seconds to connect or finish it should ignore it and move the following ones. Here is an image explaining the problem:

enter image description here

It is trying to connect to archive.ubuntu.com but since it is taking too long it just sits there for at least 3 to 5 minutes (Haven't measured the time) and then it shows as ignored and moves to the following. I wish to change that to seconds instead of minutes.

Best Answer

How can I lower the time so that if a particular repository takes more than 10 seconds to connect or finish it should ignore it and move the following ones?

Mirrors are one option, as @adempewolff explained. Let me give you a direct answer though:

Setting apt-get connection timeouts

You can control these timeouts via the following apt.conf options:

  Acquire::http::Timeout "10";
  Acquire::ftp::Timeout "10";

Note that this only applies to connection timeouts, NOT "finish time" timeouts, i.e. if it connects within 10 seconds, it will continue to download a 100MB package even if it's at 1 KB/second :)

To implement these options, simply create a conf file in /etc/apt/apt.conf.d; suppose we call it 99timeout.

Press Alt+F2, type gksudo gedit /etc/apt/apt.conf.d/99timeout
Type/paste the above lines, with your choice of timeout in seconds
Save and exit.
Now try sudo apt-get update

And the terminal-addict's "find best server" hack!

Expanded and moved as an answer to this more appropriate question

Additional apt-get conf options that you can try to tweak

Acquire::Queue-Mode: Queuing mode; Queue-Mode can be one of host or access which determines how APT parallelizes outgoing connections. host means that one connection per target host will be opened, access means that one connection per URI type will be opened.
Acquire::Retries: Number of retries to perform. If this is non-zero APT will retry failed files the given number of times.
Acquire::http::Dl-Limit: accepts integer values in kilobytes, to throttle download speed and not slow down your browsing/email/etc. when updating. The default value is 0 which deactivates the limit and tries uses as much as possible of the bandwidth. If enabled, it will disable apt-get's parallel downloading feature.
Dig through man apt.conf if you think something else might help!

Related Solutions

Updates – How to Enable Silent Automatic Updates for Any Repository

First, install gksu:

sudo apt-get install gksu

The easiest of enabling unattended updates for your system is to edit the file 50unattended-upgrades inside /etc/apt/apt.conf.d/ with your favourite text editor, for example:

gksu gedit /etc/apt/apt.conf.d/50unattended-upgrades

In it you need to comment out the commented sections of the Allowed Origins block

Change

Unattended-Upgrade::Allowed-Origins {
        "${distro_id} ${distro_codename}-security";
//      "${distro_id} ${distro_codename}-updates";
//      "${distro_id} ${distro_codename}-proposed";
//      "${distro_id} ${distro_codename}-backports";
};

Unattended-Upgrade::Allowed-Origins {
        "${distro_id} ${distro_codename}-security";
        "${distro_id} ${distro_codename}-updates";
//      "${distro_id} ${distro_codename}-proposed";
//      "${distro_id} ${distro_codename}-backports";
};

For software that is not on the Ubuntu repos that you would like to update you need to add a origin and archive to the file. To find what those are for your PPAs open the folder /var/lib/apt/lists/, that is the storage area for state information for each package resource. What you are looking for is the files that end with Release in the name.

Open one with your text editor, ie for Google Chrome:

gedit /var/lib/apt/lists/dl.google.com_linux_chrome_deb_dists_stable_Release

Origin: Google, Inc.
Label: Google
Suite: stable
Codename: stable
Version: 1.0
Date: Thu, 17 Nov 2011 19:09:01 +0000
Architectures: i386 amd64
Components: main
Description: Google chrome-linux repository.

The origin is obvious (Origin: Google, Inc.) and the archive will be whatever is under the line Suite (Suite: stable).

If either Origin or Suite is missing then they will be the empty string. But note that if both are missing then probably it will not be possible to use that source with unattended upgrades without including other sources with the same issue.

After you noted those 2 lines you need to edit the 50unattended-upgrades file and add the lines using this format "<origin>:<archive>"; of for this examples sake "Google\, Inc.:stable";.

Google Chrome's origin is kinda tricky because it has a space a end point and a comma in it but most Release files will be easy to read.

As another example, Node JS source specifies an origin (Node Source) but not an archive; so you can match it with "Node Source:";.

Allowed Origins is matched using shell-style wildcards (more specifically, with Python's fnmatch()). If you're careful enough to not include conflicting sources it's possible to write things like "Node *:*";.

Do not forget to make a backup of your 50unattended-upgrades file before editing it, do that with sudo cp /etc/apt/apt.conf.d/50unattended-upgrades /etc/apt/apt.conf.d/50unattended-upgrades.bak.

To test the changes done on the file you can use sudo unattended-upgrades with the parameters --dry-run and --debug.

--dry-run will run an unattended upgrades cycle except it will not really install the upgrades, only check and verify that everything is ok.

--debug will enable verbose mode.

You can always check the logs for unattended-upgrades at /var/log/unattended-upgrades/unattended-upgrades.log.

You can change the configuration of the unattended upgrades by editing the file /etc/apt/apt.conf.d/10periodic, options for the configuration are in the /etc/cron.daily/apt script header. Read them to configure the frequency of the unattended upgrades.

Ubuntu 16.04.3 SSD Boot – Fixing Slow Boot Time

I went through a similar (although not as drastic) experience.

From the terminal you need to use:

sudo systemctl disable snapd.refresh.service
sudo systemctl disable NetworkManager-wait-online.service

If you aren't using snapd disabling it isn't a problem. As per my own experience disabling NetworkManager-wait-online-service during boot isn't a problem.

As far as apt-daily.service goes it's a known bug. It wasn't designed to be run during boot but fifteen minutes into your session. There are a couple of different answers to that problem but as I've never encountered it cannot say which is better. (I would go with the one with the most upvotes though).

Although SSD boot took my time from 45 seconds to 11 seconds, I'm sorry you bought one thinking it would solve this particular problem. You'll still enjoy it though because applications will load in a few seconds instead of 15 seconds.