Ошибка Squid ERR_CANNOT_FORWARD

В access_log нужно смотреть, как он решил поступить с запросом (HIER_DIRECT/etc).

В access.log имеется вот такое:

1518190105.148      0 127.0.0.1 TCP_MISS/500 4504 GET http://apt.llvm.org/artful/dists/llvm-toolchain-artful-4.0/InRelease - HIER_NONE/- text/html
1518190105.149      0 127.0.0.1 TCP_MISS/500 4504 GET http://apt.llvm.org/artful/dists/llvm-toolchain-artful-5.0/InRelease - HIER_NONE/- text/html
1518190105.150      0 127.0.0.1 TCP_MISS/500 4495 GET http://security.ubuntu.com/ubuntu/dists/artful-security/InRelease - HIER_NONE/- text/html
1518190105.153      0 127.0.0.1 TCP_MISS/500 4474 GET http://pl.archive.ubuntu.com/ubuntu/dists/artful/InRelease - HIER_NONE/- text/html

(часть выхлопа после запуска apt update)

HIER_NONE через 0 милисекунд. Значит в сеть не ходил вообще.

Нужно думать почему. Возможно resolv.conf ещё не был сгенерирован во время запуска, просто не знает, куда за этим идти.

В systemd-параллельщине не разбираюсь, стоит попробовать переставить его в самый конец процесса загрузки.

Поскольку после рестарта squid проблема исчезает, что-то мне подсказывает, что порядок интциализации чего-то (network?) и squid есть неправильный.

Т.е. предположение таково, что сразу после старта системы squid подключается к нерабочему сокету(?) и потому выглядит как будто есть некие проблемы с сетью.

Для ситуации уточню, что в данном случае squid находится в виртуалке (VirtualBox) с одним сетевым адаптером «attached to NAT». На адаптере выполнены следующие манипуляции:

VBoxManage modifyvm «$VM_NAME» --natdnsproxy1 on
VBoxManage modifyvm «$VM_NAME» --natdnshostresolver1 on

(взято отсюда: https://www.virtualbox.org/manual/ch09.html#nat-adv-dns)

Нужно думать почему. Возможно resolv.conf ещё не был сгенерирован во время запуска, просто не знает, куда за этим идти.

В systemd-параллельщине не разбираюсь, стоит попробовать переставить его в самый конец процесса загрузки.

О, именно то, о чем я думал

Кстати, вот что нашел в /etc/resolvconf/update-libc.d/squid

#!/bin/sh

PATH="/usr/sbin:/usr/bin:/sbin:/bin"

# Make squid aware of changes to resolv.conf
# Avoid reload before /usr is mounted
if [ -d /usr/sbin ] ; then
   invoke-rc.d squid reload || true
fi

Т.е. должно работать вне зависимости от порядка запуска.

А это точно выполняется?

Если отребутить VM и на отлынивающем сквиде скомандовать reload, что получается?

Ха, как по закону подлости не работает (в смыcле squid все равно возвращает HTTP/500), а вот через systemd норм:

systemctl reload squid

Наверное надо написать баг на launchpad

В debian та же ерунда: внесли systemd и назначили за главного.
Если даже его вынести, то потом оказывается что, к примеру, хуки pm-utils то не работают.

А зачем их вызывать откуда-либо ещё, если теперь их можно вызвать из systemd?