ошибки тайм-аута в apt-get update / install

Я пытаюсь сделать apt-get update или apt-get install xyz, и я вижу таймауты вроде этого:

W: Failed to fetch http://eu-west-1.ec2.archive.ubuntu.com/ubuntu/dists/oneiric-updates/Release.gpg  
Unable to connect to eu-west-1.ec2.archive.ubuntu.com:http: [IP: 10.224.87.159 80]

Это временная проблема с Ubuntu, или, может быть, это что-то на моем конец. Ящик, к которому я обращаюсь, находится в EC2-EU.

Возможно, есть способ заставить установщика использовать серверы США, которые, похоже, работают?

7
задан 24 September 2011 в 12:44

6 ответов

Во-первых, я предполагаю, что таймауты - это временная проблема с серверами обновлений Ubuntu в этом регионе.

Следует отметить, что EC2 Ubuntu AMI указывают на обновление серверов, размещенных в регионе EC2, который вы используете. Это быстро (~ 10 Мбит / с), и вы не платите за пропускную способность.

Сказав это, ничего не происходит в отношении того, откуда вы получаете свои обновления. Вы можете изменить свой /etc/apt/sources.list, чтобы указать на разные серверы обновлений в другом регионе. Два предложения об обходном пути:

скопируйте sources.list из региона США на ваши хосты в ЕС. добавьте следующую строку в верхнюю часть вашего sources.list: deb mirror://mirrors.ubuntu.com/mirrors.txt oneiric main restricted universe multiverse

. Что является опрятным во втором решении, так это то, что этот файл «mirror.txt» динамически генерируется через GeoIP и всегда должен возвращать хорошее и относительно близкое зеркало. Это замечательно для пользователей Ubuntu, которые часто путешествуют.

Опять же, учитывая особый характер архивных серверов на EC2, я обычно не делал этого на экземпляре облака. И я бы сделал только одно из этих обходных решений как временную меру. Проблема, где бы она ни была, является временной, и я ожидаю, что она будет исправлена ​​довольно быстро.

10
ответ дан 25 May 2018 в 18:39
  • 1
    Ага, теперь я это понимаю. Я построил этот ящик с изображениями AMI Amazon на cloud.ubuntu.com, и он подключился к локальному серверу (который не работает, как он появляется). Я прокомментировал все строки с этим сервером и добавил ваше зеркало: // строка вверху, и все работает. Дайте мне знать, если комментировать все остальные строки имеют некоторые отрицательные побочные эффекты. – David Parks 24 September 2011 в 02:25
  • 2
    Хм. Это довольно интересно. Мне не приходило в голову, что зеркальца deb: // строка будет работать сама по себе, но теперь имеет смысл теперь упомянуть об этом. Пока он работает, я вообще не вижу проблемы. Сказав это, он, вероятно, будет работать так же хорошо, как исходные записи остаются нетронутыми. Зеркальная линия просто должна быть первой. – Mark Russell 24 September 2011 в 02:36
  • 3
    Было около 6 строк, ссылающихся на плохой сервер, они работали, комментируя их и оставляя только эту строку, я смог выполнить установки всего программного обеспечения, в котором я нуждался. – David Parks 25 September 2011 в 01:51
  • 4
    У меня была эта проблема пару раз. У меня есть дополнительный ENI и дополнительный IP-маршрут / правила для его обработки .. и отлично работает после настройки, но если я оставлю экземпляр на некоторое время (недели) и вернусь к нему, я подключился к нам-запад-2. ec2.archive.ubuntu.com не работает. Перезагрузка экземпляра возвращает его. Не исследовали, что может прерывать с помощью ip route / rules ... – sonjz 5 August 2015 в 00:03

Во-первых, я предполагаю, что тайм-ауты - это временная проблема с серверами обновлений Ubuntu в этом регионе.

Следует отметить, что EC2 Ubuntu AMI указывают на обновление серверов, размещенных в регионе EC2, который вы используете. Это быстро (~ 10 Мбит / с), и вы не платите за пропускную способность.

Сказав это, нет ничего принудительного в том, откуда вы получаете свои обновления. Вы можете изменить свой /etc/apt/sources.list, чтобы указать на разные серверы обновлений в другом регионе. Два предложения об обходном пути:

  • скопируйте sources.list из региона США на ваши хосты в ЕС.
  • добавьте следующую строку в начало вашего sources.list : deb mirror://mirrors.ubuntu.com/mirrors.txt oneiric main restricted universe multiverse

. Что во втором заключается в том, что этот файл «mirror.txt» динамически генерируется через GeoIP и всегда должен возвращать хорошее и относительно близкое зеркало. Это замечательно для пользователей Ubuntu, которые часто путешествуют.

Опять же, учитывая особый характер серверов архивации на EC2, я обычно не делал этого на экземпляре облака. И я бы сделал только одно из этих обходных решений как временную меру. Проблема, где бы она ни была, является временной, и я ожидаю, что она будет исправлена ​​довольно быстро.

10
ответ дан 2 August 2018 в 02:57

Во-первых, я предполагаю, что тайм-ауты - это временная проблема с серверами обновлений Ubuntu в этом регионе.

Следует отметить, что EC2 Ubuntu AMI указывают на обновление серверов, размещенных в регионе EC2, который вы используете. Это быстро (~ 10 Мбит / с), и вы не платите за пропускную способность.

Сказав это, нет ничего принудительного в том, откуда вы получаете свои обновления. Вы можете изменить свой /etc/apt/sources.list, чтобы указать на разные серверы обновлений в другом регионе. Два предложения об обходном пути:

  • скопируйте sources.list из региона США на ваши хосты в ЕС.
  • добавьте следующую строку в начало вашего sources.list : deb mirror://mirrors.ubuntu.com/mirrors.txt oneiric main restricted universe multiverse

. Что во втором заключается в том, что этот файл «mirror.txt» динамически генерируется через GeoIP и всегда должен возвращать хорошее и относительно близкое зеркало. Это замечательно для пользователей Ubuntu, которые часто путешествуют.

Опять же, учитывая особый характер серверов архивации на EC2, я обычно не делал этого на экземпляре облака. И я бы сделал только одно из этих обходных решений как временную меру. Проблема, где бы она ни была, является временной, и я ожидаю, что она будет исправлена ​​довольно быстро.

10
ответ дан 7 August 2018 в 20:51

Во-первых, я предполагаю, что тайм-ауты - это временная проблема с серверами обновлений Ubuntu в этом регионе.

Следует отметить, что EC2 Ubuntu AMI указывают на обновление серверов, размещенных в регионе EC2, который вы используете. Это быстро (~ 10 Мбит / с), и вы не платите за пропускную способность.

Сказав это, нет ничего принудительного в том, откуда вы получаете свои обновления. Вы можете изменить свой /etc/apt/sources.list, чтобы указать на разные серверы обновлений в другом регионе. Два предложения об обходном пути:

  • скопируйте sources.list из региона США на ваши хосты в ЕС.
  • добавьте следующую строку в начало вашего sources.list : deb mirror://mirrors.ubuntu.com/mirrors.txt oneiric main restricted universe multiverse

. Что во втором заключается в том, что этот файл «mirror.txt» динамически генерируется через GeoIP и всегда должен возвращать хорошее и относительно близкое зеркало. Это замечательно для пользователей Ubuntu, которые часто путешествуют.

Опять же, учитывая особый характер серверов архивации на EC2, я обычно не делал этого на экземпляре облака. И я бы сделал только одно из этих обходных решений как временную меру. Проблема, где бы она ни была, является временной, и я ожидаю, что она будет исправлена ​​довольно быстро.

10
ответ дан 13 August 2018 в 12:36
  • 1
    – David Parks 24 September 2011 в 02:25
  • 2
    – Mark Russell 24 September 2011 в 02:36
  • 3
    – David Parks 25 September 2011 в 01:51
  • 4
    У меня была эта проблема пару раз. У меня есть дополнительный ENI и дополнительный IP-маршрут / правила для его обработки .. и отлично работает после настройки, но если я оставлю экземпляр на некоторое время (недели) и вернусь к нему, я подключился к нам-запад-2. ec2.archive.ubuntu.com не работает. Перезагрузка экземпляра возвращает его. Не исследовали, что может прерывать с помощью ip route / rules ... – sonjz 5 August 2015 в 00:03

Я вижу подобное поведение с процессом cloud-init, когда я назначаю эластичный IP как часть метаданных для запуска экземпляра.

Странная вещь: я наблюдаю только одноразовые тайм-ауты в течение 30 секунд, пока работает облачный init. Я тестирую это с netcat, который запускается каждые 2 секунды как часть облачного init. Я получаю nc таймауты каждые несколько раз на некоторое время, а затем он стабилизируется. Кажется, что DNS работает каждый раз и иногда дает мне другой IP (как и ожидалось).

Я подозреваю что-то с эластичным назначением IP в инфраструктуре AWS, но я не уверен.

Другим интересным моментом является то, что http-подключения к локальному репо в моей учетной записи AWS работают нормально, и звонки на security.ubuntu.com (внешние по отношению к AWS, я считаю) тоже работают отлично. Пока я смог собрать около 15 образцов. У меня есть подтверждение, что, когда netcat не архивирует.ubuntu.com, он преуспевает в другом месте

ex из моего скрипта в cloud-init:

us-east-1.ec2.archive.ubuntu.com is an alias for us-east-1.ec2.archive.ubuntu.com.s3.amazonaws.com.
us-east-1.ec2.archive.ubuntu.com.s3.amazonaws.com is an alias for s3-1-w.amazonaws.com.
s3-1-w.amazonaws.com has address 205.251.242.197
nc: connect to us-east-1.ec2.archive.ubuntu.com port 80 (tcp) timed out: Operation now in progress
Connection to {myawsserver}.ec2.{somedomain} 80 port [tcp/http] succeeded!
Connection to security.ubuntu.com 80 port [tcp/http] succeeded!
0
ответ дан 25 May 2018 в 18:39
  • 1
    Это скорее комментарий, чем ответ. У тебя есть решение? – jmunsch 10 April 2014 в 05:44
  • 2
    Правильно - я все еще работаю над решением и неправильно разместил это как ответ вместо комментария. Я попрошу удалить. Благодарю. – Sellers 10 April 2014 в 06:55

Я вижу подобное поведение с процессом cloud-init, когда я назначаю эластичный IP как часть метаданных для запуска экземпляра.

Странная вещь: я наблюдаю только одноразовые тайм-ауты в течение 30 секунд, пока работает облачный init. Я тестирую это с netcat, который запускается каждые 2 секунды как часть облачного init. Я получаю nc таймауты каждые несколько раз на некоторое время, а затем он стабилизируется. Кажется, что DNS работает каждый раз и иногда дает мне другой IP (как и ожидалось).

Я подозреваю что-то с эластичным назначением IP в инфраструктуре AWS, но я не уверен.

Другая интересная статья: http-подключения к локальному репо в моей учетной записи AWS работают нормально, и звонки на security.ubuntu.com (внешние по отношению к AWS, я считаю) тоже работают отлично. Пока я смог собрать около 15 образцов. У меня есть подтверждение, что когда netcat не может архивировать.ubuntu.com, он преуспевает в другом месте

ex из моего скрипта в cloud-init:

us-east-1.ec2.archive.ubuntu.com is an alias for us-east-1.ec2.archive.ubuntu.com.s3.amazonaws.com.
us-east-1.ec2.archive.ubuntu.com.s3.amazonaws.com is an alias for s3-1-w.amazonaws.com.
s3-1-w.amazonaws.com has address 205.251.242.197
nc: connect to us-east-1.ec2.archive.ubuntu.com port 80 (tcp) timed out: Operation now in progress
Connection to {myawsserver}.ec2.{somedomain} 80 port [tcp/http] succeeded!
Connection to security.ubuntu.com 80 port [tcp/http] succeeded!
0
ответ дан 7 August 2018 в 20:51

Другие вопросы по тегам:

Похожие вопросы: