squid3 is killed by /etc/resolvconf/update-libc.d/squid3 in Precise

[Steffen Sindzinski]

During boot squid3 is started successfully by upstart and then killed by /etc/resolvconf/update-libc.d/squid3 but not restarted.

Can be fixed by changing /etc/resolvconf/update-libc.d/squid3 to:

#!/bin/sh

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

# Make squid aware of changes to resolv.conf
if status squid3 | grep "start/running" > /dev/null; then
    restart squid3
    #reload squid3
fi

This bug is related to:

https://bugs.launchpad.net/ubuntu/+source/squid/+bug/809526
https://bugs.launchpad.net/ubuntu/+source/squid/+bug/561750

Also /etc/resolvconf/update-libc.d/squid can be deleted in precise because squid is only a transitional package which leads to an failure message in upstart.

[James Page (james-page)]

Hi Steffen

Thanks for taking the time to report this bug in Ubuntu.

1) Also /etc/resolvconf/update-libc.d/squid can be deleted in precise because squid is only a transitional package which leads to an failure message in upstart.

Agreed - the squid package needs to tidy up files that are no longer used (this is a leftover issue from the previous squid package).

2) I'm not sure that I understand how this bug is related to the ones you detail above; squid3 by default does not do DNS checking and should be OK to do reload rather than restart.

My local squid3 deployments see to deal with this OK.

Please could you review /var/log/syslog and /var/log/squid3/cache.log for any pertinent error messages relating to the reload command and attach them to this bug report.

Marking 'Incomplete'. Please set back to 'New' once you have provided the requested information.

Thanks.

[D J Gardner (djgardner)]

My experience: roughly 30% of boots, squid starts and mid-startup it dies without logging any errors to its own files.
At least one occurance, /var/log/messages reports "kernel: [ 42.178904] init: squid3 main process (1274) killed by HUP signal"

I've seen this "premature death" at various stages in the startup e.g. a quick scan of cache.log shows it being killed after:
    Set Current Directory to /var/spool/squid3
    Adding nameserver 192.168.12.1 from /etc/resolv.conf

My guess without much testing: there is some kind of race condition/timing issue going on. Squid3 is started by upstart and at roughly the same time /etc/resolvconf/update-libc.d/squid3 is triggered (e.g. by bind9 startup, which was the previous logged event in /var/log/messages) which then sends squid a HUP.

Normally a HUP to squid is harmless (reload config), but it seems to be fatal during startup.

[Steffen Sindzinski (stesind)]

At runtime kill -sighup works fine without any messages in /var/log/syslog. Service reload as well. The problem seems only to occure at boot and the only message I found about this the "killed by HUP signal" mentioned above.

[Stefan Bader (smb)]

I can see the same on most my reboots on a Atom based mini-server. An educated guess would be that SIGHUP happens before squid3 actually has set up its own sighandler for it. And the default is exit.

[Steffen Sindzinski (stesind)]

Mine is an atom netbook mini server too.

[D J Gardner (djgardner)]

I've just had a very brief look at the code... I didn't see any reason why the HUP handling should be delayed (all the handler does is set a variable), so I've moved it earlier in the code. Patch attached.
 Wiser heads than mine might want to check that I've put it in a sane place (i.e. is there any reason it should be after the setEffectiveUser() call?)

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "Catch HUP earilier in initialisation" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

[D J Gardner (djgardner)]

Since applying the patch my server is now getting good at hitting another squid bug:
 https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/988802
Since that one is related to reconfiguring the cache during cache-rebuild, I don't find that surprising.

I expect that this will be the case for anyone else who hits this bug,

[Dmitriy Altuhov (altuhovsu)]

This bug also fixed by patch in bug #978356

Jun 23 00:04:44 server kernel: [ 14.922376] init: squid3 main process (1148) killed by ABRT signal
Jun 23 00:04:44 server kernel: [ 14.922405] init: squid3 main process ended, respawning

[Tiago Stürmer Daitx (tdaitx)]

This issue was reported as fixed by LP: #978356.