Re: [squid-users] Reverse Proxy with .htaccess - does it work? - SOLVED
* On 25/04/07 14:30 +0200, Henrik Nordstrom wrote: | ons 2007-04-25 klockan 08:52 +0300 skrev Odhiambo WASHINGTON: | | > And my squid.conf entry is as before. I have tried adding login=PASS, but still | > authentication does not work as expected. | | Should work. It actually works! The problem was with some mix up created by my colleagues on the param "name=" Sorry for the noise! -Wash http://www.netmeister.org/news/learn2quote.html DISCLAIMER: See http://www.wananchi.com/bms/terms.php -- +==+ |\ _,,,---,,_ | Odhiambo Washington<[EMAIL PROTECTED]> Zzz /,`.-'`'-. ;-;;,_ | Wananchi Online Ltd. www.wananchi.com |,4- ) )-,_. ,\ ( `'-'| Tel: +254 20 313985-9 +254 20 313922 '---''(_/--' `-'\_) | GSM: +254 722 743223 +254 733 744121 +==+ "Always try to do things in chronological order; it's less confusing that way."
Re: [squid-users] Can squid block html fragments?
fre 2007-04-27 klockan 05:33 +0200 skrev Henrik Nordstrom: > tor 2007-04-26 klockan 17:17 -0700 skrev Hung Ng: > > http://globalwarmingawareness2007.org.uk is ok > > but http://globalwarmingawareness2007.org.uk#testsite > > should be blocked? > > You can block clients sending URLs like this, but most don't as > fragments is not allowed within HTTP.. (processed by the user-agent > only). > > url_regex .# Hmm.. on a second thought that probably won't work very well.. also blocking urls containing %23 Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
Re: [squid-users] Can squid block html fragments?
tor 2007-04-26 klockan 17:17 -0700 skrev Hung Ng: > http://globalwarmingawareness2007.org.uk is ok > but http://globalwarmingawareness2007.org.uk#testsite > should be blocked? You can block clients sending URLs like this, but most don't as fragments is not allowed within HTTP.. (processed by the user-agent only). url_regex .# Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
Re: [squid-users] Squid, Reverse Proxy, Large Uploads
tor 2007-04-26 klockan 16:56 -0700 skrev Justin Dossey: > Some of my users complain that large POSTs in the neighborhood of > 30-100MB, which worked before we introduced Squid into the mix, now fail > at some point along the process (it varies). Do you know if the failure is after about the same amount of time, or if that too varies? > Notwithstanding HTTP's suitability for uploads, how can I make this work? First it needs to be identified how the POSTs is terminated.. Have you changed any of the timeouts in squid.conf? Specifically, what is the lifetime_timeout set to? Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
Re: [squid-users] Timeout explanation in layman's term
fre 2007-04-27 klockan 11:15 +0800 skrev squid squid: > Thank you for the advise. So I have got read_timeout and request_timeout > mixed up. If I want to ensure that the connection from client PC --> Squid > Proxy Server --> Web Server is always there or dropped after certain time, > pls advise what are the timeout/setting that I should set??? Thank you. There is no such connection. All connections in HTTP is hop-by-hop. There is a number of connections client<->squid (usually in the range 0 to 4 depending on the page strucuture and content), and then there may be other connections squid<->webserver. The two is independent, but cache misses results in requests being forwarded on one (any available, or a new) connection to the requested server. Not entirely sure what you are asking for. Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
Re: [squid-users] Timeout explanation in layman's term
Hi Henrik, Thank you for the advise. So I have got read_timeout and request_timeout mixed up. If I want to ensure that the connection from client PC --> Squid Proxy Server --> Web Server is always there or dropped after certain time, pls advise what are the timeout/setting that I should set??? Thank you. From: Henrik Nordstrom <[EMAIL PROTECTED]> To: squid squid <[EMAIL PROTECTED]> CC: squid-users@squid-cache.org Subject: Re: [squid-users] Timeout explanation in layman's term Date: Fri, 27 Apr 2007 00:03:16 +0200 tor 2007-04-26 klockan 20:56 +0800 skrev squid squid: > connect_timeout 120 seconds - This is a timeout between Squid Proxy Server > --> Web Server and if after 120 seconds, Squid Proxy Server does not get a > reply from Web Server, it will response to the Client PC of connection timed > out error to the Web Server. Not reply. Just to connect to the server in order to send the request. (TCP connect). > read_timeout 120 seconds - This is a timeout between Client PC --> Squid > Proxy Server and if after 120 seconds, the client PC is idle (ie. IE did not > send any request), Squid Proxy Server will drop the connection between the > Client PC and Squid Proxy Server. read_timeout is on the server connection. If the server is idle not returning a piece of response within this time Squid gives up. Default 15 minutes. It's also used as timeout while trying to send the request to the server btw.. > request_timeout 30 seconds - This is a timeout between Squid Proxy Server > --> Web Server. Squid Proxy Server able to communicate with the Web Server > upon receiving a request from the Client PC. However the Web Server is not > able to complete the request after 30 seconds, Squid Proxy Server will > response to the Client PC of connection timed out error to the Web Server. request_timeout is between client->squid. Here is two different timeouts (request_timeout and persistent_request_timeout). The first is the timeout before which the client must send the first request after establishing a TCP connection to the proxy, the second is the timeout before which the client must send the next request after the response to the previous.. > pconn_timeout 120 seconds - This is a timeout between Squid Proxy Server --> > Web Server and if after 120 seconds, Squid Proxy Server will drop the > connection between the Squid Proxy Server and Web Server. Correct. Server connections not used for more than pconn_timeout is dropped to avoid wasting server resources no longer needed. Regards Henrik << signature.asc >> _ Get MSN Messenger emoticons and display pictures here! http://ilovemessenger.msn.com/?mkt=en-sg
Re: [squid-users] Error encounter when make install
Hi Henrik, Thank you for the advise. After changing the statement, the make install continue and I encountered another error as follows: then mv -f ".deps/store_dir.Tpo" ".deps/store_dir.Po"; else rm -f ".deps/store_dir.Tpo"; exit 1; fi store_dir.c: In function `storeDirGetBlkSize': store_dir.c:526: error: storage size of `sfs' isn't known store_dir.c:527: warning: implicit declaration of function `statfs' store_dir.c:526: warning: unused variable `sfs' store_dir.c: In function `storeDirGetUFSStats': store_dir.c:565: error: storage size of `sfs' isn't known store_dir.c:565: warning: unused variable `sfs' *** Error code 1 make: Fatal error: Command failed for target `store_dir.o' Current working directory /export/home/squid-2.6.STABLE12/src *** Error code 1 make: Fatal error: Command failed for target `install-recursive' Current working directory /export/home/squid-2.6.STABLE12/src *** Error code 1 make: Fatal error: Command failed for target `install' Current working directory /export/home/squid-2.6.STABLE12/src *** Error code 1 make: Fatal error: Command failed for target `install-recursive' Kindly advise on the resolution. Regards. From: Henrik Nordstrom <[EMAIL PROTECTED]> To: squid squid <[EMAIL PROTECTED]> CC: squid-users@squid-cache.org Subject: Re: [squid-users] Error encounter when make install Date: Wed, 25 Apr 2007 14:25:19 +0200 ons 2007-04-25 klockan 15:31 +0800 skrev squid squid: > structs.h:1887: error: parse error before "in_port_t" Replace "in_port_t" on that line (structs.h line 1887) with "unsigned short" and it should hopefully work better. Regards Henrik << signature.asc >> _ Get MSN Messenger emoticons and display pictures here! http://ilovemessenger.msn.com/?mkt=en-sg
[squid-users] Can squid block html fragments?
http://globalwarmingawareness2007.org.uk is ok but http://globalwarmingawareness2007.org.uk#testsite should be blocked? However http://globalwarmingawareness2007.org.uk?q=test should be OK since it is a query. Thanks for any help. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[squid-users] Squid, Reverse Proxy, Large Uploads
I use squid as a reverse proxy for two application servers. Configuration of the peers is very basic: cache_peer 192.168.0.6 parent 80 0 sourcehash no-query no-digest originserver login=PASS cache_peer 192.168.0.7 parent 80 0 sourcehash no-query no-digest originserver login=PASS I have not set any explicit timeouts or size limits in the configuration. Some of my users complain that large POSTs in the neighborhood of 30-100MB, which worked before we introduced Squid into the mix, now fail at some point along the process (it varies). Most of my users get 20-50KB/sec up, so an upload of this type would take between 10 and 90 minutes. If I re-code pages to bypass Squid, the same users are successful with their uploads (but it's a bear to get them back onto squid due to the same origin policy). Notwithstanding HTTP's suitability for uploads, how can I make this work? Environment: Gentoo Linux 2.6.19 Squid Cache: Version 2.6.STABLE12 configure options: '--prefix=/usr' '--host=i686-pc-linux-gnu' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib' '--sysconfdir=/etc/squid' '--libexecdir=/usr/libexec/squid' '--localstatedir=/var' '--datadir=/usr/share/squid' '--enable-auth=basic,digest,ntlm' '--enable-removal-policies=lru,heap' '--enable-digest-auth-helpers=password' '--enable-basic-auth-helpers=PAM,getpwnam,NCSA,MSNT' '--enable-external-acl-helpers=ip_user,session,unix_group' '--enable-ntlm-auth-helpers=fakeauth' '--enable-ident-lookups' '--enable-useragent-log' '--enable-cache-digests' '--enable-delay-pools' '--enable-referer-log' '--enable-arp-acl' '--with-pthreads' '--with-large-files' '--enable-htcp' '--enable-carp' '--enable-follow-x-forwarded-for' '--enable-snmp' '--enable-ssl' '--enable-storeio=ufs,diskd,coss,aufs,null' '--enable-async-io' '--enable-linux-netfilter' '--enable-epoll' '--build=i686-pc-linux-gnu' 'build_alias=i686-pc-linux-gnu' 'host_alias=i686-pc-linux-gnu' 'CC=i686-pc-linux-gnu-gcc' 'CFLAGS=-O2 -march=i686 -fomit-frame-pointer' -- Justin Dossey Operations, podOmatic (415) 975-9981
Re: [squid-users] Re: Unusual squid application
tor 2007-04-26 klockan 16:53 -0400 skrev BARRY J BLUMENFELD: > I now have done a controlled test and squid is definitely NOT > consolidating all the requests. Squid by default only consolidates requests after it knows the object can be cached. What this means is that if you have N requests sent at the same time (or more exactly, before the response headers is known to Squid) then they will all get forwarded as Squid doesn't yet know. In Squid-2.6 there is an option to make Squid consolidate requests more aggressively, at the cost of slightly increased latency if it turns out the object isn't cachable. Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
Re: [squid-users] private DNS, browsers, and Squid
tor 2007-04-26 klockan 11:16 -0400 skrev Michael W. Lucas: > Packet sniffing shows that the client is talking to the proxy, but the > client is also trying all of its DNS servers to resolve the hostname > of the Web site. With complex Web sites this can take a while -- for > example, the front page for www.cnn.com has several hostnames in it. > I suspect this is causing the very slow access. Should not, assuming the private DNS has a proper private root zone allowing it to promptly reject DNS queries for other domains with "Domain does not exists". This is needed for any IP based proxy.pac rules to work proper, if not they will get significant delays due to DNS trying to resolve external names and the DNS servers not knowing what to do.. > Do other people see this behavior? What did you do? Surely we're not > the first people to use Squid, IE, and private DNS? Have run it very successfully at different customers. Technically it's no different from having a public DNS, in many cases even a lot more efficient as the internal DNS infrastructure does not get clogged with external DNS data and the clients do not need to wait for external DNS lookups just to find if a site is internal or not.. Drawback from having an private unconnected DNS infrastructure is that the "hack" of returning "DIRECT" on unresolvable domains obviously doesn't work so users will see the proxy error instead of the browser error when they type wrong.. Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
Re: [squid-users] Timeout explanation in layman's term
tor 2007-04-26 klockan 20:56 +0800 skrev squid squid: > connect_timeout 120 seconds - This is a timeout between Squid Proxy Server > --> Web Server and if after 120 seconds, Squid Proxy Server does not get a > reply from Web Server, it will response to the Client PC of connection timed > out error to the Web Server. Not reply. Just to connect to the server in order to send the request. (TCP connect). > read_timeout 120 seconds - This is a timeout between Client PC --> Squid > Proxy Server and if after 120 seconds, the client PC is idle (ie. IE did not > send any request), Squid Proxy Server will drop the connection between the > Client PC and Squid Proxy Server. read_timeout is on the server connection. If the server is idle not returning a piece of response within this time Squid gives up. Default 15 minutes. It's also used as timeout while trying to send the request to the server btw.. > request_timeout 30 seconds - This is a timeout between Squid Proxy Server > --> Web Server. Squid Proxy Server able to communicate with the Web Server > upon receiving a request from the Client PC. However the Web Server is not > able to complete the request after 30 seconds, Squid Proxy Server will > response to the Client PC of connection timed out error to the Web Server. request_timeout is between client->squid. Here is two different timeouts (request_timeout and persistent_request_timeout). The first is the timeout before which the client must send the first request after establishing a TCP connection to the proxy, the second is the timeout before which the client must send the next request after the response to the previous.. > pconn_timeout 120 seconds - This is a timeout between Squid Proxy Server --> > Web Server and if after 120 seconds, Squid Proxy Server will drop the > connection between the Squid Proxy Server and Web Server. Correct. Server connections not used for more than pconn_timeout is dropped to avoid wasting server resources no longer needed. Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
[squid-users] Re: Unusual squid application
Hello, About a year ago I posted the following message to the list: * We have a very unusual squid application. We want to use a squid as a distribution point of a few very large files (~300 MB) to hundreds of computers. If the first computer requests the file, and it isn't in the disk cache, a request will be made to the origin server. That's fine. What happens if a second computer requests the same file before the first download from the origin server is completely in the squid cache? Is squid smart enough to realize that the file has already been requested from the origin server and wait, or will the second request initiate a second download from the origin server? ** I received several replies that said that squid should only forward one request to the origin server. During some recent testing, however, I was sent the following message: I now have done a controlled test and squid is definitely NOT consolidating all the requests. I started 40 clients up at nearly the same time, 4 on each of 10 machines, and I have seen as many as 27 of the same query going all the way through to the database. This is going through two squids, where one is the cache_peer parent of the other. The client programs do 5 queries that each return a 9.5MB squid object. One time I actually saw all 40 of all 5 queries get through, but that was so consistent that I hardly trust the results; the client nodes were general purpose lxplus nodes so I don't expect them to all track so close together. * We are using squid 2.5.STABLE14 on 64-bit linux. These objects are definitely cachable. What can we do to debug this? Any help/advice would be appreciated. Thanks very much, Barry
Re: [squid-users] private DNS, browsers, and Squid
For the archives: It's not DNS, it's WINS. Disabling WINS made this problem disappear. Sorry for the noise. ==ml On Thu, Apr 26, 2007 at 11:16:58AM -0400, Michael W. Lucas wrote: > Hi, > > (This might be considered tangential to this list. My apologies if > so. I've searched the squid mailing list archives, FAQ, and Google > without getting an answer, and squid-users@ is where I'll find the > people who have dealt with this before.) > > I'm running squid 2.6 stable 9, on Linux. Our clients are configured > to access the proxy via a proxy.pac file. We want our clients to > access internal Web sites directly, but access external sites only > through the proxy. > > Our clients are migrating from having full access to public DNS, to > having access to only the internal private DNS. (Not my idea, but > when global management says do it, you do it.) When we switch a > client over to the private DNS, Web surfing slows a great deal. > > Packet sniffing shows that the client is talking to the proxy, but the > client is also trying all of its DNS servers to resolve the hostname > of the Web site. With complex Web sites this can take a while -- for > example, the front page for www.cnn.com has several hostnames in it. > I suspect this is causing the very slow access. > > Do other people see this behavior? What did you do? Surely we're not > the first people to use Squid, IE, and private DNS? > > Thanks, > ==ml > > > -- > Michael W. Lucas [EMAIL PROTECTED], [EMAIL PROTECTED] > http://www.BlackHelicopters.org/~mwlucas/ > Latest book: PGP & GPG -- http://www.pgpandgpg.com > "The cloak of anonymity protects me from the nuisance of caring." -Non > Sequitur -- Michael W. Lucas[EMAIL PROTECTED], [EMAIL PROTECTED] http://www.BlackHelicopters.org/~mwlucas/ Latest book: PGP & GPG -- http://www.pgpandgpg.com "The cloak of anonymity protects me from the nuisance of caring." -Non Sequitur
Re: [squid-users] cookie blocking?
Craig Skinner wrote: On Thu, Apr 19, 2007 at 05:00:56PM +0200, Matus UHLAR - fantomas wrote: acl cookieBlockSite dstdom_regex msn\. acl cookieBlockSite dstdom_regex aol\. .. .. are you sure they have to be regexes? that's quite inefficient... Hadn't thought of that. I found regex after I done some more research following on the back of what Chris suggested. What is preferable here?: Absolutely listing google.co.uk, google.de, google.com.au,. Or a regex on google? Same for msn & others. The answer to this question depends entirely on your frame of reference. Preferable to Squid performance would be to absolutely list the domains using a dstdomain acl. Preferable to the admin might be using regex on google. Depending on how many domains you are trying to match, how many requests your cache is servicing and what kind of hardware you are using, the performance hit from using regex might be negligible. After all, by default every Squid install is using a urlregex to prevent caching of cgi-bin and any GET requests with arguments (see the cache, (or no-cache, depending on your Squid version) directive in your squid.conf). Chris
Re: [squid-users] Multiple squid servers + ldap authentication + wccp or "Super Proxy Script"
Dear All, Re correct this line : monit --> keep watching on proxy2's port 8080. If proxy1 down proxy1 will replicate with squid.conf like this --> : monit --> keep watching on proxy2's port 8080. If proxy1 down proxy2 will replicate with squid.conf like this --> Chowalit
Re: [squid-users] COSS causing squid Segment Violation on FreeBSD 6.2S
On Thu, 26 Apr 2007, Mark Powell wrote: Ok. Bear with me, this difference wasn't clear to me. So you mean the squid posix AIO code (which would interface with the FreeBSD aio module) is naive? Therefore use the Squid thread-pools based AIO instead (which will not use the FreeBSD aio module at all)? So my assumption above is correct? Ok it's in bugzilla now. Many thanks. -- Mark Powell - UNIX System Administrator - The University of Salford Information Services Division, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 4837 Fax: +44 161 295 5888 www.pgp.com for PGP key
[squid-users] private DNS, browsers, and Squid
Hi, (This might be considered tangential to this list. My apologies if so. I've searched the squid mailing list archives, FAQ, and Google without getting an answer, and squid-users@ is where I'll find the people who have dealt with this before.) I'm running squid 2.6 stable 9, on Linux. Our clients are configured to access the proxy via a proxy.pac file. We want our clients to access internal Web sites directly, but access external sites only through the proxy. Our clients are migrating from having full access to public DNS, to having access to only the internal private DNS. (Not my idea, but when global management says do it, you do it.) When we switch a client over to the private DNS, Web surfing slows a great deal. Packet sniffing shows that the client is talking to the proxy, but the client is also trying all of its DNS servers to resolve the hostname of the Web site. With complex Web sites this can take a while -- for example, the front page for www.cnn.com has several hostnames in it. I suspect this is causing the very slow access. Do other people see this behavior? What did you do? Surely we're not the first people to use Squid, IE, and private DNS? Thanks, ==ml -- Michael W. Lucas[EMAIL PROTECTED], [EMAIL PROTECTED] http://www.BlackHelicopters.org/~mwlucas/ Latest book: PGP & GPG -- http://www.pgpandgpg.com "The cloak of anonymity protects me from the nuisance of caring." -Non Sequitur
Re: [squid-users] Multiple squid servers + ldap authentication + wccp or "Super Proxy Script"
Dear All First of all, Thanks you for everyone who posted and help me. I have appropriate solution for my system. Let's me share my idea. - I have 2 Box of squid proxy : proxy1=10.1.1.11 , proxy2=10.1.1.12 - I want client to authenticate with AD account , windows 2003 server. I use squid_ldap_auth to access AD account. - I use cache_peer to load balance - I use monit for my fail over. I have problem to solve with HA because I use each server as different function i.e. proxy1 --> proxy,DHCP, proxy2 --> proxy, DNS. - DNS Alias can help me to improve fail over : "mainproxy" = 10.1.1.11, 10.1.1.12 - In client's browser, I set "manual proxy configuration" as mainproxy:8080 - In proxy1 has configuration like this : squid.conf --> squid_ldap_auth, http_port 8080 , cache_peer to proxy2 - In proxy2 : squid.conf --> squid , http_port 3128, cache_peer to proxy1 : monit --> keep watching on proxy2's port 8080. If proxy1 down proxy1 will replicate with squid.conf like this --> squid_ldap_auth , http_port 8080. If proxy2 up again proxy1 will roll-backup old config. I think I accept delay and replicate time when fail over operate. It's ok for my requirement. Thank Chowalit On 4/23/07, chowalit.lab Chowalit Lab Linux <[EMAIL PROTECTED]> wrote: Dear all, Thanks Henrik, It can help me to clear this wccp concept. I just try to implement my proxy farm with this solution - Add domain "proxytest.mycom" to point both of my proxy's ip (such as 10.1.1.1, 10.1.1.2) our DNS proxytest.mycom.IN A 10.1.1.1 IN A 10.1.1.2 - Setting up both of proxy with ldap authentication to access the same Windows 2003 Server. - Set proxy domain in client's browser as "proxytest.mycom:8080" It look fine. I can fix the twice authentication pop-up windows. Because client will choose proxy by itself (with round robbin DNS). However, I still have some problem. I want to restrict only 1 IP per 1 User authentication. The problem occur when different client access different proxy. How to fix this problem. Thanks On 4/21/07, Henrik Nordstrom <[EMAIL PROTECTED]> wrote: > ons 2007-04-18 klockan 17:14 +0700 skrev chowalit.lab Chowalit Lab > Linux: > > > As I know (Sorry if I have some miss-understanding), It's the same > > result if I implement either wccp or WPAD. There are difference in > > client setting up. Client don't need to set anything on browser but > > WPAD need. > > No, > > WCCP is transparent interception, violating RFCs etc. Here > authentication won't work. > > WPAD is automatic discovery of the proxy (or to be exact automatic > discovery of the PAC file telling the browser how it should use > proxies). As the browser knows it's using a proxy and no RFCs violated > there is no problem with proxy authentication. > > > Sorry I'm not clear. However, as Chris claimed that HA is not fix this problem. > > Please explain clearly. > > A load balanced proxy address solves a problem with basic proxy > authentication. Basic proxy authentication is performed per proxy host > name, and as a result PAC based solutions may result in multiple > authentication prompts during the browsing session, one per proxy used. > The load balancer solution where the browser always goes to the same > load balanced proxy address avoid this. > > Regards > Henrik > >
Re: [squid-users] COSS causing squid Segment Violation on FreeBSD 6.2S (store_io_coss.c)
On Thu, Apr 26, 2007, Mark Powell wrote: > It does stop the crashes, but I'm getting a lot of errors, so of which > appear to be new ones: Very eww. Now we need to figure out why the hell its spitting out those pending relocate IO errors as its probably playing havoc with things. Could you do me a favour and stuff all of this into a Bugzilla bug report? Bugzilla is linked off the main squid website front page. Adrian > > 2007/04/26 15:12:17| COSS: /dev/amrd1: Rebuild Completed > 2007/04/26 15:12:17| 81219 objects scanned, 144 objects relocated, 555 > objects fresher, 9346 objects ignored > 2007/04/26 15:12:18| Completed Validation Procedure > 2007/04/26 15:12:18| Validated 143160 Entries > 2007/04/26 15:12:18| store_swap_size = 2576724k > 2007/04/26 15:12:19| storeLateRelease: released 4996 objects > 2007/04/26 15:12:21| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:12:29| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:12:29| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:12:29| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:12:29| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:12:36| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:12:38| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:12:38| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:12:38| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:12:38| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:12:38| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:12:38| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:12:38| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:12:38| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:12:38| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:12:38| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:12:38| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:12:38| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:12:38| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:12:39| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:12:39| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:12:39| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:12:39| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:12:39| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:12:39| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:12:39| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:13:18| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:13:31| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:13:31| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:13:32| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:13:32| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:13:32| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:13:32| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:13:32| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:13:32| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:13:32| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:13:33| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:13:41| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:14:23| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:14:35| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:14:35| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:15:00| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:15:24| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:15:33| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:15:45| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:15:45| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:15:56| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:15:56| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:15:56| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:15:56| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:15:56| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:15:56| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:15:57| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:15:57| squidaio_queue_request: WARNING - Queue congestion > 2007/04/26 15:16:04| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:16:07| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:16:07| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:16:07| storeCossCompletePendingReloc: got failure (-1) > 2007/04/26 15:16:07| storeCossCompletePendingRe
Re: [squid-users] COSS causing squid Segment Violation on FreeBSD 6.2S (store_io_coss.c)
On Thu, 26 Apr 2007, Adrian Chadd wrote:
Change:
xmemcpy(p, buf, len);
to be:
if (errflag == 0) {
assert(len >= 0);
xmemcpy(p, buf, len);
}
That should stop the crashes but it won't stop the IO errors and I'm not
quite sure whether COSS will return crap to the client request or not.
COSS should at least return a read failure back up to Squid and I'm
sure things will be fine from there.
Let me know if that stops the crashes and I'll go and commit a patch.
It does stop the crashes, but I'm getting a lot of errors, so of which
appear to be new ones:
2007/04/26 15:12:17| COSS: /dev/amrd1: Rebuild Completed
2007/04/26 15:12:17| 81219 objects scanned, 144 objects relocated, 555
objects fresher, 9346 objects ignored
2007/04/26 15:12:18| Completed Validation Procedure
2007/04/26 15:12:18| Validated 143160 Entries
2007/04/26 15:12:18| store_swap_size = 2576724k
2007/04/26 15:12:19| storeLateRelease: released 4996 objects
2007/04/26 15:12:21| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:12:29| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:12:29| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:12:29| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:12:29| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:12:36| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:12:38| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:12:38| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:12:38| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:12:38| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:12:38| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:12:38| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:12:38| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:12:38| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:12:38| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:12:38| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:12:38| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:12:38| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:12:38| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:12:39| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:12:39| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:12:39| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:12:39| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:12:39| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:12:39| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:12:39| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:13:18| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:13:31| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:13:31| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:13:32| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:13:32| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:13:32| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:13:32| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:13:32| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:13:32| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:13:32| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:13:33| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:13:41| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:14:23| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:14:35| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:14:35| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:15:00| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:15:24| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:15:33| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:15:45| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:15:45| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:15:56| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:15:56| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:15:56| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:15:56| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:15:56| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:15:56| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:15:57| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:15:57| squidaio_queue_request: WARNING - Queue congestion
2007/04/26 15:16:04| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:16:07| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:16:07| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:16:07| storeCossCompletePendingReloc: got failure (-1)
2007/04/26 15:16:07| storeCossCompletePen
Re: [squid-users] COSS causing squid Segment Violation on FreeBSD 6.2S
On Thu, Apr 26, 2007, Mark Powell wrote: > On Thu, 26 Apr 2007, Adrian Chadd wrote: > > >On Thu, Apr 26, 2007, Mark Powell wrote: > > > >>BTW I'll still test your patch with the POSIX AIO code built into squid > >>(which is what you've kinda requested?) > > > >You're using aufs and COSS - so by default it'll use the Squid > >thread-pools based > >AIO. Keep using that. > > Ok. Bear with me, this difference wasn't clear to me. > So you mean the squid posix AIO code (which would interface with the > FreeBSD aio module) is naive? Therefore use the Squid thread-pools based > AIO instead (which will not use the FreeBSD aio module at all)? > > >USE_AUFSOPS=0 means "use squid thread-pools based AIO from aufs". > > That's strange, as the config.log that the port made has USE_AUFSOPS=1 in > it. Therefore I'm not using Squid thread-pools based AIO? > Is there a specific function to look for in the binary that will > determine which AIO method it is using i.e. > > # nm `which squid` | grep > > or another method to determine it? ./squid -v ; check the configure line for: --enable-coss-aio-ops Enable COSS I/O with Posix AIO (default is aufs I/O) > > >The AIO code in src/fs/aufs/* isn't posix AIO by a long shot.. > > Cheers. > > -- > Mark Powell - UNIX System Administrator - The University of Salford > Information Services Division, Clifford Whitworth Building, > Salford University, Manchester, M5 4WT, UK. > Tel: +44 161 295 4837 Fax: +44 161 295 5888 www.pgp.com for PGP key -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $25/pm entry-level bandwidth-capped VPSes available in WA -
Re: [squid-users] COSS causing squid Segment Violation on FreeBSD 6.2S
On Thu, 26 Apr 2007, Adrian Chadd wrote: On Thu, Apr 26, 2007, Mark Powell wrote: BTW I'll still test your patch with the POSIX AIO code built into squid (which is what you've kinda requested?) You're using aufs and COSS - so by default it'll use the Squid thread-pools based AIO. Keep using that. Ok. Bear with me, this difference wasn't clear to me. So you mean the squid posix AIO code (which would interface with the FreeBSD aio module) is naive? Therefore use the Squid thread-pools based AIO instead (which will not use the FreeBSD aio module at all)? USE_AUFSOPS=0 means "use squid thread-pools based AIO from aufs". That's strange, as the config.log that the port made has USE_AUFSOPS=1 in it. Therefore I'm not using Squid thread-pools based AIO? Is there a specific function to look for in the binary that will determine which AIO method it is using i.e. # nm `which squid` | grep or another method to determine it? The AIO code in src/fs/aufs/* isn't posix AIO by a long shot.. Cheers. -- Mark Powell - UNIX System Administrator - The University of Salford Information Services Division, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 4837 Fax: +44 161 295 5888 www.pgp.com for PGP key
Re: [squid-users] COSS causing squid Segment Violation on FreeBSD 6.2S
On Thu, Apr 26, 2007, Mark Powell wrote: > BTW I'll still test your patch with the POSIX AIO code built into squid > (which is what you've kinda requested?) You're using aufs and COSS - so by default it'll use the Squid thread-pools based AIO. Keep using that. USE_AUFSOPS=0 means "use squid thread-pools based AIO from aufs". The AIO code in src/fs/aufs/* isn't posix AIO by a long shot.. Adrian
Re: [squid-users] COSS causing squid Segment Violation on FreeBSD 6.2S
On Thu, 26 Apr 2007, Adrian Chadd wrote: On Thu, Apr 26, 2007, Mark Powell wrote: I'd stay away from the posix AIO code though; its reasonably naive and was meant for development. I know how to make it more "optimal" and suited to production use but it'd take time I don't have. :( Do you mean I should be using the kernel module or not? I assume that it will use the kernel code when: #define USE_AUFSOPS 0 Well, there's a build option for it; it'll set that #define appropriately. It seems like you are telling me not to use the POSIX AIO code, optionally built into squid, for production use? Therefore, I should compile with USE_AUFSOPS=0 and rely on the FreeBSD kernel posix AIO code instead? That's the behaviour that USE_AUFSOPS toggles right? Cheers. BTW I'll still test your patch with the POSIX AIO code built into squid (which is what you've kinda requested?) -- Mark Powell - UNIX System Administrator - The University of Salford Information Services Division, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 4837 Fax: +44 161 295 5888 www.pgp.com for PGP key
Re: [squid-users] COSS causing squid Segment Violation on FreeBSD 6.2S
On Thu, Apr 26, 2007, Mark Powell wrote: > >That can come after we've figured out why its crashing (ie, we can add in > >a few lines to log specific details about the failed IO request.) > > I'll add that code from the other message you sent me. Thanks. > >I'd stay away from the posix AIO code though; its reasonably naive and > >was meant for development. I know how to make it more "optimal" and suited > >to production use but it'd take time I don't have. :( > > Do you mean I should be using the kernel module or not? > I assume that it will use the kernel code when: > > #define USE_AUFSOPS 0 Well, there's a build option for it; it'll set that #define appropriately. Adrian
Re: [squid-users] COSS causing squid Segment Violation on FreeBSD 6.2S
On Thu, 26 Apr 2007, Adrian Chadd wrote: On Thu, Apr 26, 2007, Mark Powell wrote: Would using the functions from the kernel aio module make any difference? If so, how would I get the port to use them? I see you are the port maintainer too :) Maybe, although I'd like to figure out why the IO request is actually failing. That can come after we've figured out why its crashing (ie, we can add in a few lines to log specific details about the failed IO request.) I'll add that code from the other message you sent me. I'd stay away from the posix AIO code though; its reasonably naive and was meant for development. I know how to make it more "optimal" and suited to production use but it'd take time I don't have. :( Do you mean I should be using the kernel module or not? I assume that it will use the kernel code when: #define USE_AUFSOPS 0 ? And no, I'm not the port maintainer for FreeBSD's squid port anymore. Ran out of time. :) I see. I read it wrong. You created the port, but miwi is currently maintaining it. Cheers. -- Mark Powell - UNIX System Administrator - The University of Salford Information Services Division, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 4837 Fax: +44 161 295 5888 www.pgp.com for PGP key
Re: [squid-users] COSS causing squid Segment Violation on FreeBSD 6.2S
On Thu, Apr 26, 2007, Mark Powell wrote: > >#define EINVAL 22 /* Invalid argument */ > > It's the same here :) Phew. > >So there's two things; why is there a problem, and why is the object > >relocate > >code handling said error so badly? It looks like the ctrlp doesn't have > >the object offse for some reason, which is slightly annoying. > >There's onlly a couple of things that can go wrong with readp() that > >returns EINVAL.. > > What does all this mean to me? :) It means "Adrian's figuring it out." > Would using the functions from the kernel aio module make any > difference? If so, how would I get the port to use them? I see you are the > port maintainer too :) > Many thanks. Maybe, although I'd like to figure out why the IO request is actually failing. That can come after we've figured out why its crashing (ie, we can add in a few lines to log specific details about the failed IO request.) I'd stay away from the posix AIO code though; its reasonably naive and was meant for development. I know how to make it more "optimal" and suited to production use but it'd take time I don't have. :( And no, I'm not the port maintainer for FreeBSD's squid port anymore. Ran out of time. :) Adrian
Re: [squid-users] COSS causing squid Segment Violation on FreeBSD 6.2S
Change:
xmemcpy(p, buf, len);
to be:
if (errflag == 0) {
assert(len >= 0);
xmemcpy(p, buf, len);
}
That should stop the crashes but it won't stop the IO errors and I'm not
quite sure whether COSS will return crap to the client request or not.
COSS should at least return a read failure back up to Squid and I'm
sure things will be fine from there.
Let me know if that stops the crashes and I'll go and commit a patch.
Adrian
Re: [squid-users] Accelerator configuration option
tor 2007-04-26 klockan 13:31 +0200 skrev Emilio Casbas: > But in the binary directory created ../etc2/squid-NEW/bin > I can't see the RunAccel binary to start squid in accel mode. It's because it's no longer needed (in fact not needed since Squid-2.0). The RunAccel script has been considered deprecated for very many years, and with the changes in 2.6 it no longer worked at all and was removed. Just configure your squid.conf proper and start Squid, thats all. See the FAQ for details on how to configure Squid (2.6 and later) in accelerator mode. > Has it changed something from previous versions? Yes, accelerator mode has gotten a lot of improvements, and much easier to configure. > I haven't seen any related on the Changelog file The removal of RunAccel wasn't considered someting which needed to be mentioned. Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
Re: [squid-users] COSS causing squid Segment Violation on FreeBSD 6.2S
On Thu, 26 Apr 2007, Adrian Chadd wrote:
On Thu, Apr 26, 2007, Mark Powell wrote:
On Thu, 26 Apr 2007, Adrian Chadd wrote:
(gdb) frame 2
#2 0x080e729f in aioCheckCallbacks (SD=0x82bb000) at aufs/async_io.c:319
319 done_handler(ctrlp->fd, their_data, ctrlp->bufp,
(gdb) print *ctrlp
$4 = {next = 0x0, fd = 21, operation = 1, done_handler = 0,
done_handler_data = 0x0, result = {aio_return = -1, aio_errno = 22, _data
= 0x8c3ad00, data = 0x8c389c0}, len = 761, bufp = 0x8d09800 "",
free_func = 0, node = {data = 0x8c389c0, prev = 0x0, next = 0x0}}
(gdb)
.. now we're getting somewhere. I guess the stuff in the stack frame for
the COSS relocation pending completion is busted due to optimisation.
Ok, whats errno 22 on your platform? On my freebsd 6.2 box:
#define EINVAL 22 /* Invalid argument */
It's the same here :)
So there's two things; why is there a problem, and why is the object relocate
code handling said error so badly? It looks like the ctrlp doesn't have
the object offse for some reason, which is slightly annoying.
There's onlly a couple of things that can go wrong with readp() that
returns EINVAL..
What does all this mean to me? :)
Would using the functions from the kernel aio module make any
difference? If so, how would I get the port to use them? I see you are the
port maintainer too :)
Many thanks.
--
Mark Powell - UNIX System Administrator - The University of Salford
Information Services Division, Clifford Whitworth Building,
Salford University, Manchester, M5 4WT, UK.
Tel: +44 161 295 4837 Fax: +44 161 295 5888 www.pgp.com for PGP key
Re: [squid-users] Advise on timeout
tor 2007-04-26 klockan 16:46 +0800 skrev squid squid: > For example, if a client connects to an application thru squid proxy server > (ie. using session login, etc) to retrieve some information. After that, the > client is left idle. What are the timeout parameters (ie. request timeout, > read timeout, pconn_timeout, etc) on squid that will affect the session > login (ie. require client to perform login again)??? Quite likely you are looking at the wrong end for this. HTTP is stateless and does not have login sessions. And neither does Squid except in very special setups. Sessions set up in/by the application is maintained and controlled by the application, completely outside of Squid. Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
Re: [squid-users] COSS causing squid Segment Violation on FreeBSD 6.2S
On Thu, Apr 26, 2007, Mark Powell wrote:
> On Thu, 26 Apr 2007, Adrian Chadd wrote:
>
> >can you please do:
> >
> >frame 2
> >print *ctrlp ?
>
> (gdb) frame 2
> #2 0x080e729f in aioCheckCallbacks (SD=0x82bb000) at aufs/async_io.c:319
> 319 done_handler(ctrlp->fd, their_data, ctrlp->bufp,
> (gdb) print *ctrlp
> $4 = {next = 0x0, fd = 21, operation = 1, done_handler = 0,
> done_handler_data = 0x0, result = {aio_return = -1, aio_errno = 22, _data
> = 0x8c3ad00, data = 0x8c389c0}, len = 761, bufp = 0x8d09800 "",
> free_func = 0, node = {data = 0x8c389c0, prev = 0x0, next = 0x0}}
> (gdb)
.. now we're getting somewhere. I guess the stuff in the stack frame for
the COSS relocation pending completion is busted due to optimisation.
Ok, whats errno 22 on your platform? On my freebsd 6.2 box:
#define EINVAL 22 /* Invalid argument */
So there's two things; why is there a problem, and why is the object relocate
code handling said error so badly? It looks like the ctrlp doesn't have
the object offse for some reason, which is slightly annoying.
There's onlly a couple of things that can go wrong with readp() that
returns EINVAL..
Adrian
Re: [squid-users] http_port options not working
tor 2007-04-26 klockan 14:01 +0300 skrev [EMAIL PROTECTED]: > hello > i've updated 2.5 to 2.6 and the http_port options ( tproxy and transparent) > doesn't work but the vport=80 options works alone. > i set it up like this > http_port ip:8080 transparent vport=80 tproxy > > can anyone tell me why these two options do not work ? You can't run forward and reverse proxying on the same http_port. vport is a reverse proxy option. If your proxy is a forward proxy for clients to reach the internet then don't specify vport. For a transparent proxy "transparent" is all you need to specify. tproxy is a new feature, only useful if you have patched the kernel with TPROXY support and added the suitable TPROXY rules in the tproxy table.. Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
Re: [squid-users] COSS causing squid Segment Violation on FreeBSD 6.2S
On Thu, 26 Apr 2007, Adrian Chadd wrote:
can you please do:
frame 2
print *ctrlp ?
(gdb) frame 2
#2 0x080e729f in aioCheckCallbacks (SD=0x82bb000) at aufs/async_io.c:319
319 done_handler(ctrlp->fd, their_data, ctrlp->bufp,
(gdb) print *ctrlp
$4 = {next = 0x0, fd = 21, operation = 1, done_handler = 0,
done_handler_data = 0x0, result = {aio_return = -1, aio_errno = 22, _data
= 0x8c3ad00, data = 0x8c389c0}, len = 761, bufp = 0x8d09800 "",
free_func = 0, node = {data = 0x8c389c0, prev = 0x0, next = 0x0}}
(gdb)
Cheers.
Adrian
#3 0x080c97b2 in storeDirCallback () at store_dir.c:508
#4 0x0807b710 in comm_select (msec=10) at comm_generic.c:377
#5 0x080a568a in main (argc=2, argv=0xbfbfeb88) at main.c:837
(gdb) frame 1
#1 0x080ed46d in storeCossCompletePendingReloc (fd=21, my_data=0x8d39290,
buf=0x11546038 "", aio_return=290742328, aio_errno=290742328) at
coss/store_io_coss.c:1160
1160xmemcpy(p, buf, len);
(gdb) print *op
$1 = {type = COSS_OP_NONE, node = {data = 0x0, prev = 0x0, next = 0x0},
pending_op_node = {data = 0x0, prev = 0x0, next = 0x0}, sio = 0x0,
requestlen = 0, requestoffset = 0, reqdiskoffset = 0, requestbuf = 0x0,
completed = 0 '\0', pr = 0x0}
(gdb) print * ((CossPendingReloc *) pr)
oops, try changing pr for my_data; and print p, print len.
adrian
No symbol "pr" in current context.
(gdb)
Still can't look at pr :(
Cheers.
Cheers.
Adrian
--
Mark Powell - UNIX System Administrator - The University of Salford
Information Services Division, Clifford Whitworth Building,
Salford University, Manchester, M5 4WT, UK.
Tel: +44 161 295 4837 Fax: +44 161 295 5888 www.pgp.com for PGP key
--
- Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support -
- $25/pm entry-level bandwidth-capped VPSes available in WA -
--
Mark Powell - UNIX System Administrator - The University of Salford
Information Services Division, Clifford Whitworth Building,
Salford University, Manchester, M5 4WT, UK.
Tel: +44 161 295 4837 Fax: +44 161 295 5888 www.pgp.com for PGP key
Re: [squid-users] COSS causing squid Segment Violation on FreeBSD 6.2S
On Thu, Apr 26, 2007, Adrian Chadd wrote:
> > #1 0x080ed46d in storeCossCompletePendingReloc (fd=21, my_data=0x8d39290,
> > buf=0x11546038 "", aio_return=290742328, aio_errno=290742328) at
> > coss/store_io_coss.c:1160
should've looked at that. aio_return and aio_errno are strangely weird values.
r_len is assigned the value of aio_return and p is a non-NULL pointer (from your
next reply.)
> > #2 0x080e729f in aioCheckCallbacks (SD=0x82bb000) at aufs/async_io.c:319
can you please do:
frame 2
print *ctrlp ?
Adrian
> > #3 0x080c97b2 in storeDirCallback () at store_dir.c:508
> > #4 0x0807b710 in comm_select (msec=10) at comm_generic.c:377
> > #5 0x080a568a in main (argc=2, argv=0xbfbfeb88) at main.c:837
> > (gdb) frame 1
> > #1 0x080ed46d in storeCossCompletePendingReloc (fd=21, my_data=0x8d39290,
> > buf=0x11546038 "", aio_return=290742328, aio_errno=290742328) at
> > coss/store_io_coss.c:1160
> > 1160xmemcpy(p, buf, len);
> > (gdb) print *op
> > $1 = {type = COSS_OP_NONE, node = {data = 0x0, prev = 0x0, next = 0x0},
> > pending_op_node = {data = 0x0, prev = 0x0, next = 0x0}, sio = 0x0,
> > requestlen = 0, requestoffset = 0, reqdiskoffset = 0, requestbuf = 0x0,
> > completed = 0 '\0', pr = 0x0}
>
> > (gdb) print * ((CossPendingReloc *) pr)
>
> oops, try changing pr for my_data; and print p, print len.
>
>
>
> adrian
>
>
> > No symbol "pr" in current context.
> > (gdb)
> >
> > Still can't look at pr :(
> > Cheers.
> >
> > > Cheers.
> > >
> > >>
> > >>
> > >>
> > >>
> > >>Adrian
> > >>
> > >>
> > >
> > >
> >
> > --
> > Mark Powell - UNIX System Administrator - The University of Salford
> > Information Services Division, Clifford Whitworth Building,
> > Salford University, Manchester, M5 4WT, UK.
> > Tel: +44 161 295 4837 Fax: +44 161 295 5888 www.pgp.com for PGP key
>
> --
> - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support
> -
> - $25/pm entry-level bandwidth-capped VPSes available in WA -
--
- Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support -
- $25/pm entry-level bandwidth-capped VPSes available in WA -
[squid-users] Timeout explanation in layman's term
Hi, Based on a connection as follows: Client PC --> Squid Proxy Server --> Web server Is my understanding of the following timeout in layman's term correct??? If not, what should they be??? connect_timeout 120 seconds - This is a timeout between Squid Proxy Server --> Web Server and if after 120 seconds, Squid Proxy Server does not get a reply from Web Server, it will response to the Client PC of connection timed out error to the Web Server. read_timeout 120 seconds - This is a timeout between Client PC --> Squid Proxy Server and if after 120 seconds, the client PC is idle (ie. IE did not send any request), Squid Proxy Server will drop the connection between the Client PC and Squid Proxy Server. request_timeout 30 seconds - This is a timeout between Squid Proxy Server --> Web Server. Squid Proxy Server able to communicate with the Web Server upon receiving a request from the Client PC. However the Web Server is not able to complete the request after 30 seconds, Squid Proxy Server will response to the Client PC of connection timed out error to the Web Server. pconn_timeout 120 seconds - This is a timeout between Squid Proxy Server --> Web Server and if after 120 seconds, Squid Proxy Server will drop the connection between the Squid Proxy Server and Web Server. Thank you. _ Find singles online in your area with MSN Dating and Match.com! http://cp.intl.match.com/eng/msn/msnsg/wbc/wbc.html
Re: [squid-users] COSS causing squid Segment Violation on FreeBSD 6.2S
On Thu, 26 Apr 2007, Adrian Chadd wrote:
oops, try changing pr for my_data; and print p, print len.
(gdb) print * ((CossPendingReloc *) my_data)
$2 = {cs = 0x8297600, node = {data = 0x8d39290, prev = 0x0, next = 0x0},
len = 761, original_filen = 1402, new_filen = 52, ops = {head = 0x8d39410,
tail = 0x8d39410}, p = 0x11546038 "",
locked_membuf = 0x11512010}
(gdb) print p
$3 = 0x11546038 ""
(gdb) print len
No symbol "len" in current context.
(gdb)
Cheers.
--
Mark Powell - UNIX System Administrator - The University of Salford
Information Services Division, Clifford Whitworth Building,
Salford University, Manchester, M5 4WT, UK.
Tel: +44 161 295 4837 Fax: +44 161 295 5888 www.pgp.com for PGP key
Re: [squid-users] COSS causing squid Segment Violation on FreeBSD 6.2S
On Thu, Apr 26, 2007, Mark Powell wrote:
> On Thu, 26 Apr 2007, Mark Powell wrote:
> >Will try again in base gdb as that seemed to give more info? Or at least
> >the 'bt' was completely different.
>
> Back on base gdb:
>
> (gdb) run -YND
> Starting program: /usr/local/sbin/squid -YND
> warning: Unable to get location for thread creation breakpoint: generic
> error
> [New LWP 100150]
> [New Thread 0x829d000 (LWP 100151)]
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x829d000 (LWP 100199)]
> 0x88278c07 in memcpy () from /lib/libc.so.6
> (gdb) bt
> #0 0x88278c07 in memcpy () from /lib/libc.so.6
> #1 0x080ed46d in storeCossCompletePendingReloc (fd=21, my_data=0x8d39290,
> buf=0x11546038 "", aio_return=290742328, aio_errno=290742328) at
> coss/store_io_coss.c:1160
> #2 0x080e729f in aioCheckCallbacks (SD=0x82bb000) at aufs/async_io.c:319
> #3 0x080c97b2 in storeDirCallback () at store_dir.c:508
> #4 0x0807b710 in comm_select (msec=10) at comm_generic.c:377
> #5 0x080a568a in main (argc=2, argv=0xbfbfeb88) at main.c:837
> (gdb) frame 1
> #1 0x080ed46d in storeCossCompletePendingReloc (fd=21, my_data=0x8d39290,
> buf=0x11546038 "", aio_return=290742328, aio_errno=290742328) at
> coss/store_io_coss.c:1160
> 1160xmemcpy(p, buf, len);
> (gdb) print *op
> $1 = {type = COSS_OP_NONE, node = {data = 0x0, prev = 0x0, next = 0x0},
> pending_op_node = {data = 0x0, prev = 0x0, next = 0x0}, sio = 0x0,
> requestlen = 0, requestoffset = 0, reqdiskoffset = 0, requestbuf = 0x0,
> completed = 0 '\0', pr = 0x0}
> (gdb) print * ((CossPendingReloc *) pr)
oops, try changing pr for my_data; and print p, print len.
adrian
> No symbol "pr" in current context.
> (gdb)
>
> Still can't look at pr :(
> Cheers.
>
> > Cheers.
> >
> >>
> >>
> >>
> >>
> >>Adrian
> >>
> >>
> >
> >
>
> --
> Mark Powell - UNIX System Administrator - The University of Salford
> Information Services Division, Clifford Whitworth Building,
> Salford University, Manchester, M5 4WT, UK.
> Tel: +44 161 295 4837 Fax: +44 161 295 5888 www.pgp.com for PGP key
--
- Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support -
- $25/pm entry-level bandwidth-capped VPSes available in WA -
Re: [squid-users] Accelerator configuration option
On 26.04.07 13:31, Emilio Casbas wrote: > Is there any new option in the configure script to enable the accel > feature in squid? no, but there is new "vhost" option for accelerated mode > with squid-2.6.Stable12, I'm doing this compilation > ./configure --prefix=/usr/local/etc2/squid-NEW --enable-snmp > --enable-async-io --enable-referer-log --enable-useragent-log > --enable-ssl '--enable-err-languages=English Spanish' > > But in the binary directory created ../etc2/squid-NEW/bin > I can't see the RunAccel binary to start squid in accel mode. it was probably removed since acceleration is fully configurable through configuration file. RunCache and proper squid.conf should do the trick. > Has it changed something from previous versions? > I haven't seen any related on the Changelog file -- Matus UHLAR - fantomas, [EMAIL PROTECTED] ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Save the whales. Collect the whole set.
Re: [squid-users] http_port options not working
On 26.04.07 14:01, [EMAIL PROTECTED] wrote: > i've updated 2.5 to 2.6 and the http_port options ( tproxy and transparent) > doesn't work but the vport=80 options works alone. > i set it up like this > http_port ip:8080 transparent vport=80 tproxy > > can anyone tell me why these two options do not work ? did you compile in the option? support for intercepting connections must be compiled in. -- Matus UHLAR - fantomas, [EMAIL PROTECTED] ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Fighting for peace is like fucking for virginity...
Re: [squid-users] COSS causing squid Segment Violation on FreeBSD 6.2S
On Thu, 26 Apr 2007, Mark Powell wrote:
Will try again in base gdb as that seemed to give more info? Or at least the
'bt' was completely different.
Back on base gdb:
(gdb) run -YND
Starting program: /usr/local/sbin/squid -YND
warning: Unable to get location for thread creation breakpoint: generic
error
[New LWP 100150]
[New Thread 0x829d000 (LWP 100151)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x829d000 (LWP 100199)]
0x88278c07 in memcpy () from /lib/libc.so.6
(gdb) bt
#0 0x88278c07 in memcpy () from /lib/libc.so.6
#1 0x080ed46d in storeCossCompletePendingReloc (fd=21, my_data=0x8d39290, buf=0x11546038
"", aio_return=290742328, aio_errno=290742328) at coss/store_io_coss.c:1160
#2 0x080e729f in aioCheckCallbacks (SD=0x82bb000) at aufs/async_io.c:319
#3 0x080c97b2 in storeDirCallback () at store_dir.c:508
#4 0x0807b710 in comm_select (msec=10) at comm_generic.c:377
#5 0x080a568a in main (argc=2, argv=0xbfbfeb88) at main.c:837
(gdb) frame 1
#1 0x080ed46d in storeCossCompletePendingReloc (fd=21, my_data=0x8d39290, buf=0x11546038
"", aio_return=290742328, aio_errno=290742328) at coss/store_io_coss.c:1160
1160xmemcpy(p, buf, len);
(gdb) print *op
$1 = {type = COSS_OP_NONE, node = {data = 0x0, prev = 0x0, next = 0x0},
pending_op_node = {data = 0x0, prev = 0x0, next = 0x0}, sio = 0x0, requestlen =
0, requestoffset = 0, reqdiskoffset = 0, requestbuf = 0x0, completed = 0 '\0',
pr = 0x0}
(gdb) print * ((CossPendingReloc *) pr)
No symbol "pr" in current context.
(gdb)
Still can't look at pr :(
Cheers.
Cheers.
Adrian
--
Mark Powell - UNIX System Administrator - The University of Salford
Information Services Division, Clifford Whitworth Building,
Salford University, Manchester, M5 4WT, UK.
Tel: +44 161 295 4837 Fax: +44 161 295 5888 www.pgp.com for PGP key
Re: [squid-users] sslReadServer:FD XX: read failure: (104)Connectionreset by peer
tor 2007-04-26 klockan 10:44 +0200 skrev Gilles ROUTIER: > > This means a CONNECT tunnel request got aborted by the contacted server > > after the TCP connection had succeeded. > It is possible that it is this problem which slows down all the accesses > through the proxy ? Perhaps. Not the error as such, but the fact that you see a lot of them might indicate someone is abusing the CONNECT method via your proxy. Check your access.log for abnormal activity, and make sure the CONNECT method is suitably restricted to only allow known SSL ports. Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
Re: [squid-users] COSS causing squid Segment Violation on FreeBSD 6.2S
On Thu, 26 Apr 2007, Adrian Chadd wrote: On Thu, Apr 26, 2007, Mark Powell wrote: Program received signal SIGSEGV, Segmentation fault. 0x88278c07 in memcpy () from /lib/libc.so.6 (gdb) bt #0 0x88278c07 in memcpy () from /lib/libc.so.6 #1 0x08297200 in ?? () Hm, weird that the symbol doesn't show up. See if 'nm squid | grep 8297200' tells you anything. No nothing. # nm /usr/local/sbin/squid | grep 8297200 # #2 0x080e729f in aioCheckCallbacks (SD=0x82ac000) at aufs/async_io.c:319 #3 0x080c97b2 in storeDirCallback () at store_dir.c:508 #4 0x0807b710 in comm_select (msec=10) at comm_generic.c:377 #5 0x080a568a in main (argc=2, argv=0xbfbfeb9c) at main.c:837 #6 0x08057bad in _start () Will try again in base gdb as that seemed to give more info? Or at least the 'bt' was completely different. Cheers. Adrian -- Mark Powell - UNIX System Administrator - The University of Salford Information Services Division, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 4837 Fax: +44 161 295 5888 www.pgp.com for PGP key
Re: [squid-users] COSS causing squid Segment Violation on FreeBSD 6.2S
On Thu, Apr 26, 2007, Mark Powell wrote: > Program received signal SIGSEGV, Segmentation fault. > 0x88278c07 in memcpy () from /lib/libc.so.6 > (gdb) bt > #0 0x88278c07 in memcpy () from /lib/libc.so.6 > #1 0x08297200 in ?? () Hm, weird that the symbol doesn't show up. See if 'nm squid | grep 8297200' tells you anything. > #2 0x080e729f in aioCheckCallbacks (SD=0x82ac000) at aufs/async_io.c:319 > #3 0x080c97b2 in storeDirCallback () at store_dir.c:508 > #4 0x0807b710 in comm_select (msec=10) at comm_generic.c:377 > #5 0x080a568a in main (argc=2, argv=0xbfbfeb9c) at main.c:837 > #6 0x08057bad in _start () Adrian
Re: [squid-users] COSS causing squid Segment Violation on FreeBSD 6.2S
On Thu, 26 Apr 2007, Adrian Chadd wrote: On Thu, Apr 26, 2007, Mark Powell wrote: On Thu, 26 Apr 2007, Adrian Chadd wrote: On Thu, Apr 26, 2007, Mark Powell wrote: You're in the wrong frame here, but at least the BT looks right. Try "frame 1", then print *op and print *pr. hm, thats not good. how's it NULL? Oh, it hasn't been assigned yet. Try print * ((CossPendingReloc *) pr); I bet GCC has happily optimised out pr for you. This time with gdb53, it seems worse: (gdb) break 1149 Breakpoint 1 at 0x80ed3e1: file coss/store_io_coss.c, line 1149. (gdb) run -YND Starting program: /usr/local/sbin/squid -YND Program received signal SIGSEGV, Segmentation fault. 0x88278c07 in memcpy () from /lib/libc.so.6 (gdb) bt #0 0x88278c07 in memcpy () from /lib/libc.so.6 #1 0x08297200 in ?? () #2 0x080e729f in aioCheckCallbacks (SD=0x82ac000) at aufs/async_io.c:319 #3 0x080c97b2 in storeDirCallback () at store_dir.c:508 #4 0x0807b710 in comm_select (msec=10) at comm_generic.c:377 #5 0x080a568a in main (argc=2, argv=0xbfbfeb9c) at main.c:837 #6 0x08057bad in _start () (gdb) print *op No symbol "op" in current context. (gdb) frame 1 #1 0x08297200 in ?? () (gdb) print *op No symbol "op" in current context. (gdb) Cheers. -- Mark Powell - UNIX System Administrator - The University of Salford Information Services Division, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 4837 Fax: +44 161 295 5888 www.pgp.com for PGP key
Re: [squid-users] COSS causing squid Segment Violation on FreeBSD 6.2S
On Thu, Apr 26, 2007, Mark Powell wrote:
> On Thu, 26 Apr 2007, Adrian Chadd wrote:
>
> >On Thu, Apr 26, 2007, Mark Powell wrote:
> >You're in the wrong frame here, but at least the BT looks right.
> >Try "frame 1", then print *op and print *pr.
>
> Still in old gdb as it's still there (you're fast :) ):
>
> (gdb) frame 1
> #1 0x080ed46d in storeCossCompletePendingReloc (fd=21, my_data=0x8d73150,
> buf=0xfe89038 "", aio_return=266899512, aio_errno=266899512) at
> coss/store_io_coss.c:1160
> 1160xmemcpy(p, buf, len);
> (gdb) print *op
> $1 = {type = COSS_OP_NONE, node = {data = 0x0, prev = 0x0, next = 0x0},
> pending_op_node = {data = 0x0, prev = 0x0, next = 0x0}, sio = 0x0,
> requestlen = 0, requestoffset = 0, reqdiskoffset = 0, requestbuf = 0x0,
> completed = 0 '\0', pr = 0x0}
> (gdb) print *pr
> No symbol "pr" in current context.
> (gdb)
hm, thats not good. how's it NULL? Oh, it hasn't been assigned yet.
Try print * ((CossPendingReloc *) pr); I bet GCC has happily optimised out
pr for you.
Adrian
Re: [squid-users] COSS causing squid Segment Violation on FreeBSD 6.2S
On Thu, 26 Apr 2007, Adrian Chadd wrote:
On Thu, Apr 26, 2007, Mark Powell wrote:
You're in the wrong frame here, but at least the BT looks right.
Try "frame 1", then print *op and print *pr.
Still in old gdb as it's still there (you're fast :) ):
(gdb) frame 1
#1 0x080ed46d in storeCossCompletePendingReloc (fd=21, my_data=0x8d73150, buf=0xfe89038
"", aio_return=266899512, aio_errno=266899512) at coss/store_io_coss.c:1160
1160xmemcpy(p, buf, len);
(gdb) print *op
$1 = {type = COSS_OP_NONE, node = {data = 0x0, prev = 0x0, next = 0x0},
pending_op_node = {data = 0x0, prev = 0x0, next = 0x0}, sio = 0x0, requestlen =
0, requestoffset = 0, reqdiskoffset = 0, requestbuf = 0x0, completed = 0 '\0',
pr = 0x0}
(gdb) print *pr
No symbol "pr" in current context.
(gdb)
--
Mark Powell - UNIX System Administrator - The University of Salford
Information Services Division, Clifford Whitworth Building,
Salford University, Manchester, M5 4WT, UK.
Tel: +44 161 295 4837 Fax: +44 161 295 5888 www.pgp.com for PGP key
Re: [squid-users] COSS causing squid Segment Violation on FreeBSD 6.2S
On Thu, Apr 26, 2007, Mark Powell wrote: > 1 breakpoint keep y 0x080ed3e1 in storeCossCompletePendingReloc at > coss/store_io_coss.c:1149 > (gdb) run Cool. > Starting program: /usr/local/sbin/squid -YND > warning: Unable to get location for thread creation breakpoint: generic > error > [New LWP 100198] > [New Thread 0x829d000 (LWP 100151)] > > Program received signal SIGSEGV, Segmentation fault. Hm, it didn't set the breakpoint right. Try running gdb from ports (version 5.xx) rather than the base one. > [Switching to Thread 0x829d000 (LWP 100167)] > 0x88278c07 in memcpy () from /lib/libc.so.6 > (gdb) print *op > No symbol "op" in current context. > (gdb) print *pr > No symbol "pr" in current context. > (gdb) bt > #0 0x88278c07 in memcpy () from /lib/libc.so.6 > #1 0x080ed46d in storeCossCompletePendingReloc (fd=21, my_data=0x8d73150, You're in the wrong frame here, but at least the BT looks right. Try "frame 1", then print *op and print *pr. adrian
Re: [squid-users] COSS causing squid Segment Violation on FreeBSD 6.2S
On Thu, 26 Apr 2007, Adrian Chadd wrote:
On Thu, Apr 26, 2007, Mark Powell wrote:
When the caches restart, read the COSS dir and then when they finish
reading it they die with the same error again. They are both seemingly in
a loop doing this forever now. However, the other cache is still running
happily (perhaps just luck?).
Ok, the 3rd cache failed with the same error, just after sending that.
I'd try to figure out why the relocation is failing. Find the line in
store_io_coss.c which logs that, stick a break statement in gdb and run
squid inside gdb (squid -ND). Then when the thing fails you'll want to
grab some information about the operation:
print *op
print *pr
(gdb) list
1145if (errflag > 0) {
1146errno = errflag;
1147debug(79, 1) ("storeCossCompletePendingReloc: error: %s\n",
xstrerror());
1148} else {
1149debug(79, 1) ("storeCossCompletePendingReloc: got failure
(%d)\n", errflag);
1150}
1151} else {
1152debug(79, 3) ("COSS Pending Relocate: %d -> %d: completed\n",
pr->original_filen, pr->new_filen);
1153coss_stats.read.success++;
1154}
(gdb) break 1149
Breakpoint 1 at 0x80ed3e1: file coss/store_io_coss.c, line 1149.
(gdb) info breakpoints
Num Type Disp Enb AddressWhat
1 breakpoint keep y 0x080ed3e1 in storeCossCompletePendingReloc at
coss/store_io_coss.c:1149
(gdb) run
Starting program: /usr/local/sbin/squid -YND
warning: Unable to get location for thread creation breakpoint: generic error
[New LWP 100198]
[New Thread 0x829d000 (LWP 100151)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x829d000 (LWP 100167)]
0x88278c07 in memcpy () from /lib/libc.so.6
(gdb) print *op
No symbol "op" in current context.
(gdb) print *pr
No symbol "pr" in current context.
(gdb) bt
#0 0x88278c07 in memcpy () from /lib/libc.so.6
#1 0x080ed46d in storeCossCompletePendingReloc (fd=21, my_data=0x8d73150, buf=0xfe89038
"", aio_return=266899512, aio_errno=266899512) at coss/store_io_coss.c:1160
#2 0x080e729f in aioCheckCallbacks (SD=0x82bb0b0) at aufs/async_io.c:319
#3 0x080c97b2 in storeDirCallback () at store_dir.c:508
#4 0x0807b710 in comm_select (msec=10) at comm_generic.c:377
#5 0x080a568a in main (argc=2, argv=0xbfbfebb8) at main.c:837
(gdb)
What am I doing wrong with gdb?
This assumes, of course, you can handle a cache hanging in gdb and not
restarting..
I assume this is not something to do with using AIO code inside squid
rather than using the VFS_AIO module? I'm not really clear on the
difference that could make? Could you explain or point me at an
explanation?
Cheers.
Adrian
--
Mark Powell - UNIX System Administrator - The University of Salford
Information Services Division, Clifford Whitworth Building,
Salford University, Manchester, M5 4WT, UK.
Tel: +44 161 295 4837 Fax: +44 161 295 5888 www.pgp.com for PGP key
[squid-users] Accelerator configuration option
Is there any new option in the configure script to enable the accel feature in squid? with squid-2.6.Stable12, I'm doing this compilation ./configure --prefix=/usr/local/etc2/squid-NEW --enable-snmp --enable-async-io --enable-referer-log --enable-useragent-log --enable-ssl '--enable-err-languages=English Spanish' But in the binary directory created ../etc2/squid-NEW/bin I can't see the RunAccel binary to start squid in accel mode. Has it changed something from previous versions? I haven't seen any related on the Changelog file Thanks Emilio C.
Re: [squid-users] COSS causing squid Segment Violation on FreeBSD 6.2S
On Thu, Apr 26, 2007, Mark Powell wrote: > Hi, > Just in the process of putting a small percentage of our web requests > through 3 new caches to test them. However, I'm encountering SEGV > seemingly due to COSS. Two of the caches ran for about a day and then > failed e.g. > > 2007/04/26 10:39:26| storeCossCompletePendingReloc: got failure (-1) > FATAL: Received Segment Violation...dying. Hm! Well, thats a sign that the IO for that pending object relocation failed. Not a good sign. > When the caches restart, read the COSS dir and then when they finish > reading it they die with the same error again. They are both seemingly in > a loop doing this forever now. However, the other cache is still running > happily (perhaps just luck?). I'd try to figure out why the relocation is failing. Find the line in store_io_coss.c which logs that, stick a break statement in gdb and run squid inside gdb (squid -ND). Then when the thing fails you'll want to grab some information about the operation: print *op print *pr This assumes, of course, you can handle a cache hanging in gdb and not restarting.. Adrian
[squid-users] http_port options not working
hello i've updated 2.5 to 2.6 and the http_port options ( tproxy and transparent) doesn't work but the vport=80 options works alone. i set it up like this http_port ip:8080 transparent vport=80 tproxy can anyone tell me why these two options do not work ?
[squid-users] COSS causing squid Segment Violation on FreeBSD 6.2S
Hi, Just in the process of putting a small percentage of our web requests through 3 new caches to test them. However, I'm encountering SEGV seemingly due to COSS. Two of the caches ran for about a day and then failed e.g. 2007/04/26 10:39:26| storeCossCompletePendingReloc: got failure (-1) FATAL: Received Segment Violation...dying. When the caches restart, read the COSS dir and then when they finish reading it they die with the same error again. They are both seemingly in a loop doing this forever now. However, the other cache is still running happily (perhaps just luck?). COSS drives were completely blanked before use. They are all configured the same. Dell Poweredge 2650, PERC 4/DC RAID controller, 4GB RAM, 2x3.2GHz Xeon, 5x72GB 15Krpm drives: 2x72GB RAID 1 OS and everything except cache_dir 1x72GB JBODCOSS 1x72GB JBODaufs 1x72GB JBODaufs Very recent 32bit FreeBSD 6.2-STABLE #94: Fri Apr 20 11:22:18 BST 2007. Using the FreeBSD squid port which is currently 2.6-STABLE12. As both COSS and aufs are specified, I believe that both use internal AIO code in squid? Therefore the FreeBSD VFS_AIO module is not required? cache_dir coss /dev/amrd1 65000 max-size=16384 block-size=4096 cache_dir aufs /2 56000 16 256 cache_dir aufs /3 56000 16 256 I changed squid to libthr library using /etc/libmap.conf: # ldd /usr/local/sbin/squid /usr/local/sbin/squid: libcrypt.so.3 => /lib/libcrypt.so.3 (0x88158000) libm.so.4 => /lib/libm.so.4 (0x88171000) libpthread.so.2 => /usr/lib/libthr.so.2 (0x88187000) libc.so.6 => /lib/libc.so.6 (0x8819a000) I always map to libthr as in the past it has been more stable. Well libpthread causes crashes with MySQL where libthr is ok. A quick look at the squid.core gives (I'm no debugging expert :( ): (gdb) where #0 0x88264bb7 in memset () from /lib/libc.so.6 #1 0x4144 in ?? () #2 0x8826194e in calloc () from /lib/libc.so.6 #3 0x080fa334 in xcalloc (n=28, sz=2284278208) at util.c:561 #4 0x080e7a7d in storeCossDirWriteCleanStart (sd=0x82a4000) at coss/store_dir_coss.c:409 #5 0x080c94b5 in storeDirWriteCleanLogs (reopen=0) at store_dir.c:426 #6 0x080cc4dc in death (sig=0) at tools.c:314 #7 0xbfbfff94 in ?? () #8 0x000b in ?? () #9 0x000c in ?? () #10 0xbfbfe610 in ?? () #11 0x08047ffc in ?? () #12 0x080cc495 in uniqueHostname () at tools.c:556 #13 0x080e729f in aioCheckCallbacks (SD=0x82a40b0) at aufs/async_io.c:319 #14 0x080c97b2 in storeDirCallback () at store_dir.c:508 #15 0x0807b710 in comm_select (msec=10) at comm_generic.c:377 #16 0x080a568a in main (argc=2, argv=0xbfbfeea4) at main.c:837 Just tried it with libpthread and got the same error once it had read the COSS dir. The debug gives: (gdb) where #0 0x881a5abf in pthread_testcancel () from /lib/libpthread.so.2 #1 0x8819df3b in pthread_mutexattr_init () from /lib/libpthread.so.2 #2 0x882a3450 in ?? () Any ideas? Or can I find more info to help nail this? Many thanks for any pointers. -- Mark Powell - UNIX System Administrator - The University of Salford Information Services Division, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 4837 Fax: +44 161 295 5888 www.pgp.com for PGP key
Re: [squid-users] Trouble understanding why something is RELEASE'ed from the cache
On 24.04.07 20:41, Donald Thompson wrote: > I have a 30 gigabyte cache, and on a normal day the cache sees less than > a gigabyte of traffic. I've configured the cache to have a maximum > object size of 2 gigabytes. But I'm seeing large files in my store.log > being with the RELEASE tag, basically the same moment they're > successfully logged into the access.log. maybe they are not cacheable. Did you check for their cacheability? > The only time I see my cache > able to store these large files, is when the cache file space is not at > full capacity. I'm using LRU. 'heap lru' is faster. > Shouldn't squid be cycling out older data rather than the fresh files it > just pulled in assuming they meet the minimum and maximum size for caching? Yes, it should... -- Matus UHLAR - fantomas, [EMAIL PROTECTED] ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. It's now safe to throw off your computer.
[squid-users] Advise on timeout
Hi, There are various timeout parameters in squid and I would like to know which are the timeout that will affect a client connection to the squid proxy server. That is to say, the connection between the client to squid proxy server and squid proxy server to the apps server will be dropped. For example, if a client connects to an application thru squid proxy server (ie. using session login, etc) to retrieve some information. After that, the client is left idle. What are the timeout parameters (ie. request timeout, read timeout, pconn_timeout, etc) on squid that will affect the session login (ie. require client to perform login again)??? Thank you. _ Find singles online in your area with MSN Dating and Match.com! http://cp.intl.match.com/eng/msn/msnsg/wbc/wbc.html
Re: [squid-users] sslReadServer:FD XX: read failure: (104)Connectionreset by peer
I have all the time in my file cache.log : 2007/04/25 15:28:39| sslReadServer: FD 67: read failure: (104) Connection reset by peer This means a CONNECT tunnel request got aborted by the contacted server after the TCP connection had succeeded. It is possible that it is this problem which slows down all the accesses through the proxy ? Thankks Gil -- "Le contenu de ce courriel et ses éventuelles pièces jointes sont confidentiels. Ils s’adressent exclusivement à la personne destinataire. Si cet envoi ne vous est pas destiné, ou si vous l’avez reçu par erreur,et afin de ne pas violer le secret des correspondances, vous ne devez pas le transmettre à d’autres personnes ni le reproduire. Merci de le renvoyer à l’émetteur et de le détruire. Attention : L’Organisme de l'émetteur du message ne pourra être tenu responsable de l’altération du présent courriel. Il appartient au destinataire de vérifier que les messages et pièces jointes reçus ne contiennent pas de virus. Les opinions contenues dans ce courriel et ses éventuelles pièces jointes sont celles de l’émetteur. Elles ne reflètent pas la position de l’Organisme sauf s’il en est disposé autrement dans le présent courriel."
Re: [squid-users] download restrictions on clients
On 4/26/07, squid learner <[EMAIL PROTECTED]> wrote: Please if any one have good to use documentation I want that every client must be restrected for one download at a time only Here i have 25 clients with 2 512 but if any one client start 4-5 download other have problem in browsing and speed comes down You can set bandwidth limits (see delay pools) to an extent. It is however unfeasible to limit your users' parallel downloads as it's practically impossible to reliably distinguish a download from a "normal" page access. -- /kinkie
[squid-users] download restrictions on clients
Please if any one have good to use documentation I want that every client must be restrected for one download at a time only Here i have 25 clients with 2 512 but if any one client start 4-5 download other have problem in browsing and speed comes down thankyou __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
