Possible Bug with "-F" in 1.1.2?

From: Henning Schmiedehausen <henning@dont-contact.us>
Date: 7 Jan 1997 13:33:29 +0100

Hi!

I'm not too sure, that this is an "user too dumb error" or a real
bug. Yesterday I needed to upgrade from my trustworthy 1.0.12 squid to
version 1.1.2. I kept my startup-script like it was with 1.0.12:

$SQUID_HOME/bin/squid -sY -F -f $SQUID_HOME/etc/squid.conf &

Oh, I must mention that this is on an P100 with 32 M RAM running a
modified RedHat 3.0.3 with 2.0.23 Kernel.

After I did this, I went home to find out the next morning to my
surprise that squid used 97% CPU time all night long.

I looked with strace into the process and saw a very fast running loop
with a select and three gettimeofday's.

When I removed the '-F' switch from the command line, everything went
back to normal.

I could trace the problem to this part of the code:

[main.c]

        eventRun();
        if ((loop_delay = eventNextTime()) < 0)
            loop_delay = 0;
[...]
with [event.c]

time_t
eventNextTime(void)
{
    if (!tasks)
        return (time_t) 10;
    return tasks->when > squid_curtime;
}

returning always '0'.

This seems to be fine for the fast cache rebuild but somehow the
rebuild-job is never stopped and demands all CPU time.

I'm not too fit with the internal workings of squid (read: some of it
is simple magic to me ;-) ) so I'm not sure if this is just a trivial
configuration error or a real bug in 1.1.2. Sorry, I can't give you a
better error report either.

        Clueless
                Henning

-- 
Dipl.-Inf. Henning Schmiedehausen - henning@iconsult.com           
                                                                        "Bah."
ICONSULT Tandogan - Schmiedehausen - Egerer GbR  Tel.: +49-9131-9047-12
Memelstrasse 38 - D-91052 Erlangen               Fax.: +49-9131-9047-77
		  Why get in line, if you don't wanna wait?
	   They say that "time is money" - sell your watch today.
Received on Tue Jan 07 1997 - 04:48:19 MST

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:34:00 MST