Re: [squid-users] log message oddities -- what do they mean? how to interpret?

On 15/07/11 13:08, Linda Walsh wrote:
> Most recent info as at the bottom, but am curious about things I ran
> into....
>
> Still have 1 unknown error and no estimate on load handling ability,
> But think I will send this off now.
>
> Hopefully others will be able to give it a gander and offer insights....
>
> Thanks!
>
> Linda...
>
>
>
> I recently upgraded to 3.2.0.9
>

As documented this bundle had a lot of deep I/O and communication
architectural changes. Instability is/was expected.

Most of the bugs you hit are now resolved in the daily update bundle.
If you need a relatively stable 3.2 release please use 3.2.0.8.

>
> Jul 13 22:28:49 Ishtar squid[10383]: /var/cache/squid/03/29/00003A79
> squid[10383]: DiskThreadsDiskFile::openDone: (2) No such file or directory
> squid[10383]: /var/cache/squid/03/29/00003A7B
> squid[10383]: DiskThreadsDiskFile::openDone: (2) No such file or directory
>
> But looking in those dirs. I can see those files....so what file doesn't
> exist?
> They are owned by user/group 'squid.squid', w/perms 640.
> -----

Either the file did not exist at the time that open was attempted, or
the process logging that does not actually have squid:squid permission.
Looks like it may be running as user "Ishtar".

> NOTE, the above message are ***real*** important personally, as I'm
> not getting them with my new build and using aufs.
>
> Seems like their build was using diskthreads.
>
> I don't know if I wanted to use disk threads. (do I?)
>
> Isn't AIO faster or would disk threads be? Of course, aio doesn't seem
> to give errors like the ones above! ;-)

Linux works fastest on AUFS, BSD systems works fastest on diskd. Due to
a design problem in the AIO implementation of Squid which BSD runs up
against.

>
> But, that might be fixable if they are faster....
>
> Anyway -- (just noticed that log message above...as was looking at
> current long
> messages with 3.2.0.9... am getting many more messages/ much more
> verbosity.
> I guess my default 'build' settings are for a bit more 'noise'? (or I
> don't have
> something config'ed correctly in my squid.conf for the new 3.2).

"debug_options ALL,1" perhapse?
   There were some messages set at the wring verbosity in 3.2.0.9 and
some bugs which cause loud complaints. I think we have got most of those
ones out now.

>
> This looks like what I was seeing with 3.1 as well: lots of fails...
> with SIG 6's
>
> squid[957]: assertion failed: comm.cc:1904:
> "!commHasHalfClosedMonitor(fd)"
> squid[7072]: Squid Parent: child process 957 exited due to signal 6
> with status 0
> squid[7072]: Squid Parent: child process 6023 started
> squid[6023]: Starting Squid Cache version 3.2.0.9 for
> x86_64-unknown-linux-gnu...
> squid[6023]: Process ID 6023
> squid[6023]: With 16384 file descriptors available
> squid[6023]: Initializing IP Cache...
>
> ...and restart...
>
> So What's a !commHasHalfClosedMonitor(fd)...and why does it cause death?

pconn issues. We fixed those the other day, so the
squid-3.2.0.9-20110714 dialy should be fixed.

> ----
> (before I sent this.....going over and over config and
> squid.conf/configure/filesystem!/
> addressings and have noticed some things and tried fixes...:
>
> filesystem: looks like both the suse version (and mine, I copied theirs
> as closely as
> possible, as wanted it to use the same file locations -- presuming that
> they had set them
> up properly....*cough*)...
>
> /var/squid was (is) set for the comm shared state dir, but it didn't
> exist on my machine.

I'm not sure I quite understand what problem you are trying to describe.

Squid-3.2 IPC is (wrongly) hard-coded to use PREFIX/var/run instead of
the system local state dir. We are in progress fixing that now.

> ---
> just created it and will see if that fixes that...but now see:
>
> assertion failed: mem.cc:511: "MemPools[t]"
> ---
> Not sure why I saw this, but I twiddled some memory settings, though
> I'm not really using any delay pools...hmmm...

The fix for this is nearly out of a change audit now I hope. You can
safely work around it by erasing the assert line 511 in mem.cc

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.14
   Beta testers wanted for 3.2.0.9