Amos Jeffries wrote:
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.
---
I thought 3.2.0.9 was latest stable in that series...my bad.
>>
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".
---
That's actually the server name. This one is still a bit
perplexing, but not going to worry about it.
NOTE, the above message are ***real*** important personally, as I'm
not getting them with my new build and using aufs.
---
^^really messed up that line, left out, the NOT, I was trying
to emphasize by all the '**' round 'real'...(talk about missing the the
forest for the trees!)...
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.
----
Great to hear, since aufs has been working great for me..
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.
---
Well, they gave me things to look for as to why things weren't
working... ;-)....
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.
----
Oddly enough I was getting MANY sig6's in suse's build and their's
is 3.1 based. But it might be related to the directory they have
configured for *squid*'s 'system shared state dir' (/comm in configure),
is /var/squid, which I found missing, so maybe that was causing problems
with the stock suse rpm, though it wasn't working as well as the version
I'd build from 3.0-HEAD....
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.
----
It doesn't use what's from 'configure'?
Suse's config process uses a val of prefix=/usr, so
it would have been trying to use '/usr/var/run', which would
be a problem... ;-)
>> ---
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
----
I would, and will probably try 3.2 again, as I a multicore
machine that I run squid on. But to solve my problem, I gave up
on 3.2 for the nonce, and did a make from 3.HEAD (which a cron
job keeps updated daily). I was surprised/'didn't get' that 3.HEAD
was only a devel-branch for 3.1 -- as the 3.2 incompat's/probs I had
in converting, on top of using the wrong (too 'new') version, all went
away when I went back to a build from 3.HEAD.
I could have resorted to backups, but wanted to work forward.
Am working through several follow probs from my server distro
upgrade (lots of consequential problems in refixing config stuff...)..
So when I get back to a stable 'network', Maybe I'll try finding the
3.2.HEAD (am presuming that's what it would be called...)....
Glad to hear I wasn't just running into not knowing how
to configure something and that you've already fixed real probs.
All an interesting diversion ...
Thanks for the explanations...now that I know about 3.2 and its
features, I'm wanting to get it working...
Linda
