Precise: Squid3 does not start if ACL's require DNS lookups

[Arrigo Marchiori]

On Precise, squid3 is started by a upstart job, while bind9 is not.
This causes problem if squid3 needs to do DNS lookups when parsing its configuration file.

Example: the same machine is a DNS server and a proxy.
The file /etc/squid3/squid.conf contains the following line:
acl myacl src host.name

The bind9 service would be able to resolve host.name, but it may not be started before squid3. If this happens, squids logs the following error messages:

[...]
squid3: Bungled squid.conf line 727: acl myacl src host.name
[ 7167.978333] init: squid3 main process (4637) terminated with status 1
[ 7167.978363] init: squid3 main process ended, respawning
squid3: Bungled squid.conf line 727: acl myacl src host.name
[ 7167.995068] init: squid3 main process (4643) terminated with status 1
[ 7167.995098] init: squid3 main process ended, respawning
squid3: Bungled squid.conf line 727: acl myacl src host.name
[ 7168.012017] init: squid3 main process (4649) terminated with status 1
[ 7168.012047] init: squid3 respawning too fast, stopped

This problem consistently appears on my system.

# dpkg-query -l | grep squid
ii squid 3.1.19-1ubuntu3.12.04.1 dummy transitional package from squid to squid3
ii squid-langpack 20111114-1 Localized error pages for Squid
ii squid3 3.1.19-1ubuntu3.12.04.1 Full featured Web Proxy cache (HTTP proxy)
ii squid3-common 3.1.19-1ubuntu3.12.04.1 Full featured Web Proxy cache (HTTP proxy) - common files

# dpkg-query -l | grep bind9
ii bind9 1:9.8.1.dfsg.P1-4ubuntu0.5 Internet Domain Name Server
ii bind9-host 1:9.8.1.dfsg.P1-4ubuntu0.5 Version of 'host' bundled with BIND 9.X
ii bind9utils 1:9.8.1.dfsg.P1-4ubuntu0.5 Utilities for BIND
ii libbind9-80 1:9.8.1.dfsg.P1-4ubuntu0.5 BIND9 Shared Library used by BIND

IMHO the solution to this bug should consist of:
 1- writing an upstart job for running bind9;
 2- letting the squid3 upstart job depend on bind9.

[Robie Basak (racb)]

Thank you for taking the time to report this bug and helping to make Ubuntu better.

I think it's reasonable to request that bind9 have an upstart job, in order to permit better dependency management for services that depend on bind9.

But I'm not sure about making the squid3 depend on bind9. I understand why this is required in your case, but your configuration strikes me as quite unusual so I'm not sure if it is applicable to all users. And we would also need to handle the case when bind9 is not installed.

If we end up not doing this in the general case, then is the kind of case where I'd expect you to override your squid3 upstart job dependencies by hand, using the mechanisms already provided by upstart to do this (eg. http://web.archive.org/web/20110811021301/http://upstart.at/2011/03/11/override-files-in-ubuntu-natty/)

Marking this as Triaged, since what you are requesting is clear to developers. And adding a bind9 task for the upstart job. But I'd prefer to consult with others about a job start dependency from squid3 to bind9, since I think this is a more general issue that applies wider than just squid3.

[Robie Basak (racb)]

The ubuntu-server list is a suitable venue to consult others on the squid3 job depending on bind9, if you want to take it up there?

[Arrigo Marchiori (ardovm)]

Robie,

thank you for your comments, the link and the mailing list pointer.

I understand that bind9 should not be explicitly listed as a dependency of squid3. Maybe it could depend on some other "well-known event" that bind9 could emit...

I find upstart a bit confusing, therefore I leave this task to those who know the matter better than me. I am sorry I cannot be of any help on this, but I am open for testing any solution during the development.

[Robie Basak (racb)]

> Maybe it could depend on some other "well-known event" that bind9 could emit...

But nothing would be there to emit that on a system that doesn't do its own DNS. This is why the only reasonable answer I can give is to expect sysadmins who need this kind of complex setup to add overrides to their upstart job configuration. This does require the bind9 job to be converted to upstart of course, and I think this would be reasonable.

> I am sorry I cannot be of any help on this, but I am open for testing any solution during the development.

I appreciate you raising this, but to avoid any misunderstanding, I don't think this issue will make any progress without somebody to drive it.