Posts Tagged ‘options’

Fixing 127.0.0.1 – – “OPTIONS * HTTP/1.0” 200 136 “-” “Apache (internal dummy connection)” / ::1 – – [-.. :- .. +0200] “OPTIONS * HTTP/1.0” 200 Apache access.log junk records

Saturday, December 1st, 2012

If you're on Debian Linux and you played with mpm_prefork_module MinSpareServers and MaxSpareServers directives, it is very likely your access.log apache log ends up with a plenty of junk messages like:

127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"

It was quite unexplainable to me what is causing all this errors. I've seen plenty of posts on the Internet discussing on that but most are somehow outdated and suggested solutions to the weird logged  internal dummy connection messages did not work well for me.

I would not care so much about the message, only if it was not creating a lot of bulk records in my logs which when later are compressed just take up useless disk space and besides that it makes following the Apache log with:

# tail -f  /var/log/apache2/access.log

hardly readable.

  • One of the many solutions and posts suggested a solution with mod_rewrite rules. It claims adding the rules to .htaccess or to apache config files (vhost confs whether multiple vhosts domains):

RewriteCond %{HTTP_USER_AGENT} ^.*internal\ dummy\ connection.*$ [NC]
RewriteRule .* – [F,L]

The full article you read the whole here.
I've tested this rules, and thought I might be doing something wrong this proved unworking for me. Besides that even if it worked I would not imply such fix, as it will be creating a useless extra load on each incoming Apache connection.

 

As a second solution as I found on stackoverflow's website is to add in apache / vhost configs:

<Limit OPTIONS Order allow,deny Deny from all </Limit> I tested this as well but it does not work either. I've seen a bunch of other posts and none seemed to be working, until I finally came across Linux Guru's blog which was discussing a similar issue suggesting a fix. The post is discussing on Apache access.log being filled with messages like: ::1 - - [13/Mar/2008:09:05:13 +0200] "OPTIONS * HTTP/1.0" 200 Which are almost the same except, the 127.0.0.1 is the IPv6's equivalent ::1. The blog provided solution is to use: SetEnvIf Remote_Addr "::1" dontlog CustomLog /var/log/apache2/access.log combined env=!dontlog What this makes is to completely clear up all occurances of ::1 in /var/log/apache2/access.log. Once it uses Apache Internal directive SetEnvIf Remote_Addr "::1" dontlog to "bind" ::1 to dontlog variable and then after the usual Log location definition – e.g. – CustomLog /var/log/apache2/access.log combined it instructs the environment not to log dontlog variable matches, i.e. env=!dontlog

Following he same logic to get rid of the so annoying:

127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"

I used as a solution adding:

SetEnvIf Remote_Addr "127.0.0.1" dontlog
CustomLog /var/log/apache2/access.log combined env=!dontlog

to /etc/apache2/sites-available/000-default (the default virtualhost), with the CustomLog directive, for more domains and more CustomLog VirtualHost definitions it might be necessary to add it to all Vhosts too.

This solution to Request of the Server to itself is also found on Apache's wiki  check what httpd wiki here.

As I've read further it appeared the same Internal Dummy Connection error is experienced on CentOS Linux too and the SetEnvIf method works there too well you can read post here.

Another possible solution though this didn't work for me is to just play with the settings of MinSpareServers and MaxSpareServers in apache2.conf (or httpd.conf on RedHats and BSD).

There is plenty of things written on the problem and it is really confusing to read about it, as most of the people writing about it were looking for the quick fix and thus just dropped few lines on what worked for them without much details on exact OS en Apache version.

The reason why:
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)" appear in log is due to the fact in Apache 2.x series Apache developers change the the Parent Apache controlling process to send periodic requests to its waiting idling childs, just to make the childs are still alive, this is done somehow in the very inefficient method IMHO by sending those dummy connection requests.

Maybe better and more thoroughful explanation on What is the Dummy Internal Connection and what causes it is on another Bulgarian Fellow Valery Dachev you can read his explan.

On a couple of occasions, I've experienced a very high server loads like load avarage of 180etc. , I have some suspicion that this super high loads are caused somehow by the Internal Dummy Connection thing too, though I'm not sure if my assumptions are correct. It could be I have messed up something with MaxSpareServers / MinSpareServers too, or just the hardware on the host is unable to process a sudden traffic peaks. I've red online other people who complain of similar overloads and complaininng about the Internal Dummy Connection too. But as long as my little research go, I couldn't find noone knowing anything on that. If some of the readers of this post has an idea on that please drop a comment !

Well that's it hope my little blog post sheds some more light on the topic, and lets hope in future Apache versions developers will come with less resource hungry method to do internal dummy checks for exmpl. by sending a SIGUSR signal.

A few helpful Bind DNS server configuration options

Wednesday, March 17th, 2010

It’s quite useful in bind to have the following configurations options in either named.conf options {} configuration block or (in case if on Debian Linux in named.conf.options.
Please edit your required file respectively and find the options {} directive and set within the options {} block the following:


zone-statistics yes;
notify yes;
transfer-format many-answers;

Here I have to clarify that the zone-statistics directive instructs the server to collect statistical data about all zone files, this statistics can later be accessed via the:
rndc stats command.

transfer-format many-answers is actually a default directive since bind 9 and you might even like to skip that one if on bind version 9 or 9+
notify yes; – will instruct the nameserver to replicate change in zone files to a seconday configured name server.

Another really vital thing in my view is to enable Bind DNS server logging into file.

In order to do that put in named.conf:

logging {
channel _default_log {
file "/var/log/named/named.log";
severity debug;
print-time yes;
};
category default {
_default_log;
};

Note that it’s required to create the log file with proper permissions as in the location where specified in the above configuration in this case /var/log/named/named.log :


debian-server# mkdir -p /var/log/named
debian-server# touch /var/log/named/named.log
debian-server# chown -R bind:bind /var/log/named/

In this case I change the directory and file to be owned by the bind user and group, however on different linux distribution like Redhat the user could be different like on Redhat the user is usually named.
To find the correct user permissions check the user with which the Bind server is running using a simple:

debian-server# ps axu|grep -i bind
or
# ps axu|grep -i named