Re: [squid-users] squid needs restarting after internet connect

Henrik, thanks for your reply.

Henrik Nordstrom wrote:

> Make sure that /etc/resolv.conf (or squid.conf) contains your ISP name
> servers,

The problem is not that the contents of resolve.conf are wrong. They are
always correct. The problem is that squid doesn't change its nameserver
settings to reflect changes in resolve.conf.

I have tried putting the ISP nameservers after the first two lines of
resolve.conf (ie, as lines 3 and 4), but this has the undesirable
side-effect that each access to a new site waits for the nameservers
listed in the first two entries to timeout before the page can be
fetched. (I notice that squid subsequently caches the DNS server that
worked for that site, so subsequent fetches from that site are fast - nice).

> or run a caching DNS locally.

That was one of my initial thoughts. I can't remember anymore if NAMED
responds dynamically to changes in resolve.conf. Regardless, I wanted to
find out if this could be fixed by adjusting squid, before bringing
another process into the mix.

> Alternatively modify your ADSL connect script to issue a "squid -k
> reconfigure" after successful connection.

I have also considered this. What is actually needed is a "squid -k
reconfigure" whenever resolve.conf changes, which is whenever an
interface is brought up or down that has PEERDNS set to true.

Eg, if I shut down ADSL and bring up the LAN interface (in the office)
then I need a "squid -k reconfigure" as well.

One solution is to put a "squid -k reconfigure" into my "ifup-local"
script. The problem there is that these mods almost always get lost when
upgrading/reinstalling the distro.

I have also looked at the workings of "ifup-post", which calls a
do_netreport() function. This iterates all the files in
/var/run/netreport, and sends the process identified by each a "kill
-SIGIO" signal. Would this work for squid?

Squid doesn't seem to enable this automatically, so I presume I would
have to modify the startup script in /etc/init.d, meaning that the
changes will also most probably be lost on an upgrade.

A different solution would be to have squid detect that resolve.conf has
changed, and do the reconfigure automatically. To avoid the inefficiency
of polling a file system object, I would propose that squid checks if
resolve.conf has changed whenever it gets a timeout from the first
nameserver from resolve.conf.

I am happy to look at the code and create a patch if I can. However,
there's no point doing so if it is unlikely to be accepted into the
production version. What are people's thoughts?

Are there any better solutions I've missed?

Cheers!
Nik.

PS: do people prefer to be included in the reply list, or to only get
replies via the mailing list?
Received on Wed Apr 06 2005 - 18:20:27 MDT