Upstream fixed this bug in release contained in Bionic.
** Changed in: squid3 (Ubuntu)
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/988802
Title:
squid3 ki
** Bug watch added: Squid Bugzilla #3819
http://bugs.squid-cache.org/show_bug.cgi?id=3819
** Changed in: squid
Importance: Medium => Unknown
** Changed in: squid
Status: Invalid => Unknown
** Changed in: squid
Remote watch: Squid Bugzilla #3097 => Squid Bugzilla #3819
--
You rece
Launchpad has imported 7 comments from the remote bug at
http://bugs.squid-cache.org/show_bug.cgi?id=3097.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.l
Still experience this problem with latest updates (installed new 12.04
yesterday)
2013/10/06 03:41:08| assertion failed: disk.cc:377: "fd >= 0"
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/988802
Ti
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
--
You received this bug notification because you are a mem
The attachment "Delay resolvconf reload when immediately after boot" 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 situ
On the available evidence that this bug is caused by resolvconf reload squid
"too soon", I attach a work-around patch.
It delays any resolvconf reload by 30 seconds if it occurs within 200 seconds
of boot.
Those numbers might well need tuning on other systems, but the patch has solved
the issu
My trial patch to solve bug #995523 "squid3 is killed by
/etc/resolvconf/update-libc.d/squid3" , now lets this bug be triggered instead.
That bug was caused by squid receiving a HUP before the signal handler has been
configured. My patch just moved the HUP handler earlier. Thus a reconfigure as
Upstream bug referenced here is about cache storage failures during
startup/reconfigure. Which seems a bit at odds with resolv.conf loading
errors, although it may be a secondary bug result of the resolv.conf
reconfigure action being successfully triggered very early after
startup.
A stack trace i
I can also confirm this exact problem occurring in 12.04 32-Bit, in a
server configuration with dnsmasq. Squid is configured to use 127.0.0.1
(dnsmasq) as a name server. dnsmasq is configured with a set of upstream
DNS servers.
dmesg:
[ 17.256295] init: squid3 main process (1236) killed by ABRT
Marked 'Confirmed' as multiple reports upstream and 'High' - as TJ
states 'The service can be successfully restarted manually but that is
no solution for an unattended server.'
** Changed in: squid3 (Ubuntu)
Status: New => Confirmed
** Changed in: squid3 (Ubuntu)
Importance: Undecided =
** Description changed:
On 12.04 x86 server during start-up.
dmesg shows:
[ 79.073519] init: squid3 main process (3562) killed by ABRT signal
/var/log/squid3/cache.log.1 shows:
$ sudo tail /var/log/squid3/cache.log.1
2012/04/26 11:12:23| Loaded Icons.
2012/04/26 11:
12 matches
Mail list logo