Bug#776152: provide meaningful exit codes for network failures
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.
Bug#776152: provide meaningful exit codes for network failures
Julian Andres Klode: > On Sat, Jan 24, 2015 at 04:50:04PM +, 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
Bug#776152: provide meaningful exit codes for network failures
On Sat, Jan 24, 2015 at 04:50:04PM +, 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.
Bug#776152: provide meaningful exit codes for network failures
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
