Indexing: Errors in access_log

[hkphooey]

Hi.

I've just upgraded from 10 to 11, which I'm running on Centos 4.4. Everything seemed pretty smooth and users have generally been happy with the transition.

However I'm getting a lot of error messages in my /var/log/httpd/access_log. Here's the output from logwatch (with linebreaks added so that it wraps):

A total of 14719 unidentified 'other' records logged with response code(s)
GET /sis/indexer?fn=add&uid=b9200000fc786f44-722.86.121.302
&pdref=000104135ba8e5a5&dref=000131a2ee93a101
&indexid=e34479cb-44f687cf-4598af47-16cf
&flags=seen,unflagged,unanswered,undeleted,undraft,unlabel1,unlabel2,unlabel3,
unlabel4,unlabel5,unlabel6,unlabel7,unlabel8,unjunk,unnonjunk,unforwarded
HTTP/1.1 with response code(s) 2 204 responses
POST /sis/indexer?fn=index&uid=29200000fc786f44-722.86.121.302
&pdref=0001000216b6b1dd&dref=00017893d271803e
&indexid=e34479cb-44f687cf-4598ada6-412
&flags=seen,unflagged,unanswered,undeleted,undraft,unlabel1,unlabel2,unlabel3,
unlabel4,unlabel5,unlabel6,unlabel7,unlabel8,unjunk,unnonjunk,unforwarded
HTTP/1.1 with response code(s) 2 200 responses

The initial indexing was about 7000 messages, so I'm guessing that there are two entries per message. The messages are still appearing, so it wasn't just a one-off thing.

Any clues as to what is happening, whether or not this is an issue, or how I can stop the messages appearing?

Happy New Year!

[florian]

The behaviour seems completely normal. 20x access codes generally mean successful http requests. Also, the Indexer and Search services are made available to the rest of the system through http as a web service, therefore it is normal that those requests go to http and apache.

What you'll need to do is either modify your logging behaviour in your apache configuration or modify logwatch to ignore those messages, otherwise you'll see more of them as new messages arrive in people's mailboxes and are getting indexed.

Florian.

[hkphooey]

OK, I couldn't stand the 2Mb emails I was getting every day, so I finally got around to fixing this.

Turns out that the version of logwatch installed on Centos 4.4 is an old one (5.4), so it incorrectly identifies these requests as bad. I tried editing the ignore.conf file, but this version doesn't use that, so I upgraded to the latest version of logwatch:
rpm -e logwatch
rpm -ihv logwatch.latest.version.rpm

And all is good. No need to even alter the config files. Hope this helps someone.

[hughesjr]

I guess being that I am the CentOS-4.4 lead developer and that I use scalix, I should figure out how to fix this

I will see if I can't come up with a way to not show the good responses.

BTW ... the version of logwatch is not an old one when compared to RHEL ... it is the same one. I would NOT recommend anyone upgrade to a version of logwatch that is non enterprise ....

[hughesjr]

http://rhn.redhat.com/errata/RHBA-2006-0631.html

That supposedly fixes the status < 400 showing up ... it did cut down the amount, but did not fix all of the < 400 codes showing up as errors.

Here is the RH bugzilla entry that addresses httpd codes showing up:

https://bugzilla.redhat.com/bugzilla/sh ... ?id=178387

If you edit the file:

/etc/log.d/conf/services/httpd.conf

and set the variable:

$HTTP_IGNORE_ERROR_HACKS = 0

to

$HTTP_IGNORE_ERROR_HACKS = 1

then it seems to block the < 400 (and > 400 too) errors from showing up.

The version of logwatch in the CentOS fasttrack repository is the one that corresponds to the above RH bug fix. See this link to get configure the fasttrack repo:

http://wiki.centos.org/Repositories

[hughesjr]

it also just happens to be that the newer logwatch RPMS are only text files (perl) and you can probably install one from FC or elsewhere and it "should" work if the perl versions are not too divergent.