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
