This bug was fixed in the package apt - 1.5~rc2
---------------
apt (1.5~rc2) unstable; urgency=medium
[ Julian Andres Klode ]
* Actually install apt_auth.conf manual page (Closes: #873934)
* test: Workaround gpgv warning
* apt-daily: Wait for network before daily updates.
Introduce a new helper, apt-helper wait-online that uses
NetworkManager and/or systemd-networkd to wait for them
reporting online, with a time out of 30 seconds; and run
that helper before running the daily update script. (LP: #1699850)
* apt-daily: Pull in network-online.target in service, not timer
* Do not warn about duplicate "legacy" targets (Closes: #839259)
(LP: #1697120)
* cdrom: Don't hardcode "Files" field for copying source files
* ftparchive: Do not pass through disabled hashes in Sources (Closes: #872963)
* Directly link against libudev on Linux systems - this does not affect
public API and ABI, but protected pkgUdevCdromDevices function pointers
were renamed and are now always NULL, even if Dlopen returns true.
[ Christos Trochalakis ]
* doc: correct '--allow-releaseinfo-change-*' typos (Closes: #873914)
[ Frans Spiesschaert ]
* Dutch program translation update (Closes: #874285)
* Dutch manpage translation update (Closes: #874293)
[ David Kalnischkies ]
* don't write & chmod /dev/null log files
* don't ask an uninit _system for supported archs (LP: #1613184)
-- Julian Andres Klode <j...@debian.org> Sat, 09 Sep 2017 21:47:14
+0200
** Changed in: apt (Ubuntu)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apt in Ubuntu.
https://bugs.launchpad.net/bugs/1699850
Title:
Reliable network connectivity for apt-daily
Status in systemd:
Unknown
Status in apt package in Ubuntu:
Fix Released
Bug description:
[Impact]
apt-daily.service is launched by a timer that depends on network-
online.target (after the fixes for bug 1686470 are in everywhere)
At boot that is mostly sufficient for it to have network online, but
it does not seem to work all the time, and we might be disagreeing
with network-manager and friends what online state means.
At resume time, network-online.target is still active, so the service
is started as soon as possible when it tries to catch up. Depending on
the timing, the network connectivity might not be there yet, and it
will fail and only retry 12 hours later.
[Proposed solution]
Introduce a new apt-helper wait-online that waits for the machine being
online, using both network-manager and systemd-networkd helpers. If the service
is active, we use the respective online wait helper to wait for it to signal
onlineness. Once all helpers have reported onlineness, we continue.
[Original proposal, to be done later]
original plan:
It tries to connect() to remote hosts specified in sources.list until one
connection works or a TIMEOUT is reached. The proposed algorithm looks
something like this:
while (time elapsed < TIMEOUT):
for each entry:
host = getaddrinfo()
if host failed:
continue
fd = connect to it
if fd is invalid:
continue
all fds += fd
if poll(all fds, 100 ms timeout) finds a connected one:
exit(0)
exit(42) # timeout
There are two things to consider:
* getaddrinfo() and connect() may fail if network is not up yet, so we need
to retry (we might need to sleep somewhere)
* If poll() fails, we likely sleep enough, so no extra sleep needed.
I believe the time out should be something like 30s.
On the systemd service side, we add:
ExecStartPre=/usr/lib/apt/apt-helper wait-online
RestartForceExitStatus=42
RestartSec=15m
To retry the service after 15 minutes.
[Test case]
* Start apt-daily.service after turning off network -> It should wait (in
ExecStartPre)
* Turn on network -> apt-daily.service should start
[Regression potential]
There might be increased I/O activity after resume, if that did not work
before. The helper is launched in an ExecStartPre unit and failures are marked
as ignored by "-". systemd automatically kills all ExecStartPre processes when
the main ExecStartPre process exits, so there is no chance of ending with some
child process still running.
To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1699850/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
