> 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?
