Hello, i got this problem with squid in the past. My problem was squid freeze all system when i restart him for 5 minutes when it's high loaded. The only solution i got at this moment was to kill -9 squid on restart, no freeze occurs. After those events, i try a new approach, i saw squid and moreover squidguard (when loads blacklists, 96 childs) use big IOPS over the raid. I decided to create two MFS for blacklists and squid disk cache. Now the problem is resolved, IOPS are backported to memory and no freeze problem occurs. Maybe you must try this solution. (i use 1G mfs for blacklists and 4G mfs for squid disk cache). -- Cordialement, Loïc BLOT, UNIX systems, security and network expert http://www.unix-experience.fr
Le samedi 29 décembre 2012 à 18:30 +0100, epsilon a écrit : > Hi Philip, > > thanks for answering. Let's go ... > > On Sat, Dec 29, 2012 at 04:10:05AM -0800, Philip Guenther wrote: > > Your case, as far as you described it, is not the same as frantisek holop's. > > Right. Not totally the same. But some similarities. > > > Most of the descriptions I've seen have been too imprecise to help in > > diagnosis. > > "It freezes somewhere after "starting network daemons" and "starting > > local daemons". I > > tried to disable services I do not essentially need or to substitute > > them with other solutions. So far no findings here." > > > > Freezes 'somewhere'? Hard to make hypotheses about the cause when > > we're not told what processes were started, or whether it's consistent > > from freeze to freeze. If you turn on ddb.console=1 in sysctl.conf > > ddb.console=1 turned on now. Will check the next time the freeze > occurs. > > > can you break into ddb when it hangs? > > Shout at me, but the magic key mentioned in the manpage is ctrl+c on > i386, right? > > > What's trace and ps show in > > that case? show bcstats? If you've performed tests of various sorts, > > what did they show? Negative results are sometimes _more_ important > > than positive results; why bother doing a test if you're going to > > throw out the result? What hypotheses have been *excluded* by your > > test results? > > First rc.conf.local: > > sendmail_flags="-L sm-mta -C/etc/mail/sendmail.cf -bd -q30m" > named_flags="" > httpd_flags="-DSSL -u" > ftpproxy_flags="" > tftpd_flags="-4 -l 192.168.xx.xx /tftpboot" > ifstated_flags="" > dhcpd_flags="xl0" > > additionally rc.local: > > /usr/local/sbin/sockd -D > /usr/local/sbin/squid > > I did use the old sytyle for starting local daemons to eliminate > problems with the new rd.d system. It is just a guess. But > unfortunately no result. Please: I did not mean there are problems > with the recent introduced rc.d system. It was just a guess to see if > this changes anything. But it did not. > > Now what did I mean with somewhere: Randomly. The freeze happens > randomly after starting one of the daemons. There is no pattern. > Sometimes it freezes after starting sshd, sometimes later. In one case > the freeze was after the loginprompt appears. In most cases it's > earlier. > > What else did I try? > > o I substituted sockd (dante) with nylon. Result: For three days no > freeze. First I was lucky, I thought I found the problem. But than > again a freeze. > o I disabled ifstated after the freeze occured just after starting > this daemon. One day no freeze. But than again: freeze. > o I disabled ntpd complete because it's possible to operate the box > with slightly inaccurate time. So ntpd can be excluded for sure! > > What proofs this? Is is possible to exclude dante/nylon/ifstated for > sure? Not really. Maybe it's a combination I did not find so far. > > I have not disabled squid. I do not use NAT, so disable squid and > dante makes this box wortless (i.e. me offline). > > > The title of the original thread was "snapshots total freeze", but > > there were dmesg's in the thread showing Aug kernel builds; for those > > who haven't tried running a (recent) snapshot, does your problem > > reproduce or change symptoms when you do? > > For now I don't want to update the system to a snapshot. My primary > reason is this would imply a complete new installation when 5.3 comes > out. The updateprocess ist described from stable to stable and not > anything else. I hope it's possible to find something without > switching to current/snapshot. This box survived two months 5.2, so > maybe the next four month will be survived too :\ Shout at me, but I > am a -stable user. > > > Is this consistent across hardware? Drop another machine into place > > where the freezing one is; does it freeze too? > > It is consistent across hardware. I tested another hardware with some > differences: > > o SATA drive instead IDE. > o other NICs > o faster CPU (and a heavy duty fan that gaves me the ability to make a > guess on CPU load which was confirmed by j...@osn.de useing a VM). > > Additionally I ran a `dd if=/dev/rwd0c of=/dev/null bs=1m` as sugested > on the list. No errors. > > What makes me wonder is the following: Why did those freezes occur on > 5.2 and on snapshots starting in November? My box runs as a gateway > useing pppoe(4). Again I guessed: Maybe something "from the evil > internets" like those nasty bug we had once with protocol 0 (maybe > you remember the guy running nmap protocol scans through PF). So I did > not power on the DSL modem during boot for some days. But no success. > The box froze after one or two days during boot and without powered > modem. > > I think this is really the only thing I can exclude for sure. Because > my modem was switched off, it cannot be something triggered from the > "evil internets". It must be triggered from my local site. And > additionally, it must be triggered from within this box, because for > some days I powered on this box alone, i.e. all other machines on my > local network were still switched off. Again: Freezes after some days. > > But the network is still on topic: Someone claimed he had no freezes > if he disabled logging in PF. pflogd is started _after_ PF is enabled. > Did anyone check what happens if pflogd is started before PF? Maybe I > give it a try. It's just I feel uncomfortable in hacking /etc/rc. This > file is not intended to be changed by users, right? > > Additional information: To save electrical energy I power off all my > machines during nights and during longer working pauses during days. So > usually I boot two or three times a day which gives me enough tries to > trigger the problem. What is funny: rebooting the machine just for fun > to trigger the bug did not work. I have no good explanation. > > Thanks for the ideas and suggestions for more tests. > > Regards > Eps
