[squid-users] squid needs restarting after internet connect

Hi all,

Apologies if my question has been addressed already. I did search FAQ
and archives first, and found nothing that seemed related. My apologies
also if this post is excessively long.

I have found on a number of installations that squid fails/ceases to
work if the machine connects to the internet *after* boot time (and
therefore, after squid has been started).

Basically, whenever I connect to the internet (in each case over ADSL),
then access to web pages through squid will hang, and squid needs to be
restarted before it will work again.

On my laptop, this situation occurs whenever I boot whilst disconnected
from the office LAN, since squid is started before I connect to the
internet. If I am in the office, then the LAN (eth0) is started before
squid, and so squid works immediately. If I subsequently stop eth0, and
connect to the internet using ADSL, then squid needs to be restarted
before it will resume working.

On a friend's server, a similar situation occurs. Squid is started at
boot time, but the ADSL is connected on demand. It appears that each
time the ADSL is started, squid needs a restart before it is operational.

My laptop is running squid 2.5.STABLE1 (from RedHat 9.0), and my
friend's server is running whatever version comes with Fedora Core 2.

On my laptop:
* the connection to ADSL is made using PPPoE, running under linux
(roaring penguin).

* I need to restart squid every time I change my path to the internet
(eg, switch between eth0 and ADSL (ppp0)).

* my browser is configured to use squid as a proxy (since squid and
browser are running on the same machine, so I can see no way to make
squid a transparent proxy).

* I can successfully telnet to a remote web server before squid has been
restarted, so I am confident the problem is specific to squid.

* the contents of resolv.conf change whenever I switch between LAN and WAN.

* The logs show nothing is amiss. /var/log/messages shows no errors from
squid, and /var/log/squid/access.log shows no record of the hanging access.

On my friend's server:
* the connection is made using PPPoA which is built into the ADSL modem.
This means, among other things, that the linux network interface for the
ADSL connection is always up, and never changes address; and that no
scripts are run on the linux box when connecting to or disconnecting
from the internet.

* squid doesn't seem to require restarting every time the ADSL
reconnected. There are times the it can be disconnected and then
reconnected and squid is fine, and other times squid must be restarted
after the ADSL has been reconnected.

* squid is configured to be a transparent caching proxy. The clients on
the server's LAN are not configured to use squid as their proxy, and the
server REDIRECTs the packets to squid.

* the contents of resolve.conf do not change when the ADSL connection is
connected/disconnected. In addition, the server is running a caching DNS
server.

* I haven't checked logs, or tried telnetting manually.

One possible theory is that the problem is related to DNS resolution.
This could explain why squid shows different results to other
applications (since I understand squid does its own DNS resolution). On
my laptop, the DNS server addresses have changed whenever I switch
network (in this case, resolve.conf has definitely changed). On my
friend's server, the DNS server used by linux does not change
(resolv.conf does not change, and the local DNS server is always
available). However, I notice that squid can (usually does) check for
available DNS servers, and that this test would normally fail when squid
first starts.

So, my questions are:

1. How should I be trying to fix this? With a workaround, such as
automating a squid restart whenever the ADSL is connected; or with a fix
to squid, such as adjustment of config parameters, an upgrade, or
changes in source code?

2. Can anyone explain what is causing the problem, or suggest further
tests I could run to determine the actual cause?

All replies received with thanks.

Cheers!
Nik.
Received on Tue Apr 05 2005 - 06:06:45 MDT