Debian Bug report logs - #776152
provide meaningful exit codes for network failures

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Patrick Schleizer <adrelanos@riseup.net>

To: submit@bugs.debian.org

Subject: provide meaningful exit codes for network failures

Date: Sat, 24 Jan 2015 16:50:04 +0000

Package: apt
Severity: important

When "apt-get update" fails the program exits with a 0 status.
It would be useful if it exited with a non-zero status in that case
(or if there were a switch to tell it to do so).

This is similar to bug 41053 [1] from 1999, that says it's fixed, but it
doesn't say how it was fixed and it's apparently unfixed.

See output (shortened that a little).

> sudo apt-get update
>   Could not resolve 'ecurity.debian.org'
> Hit http://ftp.us.debian.org wheezy Release

> Reading package lists... Done
> W: Failed to fetch
http://ecurity.debian.org/dists/wheezy/updates/Release.gpg  Could not
resolve 'ecurity.debian.org'
>
> W: Some index files failed to download. They have been ignored, or old
ones used instead.
> ~ $ echo $?
> 0

(For demonstration purposes, I just added a defunct deb line
deb http://ecurity.debian.org wheezy/updates main contrib non-free)

Detecting such situations in scripts is important. At least if you
really care if some extra repository gets used during a build script or
if you care an image to be build as verifiable / reproducible as possible.

Otherwise and adversary could just prevent one from connecting to a
repository one cares to received upgrades from (such as
security.debian.org), which would effectively render apt-get's security
check for expired release files (valid-until field) [2] [3] ineffective.

There is also another issue related to exit codes. [4]

Cheers,
Patrick

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=41053
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=499897
[3]
http://blog.ganneff.de/blog/2008/09/23/valid-until-field-in-release-f.html
[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745735

Message #10 received at 776152@bugs.debian.org (full text, mbox, reply):

From: Holger Levsen <holger@layer-acht.org>

To: 776152-subscribe@bugs.debian.org

Cc: 776152@bugs.debian.org

Subject: useful indeed

Date: Mon, 26 Jan 2015 11:20:25 +0100

[Message part 1 (text/plain, inline)]

Hi,

I just want to chime in and add my support for this feature request.

Coincidently I've just done the following commit to jenkins.debian.net.git:

commit 2ccb4f0a631291f0ae3df1438b60c95d5d51374a
Author: Holger Levsen <holger@layer-acht.org>
Date:   Mon Jan 26 11:05:36 2015 +0100

    chroot-install: work around temporarily download problems by repeating the 
step once

----

I've implemented this by grepping in the output for known failure strings, 
which of course is very suboptimal, so I would love proper exit codes from 
apt!


cheers,
	Holger

[signature.asc (application/pgp-signature, inline)]

Message #15 received at 776152@bugs.debian.org (full text, mbox, reply):

From: Julian Andres Klode <jak@debian.org>

To: Patrick Schleizer <adrelanos@riseup.net>, 776152@bugs.debian.org

Subject: Re: Bug#776152: provide meaningful exit codes for network failures

Date: Mon, 27 Jun 2016 11:08:36 +0200

On Sat, Jan 24, 2015 at 04:50:04PM +0000, Patrick Schleizer wrote:
> Package: apt
> Severity: important
> 
> When "apt-get update" fails the program exits with a 0 status.
> It would be useful if it exited with a non-zero status in that case
> (or if there were a switch to tell it to do so).

I disagree that it should do that. We just redefined successful update
(for the success hook) to mean "not all sources failed". In case we
fetch anything, that's still a success, as we update the cache with
the new data.

The question what a successful update is is complicated and depends
on the expections of the person using APT. 

> This is similar to bug 41053 [1] from 1999, that says it's fixed, but it
> doesn't say how it was fixed and it's apparently unfixed.
> 
> See output (shortened that a little).
> 
> > sudo apt-get update
> >   Could not resolve 'ecurity.debian.org'
> > Hit http://ftp.us.debian.org wheezy Release
> 
> > Reading package lists... Done
> > W: Failed to fetch
> http://ecurity.debian.org/dists/wheezy/updates/Release.gpg  Could not
> resolve 'ecurity.debian.org'
> >
> > W: Some index files failed to download. They have been ignored, or old
> ones used instead.
> > ~ $ echo $?
> > 0
> 
> (For demonstration purposes, I just added a defunct deb line
> deb http://ecurity.debian.org wheezy/updates main contrib non-free)
> 
> Detecting such situations in scripts is important. At least if you
> really care if some extra repository gets used during a build script or
> if you care an image to be build as verifiable / reproducible as possible.
> 
> Otherwise and adversary could just prevent one from connecting to a
> repository one cares to received upgrades from (such as
> security.debian.org), which would effectively render apt-get's security
> check for expired release files (valid-until field) [2] [3] ineffective.

Maybe we should do some apt-cache check-expiry command that people can
run from their script to check if their downloaded lists are still
considered "safe"?

And possibly check gpg sigs as well?

> 
> There is also another issue related to exit codes. [4]
> 
> Cheers,
> Patrick
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=41053
> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=499897
> [3]
> http://blog.ganneff.de/blog/2008/09/23/valid-until-field-in-release-f.html
> [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745735

-- 
Debian Developer - deb.li/jak | jak-linux.org - free software dev

When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to (`inline'). Thank you.

Message #24 received at 776152@bugs.debian.org (full text, mbox, reply):

From: Patrick Schleizer <adrelanos@riseup.net>

To: Julian Andres Klode <jak@debian.org>, 776152@bugs.debian.org

Subject: Re: Bug#776152: provide meaningful exit codes for network failures

Date: Mon, 27 Jun 2016 11:06:56 +0000

Julian Andres Klode:
> On Sat, Jan 24, 2015 at 04:50:04PM +0000, Patrick Schleizer wrote:
>> Package: apt
>> Severity: important
>>
>> When "apt-get update" fails the program exits with a 0 status.
>> It would be useful if it exited with a non-zero status in that case
>> (or if there were a switch to tell it to do so).
> 
> I disagree that it should do that. We just redefined successful update
> (for the success hook) to mean "not all sources failed". In case we
> fetch anything, that's still a success, as we update the cache with
> the new data.

Then perhaps have a new command line parameter? Such as 'apt-get
--strict update' or 'apt-get strict-update' or something like that?

Cheers,
Patrick

Message #29 received at 776152@bugs.debian.org (full text, mbox, reply):

From: Justin Dove <dove@mit.edu>

To: Julian Andres Klode <jak@debian.org>, 776152@bugs.debian.org

Subject: Re: Bug#776152: provide meaningful exit codes for network failures

Date: Wed, 14 Mar 2018 00:44:52 +0000

[Message part 1 (text/plain, inline)]

For laptop users in particular, the first run of apt-daily.service each day
is likely to occur on boot or after resume from suspend. Such a run will
fail to update package lists due to a DNS failure because of #834414. The
problem is made worse, however, because of apt's current exit code
behavior. After a failure to fetch, apt still exits with 0, and so the
apt.systemd.daily script considers it successful and touches the
update-stamp. Accordingly, all future runs of apt-daily.service that day
will check the update-stamp, see that it is recent, and abort running. So,
even if apt-daily.service has a chance to run later in the day when the
laptop is awake and network is up, it still will fail to update package
lists.

It seems that either apt's exit code behavior needs to change according to
this bug report, or if this is intended behavior then apt.systemd.daily
needs to check for DNS failure and handle it differently, in which case
perhaps a new bug report needs to be filed. Can someone advise?

When #834414 is fixed, this will not be as common of an issue, but it still
remains a separate bug as it is imaginable that the first run of
apt-daily.service in a given day could happen while DNS is down for any
number of reasons.

[Message part 2 (text/html, inline)]

Send a report that this bug log contains spam.