Re: [squid-users] Squid suddenly stops

> On Mon, 8 Mar 2004, dtom wrote:
>
> > Occasionally, My squid suddenly stops. Squid process exists but does not respo
> > nd.
> > No more log is written to access.log and squid process consumes about 50% of c
> > pu
> > (30% is usual cpu load).
> >
> > Squid Cache: Version 2.5.STABLE4-20031230
>
> Upgrade. This snapshot release is known to be broken with these symptoms.
> See the known bugs page for details.
>
> Regards
> Henrik

I found the bug(Bug number is #891) that be able to cause the problem which is similar to this one.
But, #891 says

melchior# pstack 1317
1317: (squid) -f /usr/local/squid/etc/squid.conf
 00080c64 ipcache_purgelru (0, 80c10, eac88, 0, 41d00149, 425b8f1d) + 54
 000537d0 eventRun (10d684, 0, ae400, 5, 0, ff19ef2c) + 260
 00085584 main (3, ffbff9c4, ffbff9d4, 2163e8, 0, 0) + 674
 0001c53c _start (0, 0, 0, 0, 0, 0) + 5c

A truss (including function calls) shows the following calls being repeated:
1317/1: psargs: (squid) -f /usr/local/squid/etc/squid.conf
1317/1: 0.8831 -> memInUse(0x23, 0x1, 0x10000, 0x40240000)
1317/1: 0.8839 -> memPoolInUseCount(0xa52888, 0x8c, 0x23, 0x0)
1317/1: 0.8845 <- memPoolInUseCount() = 937
1317/1: 0.8849 <- memInUse() = 937
1317/1: 0.8853 -> memInUse(0x23, 0x1, 0x10000, 0x40240000)
1317/1: 0.8858 -> memPoolInUseCount(0xa52888, 0x8c, 0x23, 0x0)
1317/1: 0.8862 <- memPoolInUseCount() = 937
1317/1: 0.8866 <- memInUse() = 937
1317/1: 0.8870 -> memInUse(0x23, 0x1, 0x10000, 0x40240000)
1317/1: 0.8875 -> memPoolInUseCount(0xa52888, 0x8c, 0x23, 0x0)
1317/1: 0.8880 <- memPoolInUseCount() = 937
1317/1: 0.8884 <- memInUse() = 937

On the other hand my squid says

# pstack gcore
core 'gcore.20040217.23692' of 23692: (squid) -D
----------------- lwp# 1 / thread# 1 --------------------
 0005e9d0 toMB (307f8708, 0, 1, a57d0, 205, 11f) + 34
 0003ed54 eventRun (138800, c8000, c8000, 179594, 179400, 9e800) + 64
 0005d6e0 main (c8400, ffbefe14, ffbefe20, 13800c, 0, 0) + 3ac
 0001cee8 _start (0, 0, 0, 0, 0, 0) + 58
----------------- lwp# 2 / thread# 2 --------------------
 ff11ea68 signotifywait ()
 ff04ed54 _dynamiclwps (ff06e000, 0, 0, 0, 0, 0) + 1c
 ff052030 thr_yield (0, 0, 0, 0, 0, 0) + 8c
----------------- lwp# 3 --------------------------------
 ff059770 lwp_cond_wait (ff075548, ff075558, ff06edb0)
 ff0490ac _age (3e, ff06ed9c, ff06e000, 0, 0, 4) + 74
 ff11c668 _door_return (ff175cb0, ff04a740, 0, 0, 0, 0) + 68
----------------- lwp# 4 --------------------------------
 ff11c60c door (0, 0, 0, 0, ff165d10, 4)
 ff056ba4 _sc_door_func (7, ff06f688, ff06f6a0, 3, ff06e000, 1) + 54
 ff04a740 _lwp_start (ff165d70, 0, 6000, ff175b74, 0, 0) + 18
 ff052030 thr_yield (0, 0, 0, 0, 0, 0) + 8c
-------------------------- thread# 3 --------------------
 ff04ddbc _reap_wait (ff0729e0, 20520, 0, ff06e000, 0, 0) + 38
 ff04db14 _reaper (ff06ee30, ff074740, ff0729e0, ff06ee08, 1, fe400000) + 38
 ff05b728 _thread_start (0, 0, 0, 0, 0, 0) + 40

# truss -o /truss.txt -faeld -wall -rall -vall -p 23692
Base time stamp: 1076991269.7364 [ Tue Feb 17 13:14:29 JST 2004 ]
23692/1: psargs: (squid) -D
23692/3: 9.5866 lwp_cond_wait(0xFF075548, 0xFF075558, 0xFF06EDB0) Err#62 ETIM
E
23692/3: condvar type: USYNC_THREAD
23692/3: mutex type: USYNC_THREAD
23692/3: timeout: 300.000000000 sec

These are not same and are not similar each other.
I don't think this patch can repair this problem.
Would you mind advising from different view?
Received on Mon Mar 08 2004 - 19:51:15 MST