apt does not time out during initial update

[Joshua Kwan]

Binary package hint: ubiquity

I am behind a proxy, so direct connections to the Internet via my LAN do not work. When performing an unattended install of Lucid alpha 2, it calls apt-get update inside /target with an HTTP timeout. However, that timeout is not honored, and apt-get hangs forever.

It's possible that this is a bug with apt, or more likely with the way that Ubiquity talks to apt. Feel free to reassign.

 6056 ? S 0:02 /usr/bin/perl -w /usr/bin/debconf-communicate -fnoninteractive ubiquity
 6058 ? S 0:00 log-output -t ubiquity --pass-stdout /usr/share/ubiquity/install.py
 6059 ? S 1:39 /usr/bin/python /usr/share/ubiquity/install.py
 6093 ? S 0:00 log-output -t ubiquity --pass-stdout /usr/share/ubiquity/apt-setup
 6094 ? S 0:00 /bin/sh -e /usr/share/ubiquity/apt-setup
 6097 ? S 0:00 /bin/sh /usr/lib/ubiquity/apt-setup/apt-setup --log-output /target
 6461 ? S 0:00 /bin/sh /usr/lib/ubiquity/apt-setup/apt-setup-verify --from 500 --to 600 /target/tmp/fileF6wrt5 /target/etc/apt/sources.list.new
 6464 ? S 0:00 log-output -t apt-setup in-target debconf-apt-progress --logstderr --dlwaypoint 100 --from 500 --to 600 -- apt-get -o APT::Get::List-Cleanup=false -o Dir::Etc::sourcelist=/tmp/filepRh0Ui -o Acquire::http::Timeout=30 update
 6465 ? S 0:00 /bin/sh /bin/in-target debconf-apt-progress --logstderr --dlwaypoint 100 --from 500 --to 600 -- apt-get -o APT::Get::List-Cleanup=false -o Dir::Etc::sourcelist=/tmp/filepRh0Ui -o Acquire::http::Timeout=30 update
 6490 ? S 0:00 log-output -t in-target chroot /target debconf-apt-progress --logstderr --dlwaypoint 100 --from 500 --to 600 -- apt-get -o APT::Get::List-Cleanup=false -o Dir::Etc::sourcelist=/tmp/filepRh0Ui -o Acquire::http::Timeout=30 update
 6491 ? S 0:02 /usr/bin/perl -w /usr/share/debconf/frontend /usr/bin/debconf-apt-progress --logstderr --dlwaypoint 100 --from 500 --to 600 -- apt-get -o APT::Get::List-Cleanup=false -o Dir::Etc::sourcelist=/tmp/filepRh0Ui -o Acquire::http::Timeout=30 update
 6493 ? S 0:00 /usr/bin/perl -w /usr/bin/debconf-apt-progress --logstderr --dlwaypoint 100 --from 500 --to 600 -- apt-get -o APT::Get::List-Cleanup=false -o Dir::Etc::sourcelist=/tmp/filepRh0Ui -o Acquire::http::Timeout=30 update
 6494 ? S 0:00 apt-get -o APT::Status-Fd=4 -o APT::Keep-Fds::=5 -o APT::Keep-Fds::=6 -o APT::Get::List-Cleanup=false -o Dir::Etc::sourcelist=/tmp/filepRh0Ui -o Acquire::http::Timeout=30 update
 6496 ? S 0:00 /usr/lib/apt/methods/http
 6633 tty2 R+ 0:00 ps axwwww

The only uncommented deb lines in of /tmp/filepRh0Ui point to http://us.archive.ubuntu.com.

[Monkey (monkey-libre)]

Please give more information, I´ve added a link for that. Thank You for making Ubuntu better.

https://wiki.ubuntu.com/DebuggingUbiquity/AttachingLogs

[Colin Watson (cjwatson)]

I don't see how any more information is needed here. Marking as New pending somebody else confirming it, but anyone who marks this as Incomplete should state precisely which information they're asking for, and preferably have some idea that it's actually relevant. :-)

Specifically, ubiquity logs don't seem likely to be especially useful here, unless in the off-chance there happens to be something on stderr. The ps trace rather suggests an apt bug, since as far as I can see this is the right way to set the timeout, so reassigning to apt unless Michael or another apt developer says otherwise.

[Michael Vogt (mvo)]

I can confirm the very long timeout here when setting:
# iptable -A OUTPUT -t tcp --dport 80 -j DROP
# apt-get update -o Acquire::http::timeout=30