Re: [squid-users] storeClientReadHeader: no URL!
On 06/04/2011 22:38, Tory M Blue wrote: how about trying to dump the http headers to see what is going on there? deubg setions 11 23 55 is this a forward or reverse proxy? can it be that some server is sending a 300 status code to squid but without URL? Eliezer Nope clean install on 2.7STABLE9 and the first hour or so no error messages but now I'm getting them 2011/04/06 12:33:46| storeClientReadHeader: no URL! 2011/04/06 12:34:02| storeClientReadHeader: no URL! 2011/04/06 12:34:12| storeClientReadHeader: no URL! 2011/04/06 12:34:12| storeClientReadHeader: no URL! 2011/04/06 12:34:33| storeClientReadHeader: no URL! 2011/04/06 12:34:34| storeClientReadHeader: no URL! 2011/04/06 12:34:35| storeClientReadHeader: no URL! 2011/04/06 12:34:37| storeClientReadHeader: no URL! 2011/04/06 12:35:03| storeClientReadHeader: no URL! 2011/04/06 12:35:03| storeClientReadHeader: no URL! 2011/04/06 12:35:40| storeClientReadHeader: no URL! 2011/04/06 12:35:50| storeClientReadHeader: no URL! 2011/04/06 12:35:52| storeClientReadHeader: no URL! 2011/04/06 12:36:17| storeClientReadHeader: no URL! 2011/04/06 12:36:18| storeClientReadHeader: no URL! 2011/04/06 12:36:18| storeClientReadHeader: no URL! Since this was a absolutely fresh install, clean cache directory, this is either a request coming in or something. We did make some changes with headers, but since this was a clean install, can't believe it's the apache changes from the app servers. Very strange, would like to identify Tory
Re: [squid-users] storeClientReadHeader: no URL!
On Tue, Apr 5, 2011 at 12:28 PM, Tory M Blue wrote: > On Tue, Apr 5, 2011 at 12:32 AM, Amos Jeffries wrote: >> On 05/04/11 17:09, Tory M Blue wrote: Problem is that this is happening in every cache server. Even if I start clean I get these. What debug level/numbers can I use to track this down? This happens constantly, so ya as you said something is going on but it doesn't appear to be, someone mucking with the cache or other odity, since it happens with new fresh squid instances and is happening a lot.. Thanks Amos Tory >>> >>> hmmm >>> >>> 746665-2011/04/04 21:57:05| storeClientReadHeader: swapin MD5 mismatch >>> 746729-2011/04/04 21:57:05| 1949E8301BB74F8CD2E16773A23B8D26 >>> 746784-2011/04/04 21:57:05| 3BD0B17768C3A6F6A85A4C4684A311C0 >>> >>> >>> That has to be the cause, but it makes no sense. Why would they be >>> there with a fresh cache install, on 3 different servers.. >> >> >> What OS filesystem is this using? >> does it do any sort of fancy file de-duplication or compression underneath >> Squid? >> is there any system process which might do that sort of thing? >> >> Can you try 2.7.STABLE9? >> >> If this is ufs/aufs/diskd, do you have the ufsdump tool installed with >> Squid? that can dump the content of cache files for manual checking. > Nope clean install on 2.7STABLE9 and the first hour or so no error messages but now I'm getting them 2011/04/06 12:33:46| storeClientReadHeader: no URL! 2011/04/06 12:34:02| storeClientReadHeader: no URL! 2011/04/06 12:34:12| storeClientReadHeader: no URL! 2011/04/06 12:34:12| storeClientReadHeader: no URL! 2011/04/06 12:34:33| storeClientReadHeader: no URL! 2011/04/06 12:34:34| storeClientReadHeader: no URL! 2011/04/06 12:34:35| storeClientReadHeader: no URL! 2011/04/06 12:34:37| storeClientReadHeader: no URL! 2011/04/06 12:35:03| storeClientReadHeader: no URL! 2011/04/06 12:35:03| storeClientReadHeader: no URL! 2011/04/06 12:35:40| storeClientReadHeader: no URL! 2011/04/06 12:35:50| storeClientReadHeader: no URL! 2011/04/06 12:35:52| storeClientReadHeader: no URL! 2011/04/06 12:36:17| storeClientReadHeader: no URL! 2011/04/06 12:36:18| storeClientReadHeader: no URL! 2011/04/06 12:36:18| storeClientReadHeader: no URL! Since this was a absolutely fresh install, clean cache directory, this is either a request coming in or something. We did make some changes with headers, but since this was a clean install, can't believe it's the apache changes from the app servers. Very strange, would like to identify Tory
Re: [squid-users] storeClientReadHeader: no URL!
On Tue, Apr 5, 2011 at 12:32 AM, Amos Jeffries wrote: > On 05/04/11 17:09, Tory M Blue wrote: >>> >>> Problem is that this is happening in every cache server. Even if I >>> start clean I get these. What debug level/numbers can I use to track >>> this down? This happens constantly, so ya as you said something is >>> going on but it doesn't appear to be, someone mucking with the cache >>> or other odity, since it happens with new fresh squid instances and is >>> happening a lot.. >>> >>> Thanks Amos >>> >>> Tory >>> >> >> hmmm >> >> 746665-2011/04/04 21:57:05| storeClientReadHeader: swapin MD5 mismatch >> 746729-2011/04/04 21:57:05| 1949E8301BB74F8CD2E16773A23B8D26 >> 746784-2011/04/04 21:57:05| 3BD0B17768C3A6F6A85A4C4684A311C0 >> >> >> That has to be the cause, but it makes no sense. Why would they be >> there with a fresh cache install, on 3 different servers.. > > > What OS filesystem is this using? > does it do any sort of fancy file de-duplication or compression underneath > Squid? > is there any system process which might do that sort of thing? > > Can you try 2.7.STABLE9? > > If this is ufs/aufs/diskd, do you have the ufsdump tool installed with > Squid? that can dump the content of cache files for manual checking. Nothing special, all using aufs, some on reiserfs others on ext4. I have stable9 built so I can push that to a server and see if I see the same thing. I'll also grab ufsdump and see what I can do. I tried diskd but it failed horribly, so back to aufs :) Update shortly Tory
Re: [squid-users] storeClientReadHeader: no URL!
On 05/04/11 17:09, Tory M Blue wrote: Problem is that this is happening in every cache server. Even if I start clean I get these. What debug level/numbers can I use to track this down? This happens constantly, so ya as you said something is going on but it doesn't appear to be, someone mucking with the cache or other odity, since it happens with new fresh squid instances and is happening a lot.. Thanks Amos Tory hmmm 746665-2011/04/04 21:57:05| storeClientReadHeader: swapin MD5 mismatch 746729-2011/04/04 21:57:05| 1949E8301BB74F8CD2E16773A23B8D26 746784-2011/04/04 21:57:05| 3BD0B17768C3A6F6A85A4C4684A311C0 That has to be the cause, but it makes no sense. Why would they be there with a fresh cache install, on 3 different servers.. What OS filesystem is this using? does it do any sort of fancy file de-duplication or compression underneath Squid? is there any system process which might do that sort of thing? Can you try 2.7.STABLE9? If this is ufs/aufs/diskd, do you have the ufsdump tool installed with Squid? that can dump the content of cache files for manual checking. Amos -- Please be using Current Stable Squid 2.7.STABLE9 or 3.1.12 Beta testers wanted for 3.2.0.6
Re: [squid-users] storeClientReadHeader: no URL!
> Problem is that this is happening in every cache server. Even if I > start clean I get these. What debug level/numbers can I use to track > this down? This happens constantly, so ya as you said something is > going on but it doesn't appear to be, someone mucking with the cache > or other odity, since it happens with new fresh squid instances and is > happening a lot.. > > Thanks Amos > > Tory > hmmm 746665-2011/04/04 21:57:05| storeClientReadHeader: swapin MD5 mismatch 746729-2011/04/04 21:57:05| 1949E8301BB74F8CD2E16773A23B8D26 746784-2011/04/04 21:57:05| 3BD0B17768C3A6F6A85A4C4684A311C0 That has to be the cause, but it makes no sense. Why would they be there with a fresh cache install, on 3 different servers.. Thanks Amos Tory
Re: [squid-users] storeClientReadHeader: no URL!
On Mon, Apr 4, 2011 at 4:10 PM, Amos Jeffries wrote: > On Mon, 4 Apr 2011 10:24:14 -0700, Tory M Blue wrote: >> >> What does " storeClientReadHeader: no URL!" mean, what is it telling me >> >> I'm seeing this quite a bit and can't find with normal searches what >> this means, what is causing this.. >> >> Thanks >> >> Tory >> >> 2011/04/04 10:18:45| storeClientReadHeader: no URL! >> 2011/04/04 10:18:49| storeClientReadHeader: no URL! >> 2011/04/04 10:18:49| storeClientReadHeader: no URL! >> 2011/04/04 10:18:51| /cache/0D/19/000D1950 >> >> Squid Cache: Version 2.7.STABLE7 >> Fedora 12 > > Somehow you have an object in your cache which has no URL. > > Considering that the URL is required in order to create the cache > filename/number that is a sign that someone has been tampering with the > cache or something really nasty has gone wrong. > > Squid will continue to work fine, treating these as corrupt and fetching new > content for whatever URL they would otherwise have provided. It should also > erase them to prevent future problems. So it is not something to be overly > worried about, but may be worthwhile tracking down what is happening to the > cache. > > Amos Problem is that this is happening in every cache server. Even if I start clean I get these. What debug level/numbers can I use to track this down? This happens constantly, so ya as you said something is going on but it doesn't appear to be, someone mucking with the cache or other odity, since it happens with new fresh squid instances and is happening a lot.. Thanks Amos Tory
Re: [squid-users] storeClientReadHeader: no URL!
On Mon, 4 Apr 2011 10:24:14 -0700, Tory M Blue wrote: What does " storeClientReadHeader: no URL!" mean, what is it telling me I'm seeing this quite a bit and can't find with normal searches what this means, what is causing this.. Thanks Tory 2011/04/04 10:18:45| storeClientReadHeader: no URL! 2011/04/04 10:18:49| storeClientReadHeader: no URL! 2011/04/04 10:18:49| storeClientReadHeader: no URL! 2011/04/04 10:18:49| storeClientReadHeader: no URL! 2011/04/04 10:18:51| storeClientReadHeader: no URL! 2011/04/04 10:18:51| storeAufsOpenDone: (2) No such file or directory 2011/04/04 10:18:51|/cache/0D/19/000D1950 Squid Cache: Version 2.7.STABLE7 Fedora 12 Somehow you have an object in your cache which has no URL. Considering that the URL is required in order to create the cache filename/number that is a sign that someone has been tampering with the cache or something really nasty has gone wrong. Squid will continue to work fine, treating these as corrupt and fetching new content for whatever URL they would otherwise have provided. It should also erase them to prevent future problems. So it is not something to be overly worried about, but may be worthwhile tracking down what is happening to the cache. Amos
