x86_64 build against /lib/ld-linux.so.2 instead of /lib64/ld-linux-x86-64.so.2

[Faysal Banna]

Adrian ...
building for Fedora 11 on x86_64 it builds against  /lib/ld-linux.so.2 instead of /lib64/ld-linux-x86-64.so.2
why ????

Regards

--
============================
        Faysal Banna
Meteorological Services
Rafic Harriri International Airport
     Beirut - Lebanon
   Mob: +961-3-258043
=============================

[Adrian Chadd]

2009/6/30 Faysal Banna <degr...@gmail.com>:

> Adrian ...
> building for Fedora 11 on x86_64 it builds against  /lib/ld-linux.so.2
> instead of /lib64/ld-linux-x86-64.so.2
> why ????

No idea. :) I've not played with Fedora 11. :) I'm a FreeBSD boy remember? :)

adrian

[Faysal Banna]

yes i remember
but when Lusca compiled in x86_64 it asks for glibc-i686 and not glibc-x86_64 which yields lusca i686 and not x86_64

meaning it compiles against /lib/ and not /lib64
something in bootstrap or ./configure to tell it where to look !????


much regards

[Faysal Banna]

speaking of FreeBSD i don't mind to play alot on FreeBSD i have two machines which i can spare to do my tests on ....

but would like to have some guidance from you how to enable tproxy4 in FreeBSD kernel + which version of FreeBSD you use ???
plus the much tweaks that can be done for FreeBSD to handle all the traffic.

Regards

[Adrian Chadd]

2009/6/30 Faysal Banna <degr...@gmail.com>:

> speaking of FreeBSD i don't mind to play alot on FreeBSD i have two machines
> which i can spare to do my tests on ....
>
> but would like to have some guidance from you how to enable tproxy4 in
> FreeBSD kernel + which version of FreeBSD you use ???
> plus the much tweaks that can be done for FreeBSD to handle all the traffic.

I'm sorry that I can't help out much more at the moment. All of the
stuff I'm working on right now is changing quite often (as I'm
actively developing it all!) and I just don't have the time to also
try and help others -and- do active development.

There's only one of me involved in the project and a lot of users. :)

Hopefully some of you will step up and start helping out
others/helping out with code/helping out with documentation/etc. I
would really appreciate the assistance.

Adrian

[Faysal Banna]

I shall be glad to do the documentation ...

Regards

[Adrian Chadd]

2009/6/30 Faysal Banna <degr...@gmail.com>:

> I shall be glad to do the documentation ...

Sign up with a gmail/google account and poke me with the details so I
can add you to the project!

[Faysal Banna]

as a schematic .... tell me
if i do cache_dir  aufs /cache/squid  400000 128 256 it doesn't comply with what hendrik said in his post  for L1 and L2

http://www.eu.squid-cache.org/mail-archive/squid-users/200110/1105.html

if his formula is true then i would need 900 something as L1 ...  what would u recomend in such a case !???



nevertheless
using a formula of 64bit 1GB of cache needs around 18 MB of ram
then running my 400GB would need 400*18=7200 MB of ram rounded with extra cache_mem and other OS workload then i assume we would need 8GB ram for this ... is this true !????

 
much regards

[Nyamul Hassan]

Yes, this is certainly the case. We run caches at around these sizes,
and have 8 GB of RAM on each of them, but to get the best performance
from a cache this size, my understanding is we need at least 16 GB.

Regards
HASSAN

--
Sent from my mobile device

[Faysal Banna]

Guys i had this issue lately

2009/06/30 21:38:12| WARNING: use of 'override-expire' in 'refresh_pattern' violates HTTP
2009/06/30 21:38:12| WARNING: use of 'override-lastmod' in 'refresh_pattern' violates HTTP
2009/06/30 21:38:12| WARNING: HTTP requires the use of Via
2009/06/30 21:38:12| aclMatchWordList: looking for 'PURGE'
2009/06/30 21:38:12| aclMatchWordList: checking 'PURGE'
2009/06/30 21:38:12| cachemgrRegister: registered config
2009/06/30 21:38:12| fd_open FD 0 stdin
2009/06/30 21:38:12| fd_open FD 1 stdout
2009/06/30 21:38:12| fd_open FD 2 stderr
2009/06/30 21:38:12| leave_suid: PID 15382 called
2009/06/30 21:38:12| leave_suid: PID 15382 giving up root, becoming 'squid'

*** glibc detected *** squid: malloc(): memory corruption: 0x000000002608c630


Regards

[Faysal Banna]

I also have

squid[15400] general protection ip:392cc76c60 sp:7fff40eea980 error:0 in libc-2.10.1.so[392cc00000+164000]

[Adrian Chadd]

As I said in a previous reply, that is some kind of memory corruption
which is going to be very difficult to track down.

All I can say is that I've not seen it anywhere on the caches that
I've setup in either testing or production. That isn't to say there
isn't a problem lurking anywhere, but I've not seen it yet.

I'd suggest slowly disabling compile time options until you have the
bare minimum, remove the configuration additions until you have the
bare minimum and see if you still have a problem. That may narrow down
the problematic behaviour to a specific set of features.

My caches generally look like this:

--prefix="/usr/local/lusca" --enable-storeio="aufs coss null"
--with--large-files --enable-large-cache-files --enable-snmp
--enable-delay-pools --enable-(Whatever transparency option I need)
(and then the auth modules as needed.)

The other thing to try is earlier versions of Squid and Lusca, going
back perhaps to the last stable Cacheboy release. See if any of those
have the same issue.

Narrowing down either the feature or relevant source change(s) is
going to be a big help.



Adrian


2009/7/1 Faysal Banna <degr...@gmail.com>:

[Faysal Banna]

Before we jump into conclusions i believe the guys at my office have installed Fedora and Broke the package dependency somewhere ...


so it became unusable for a certain reason that's why the glibc was breaking out


i am checking it manually myself to see what's on with it and be reporting you back

I believe its OS issue and not Lusca/cache issue


Regards