Mint Forum

After email discussions with my ISP’s support staff, we still have not been able to figure out why Mint continues to skip about 20% of the visits to our site. See this earlier thread

After staring long minutes at Mint’s Debugger output I noticed that the When field and the Local field are way off in the non-tabulated entries, and that the Cookies field is always empty in the non-tabulated entries.

An example:

Tabulated entry

When 09:33:04 2007.09.13 ~0s

Local 09:33:05 2007.09.13 ~1s

Cookies MintAccepts Cookies (etc.)

Non-tabulated entry with RED background

When 09:33:08 2007.09.13

Local 06:00:00 1969.12.31 ~13769d

Cookies [blank]

What might cause this?

I re-uploaded the script.js file but it was exactly the same amount of bytes so it probably wasn’t partially uploaded before.

I also followed your suggestion and added the code to disable mod_security to the .htaccess file in the Mint directory. I also tried the code in the main directory’s htaccess file just for kicks. Neither had any impact.

The errors “in red” in the debugger continue and the approximate 20% discrepancy between Google Analytics and Mint remains the same (Google is 20% higher than Mint). This is particularly ironic since you may remember that months ago I had a similar but reverese discrepancy (MInt was 20% higher than Google) until I followed your suggestion to add Google’s javascript to Mint’s prepend script. Then, for several months Google Analytics and Mint goose-stepped to the same beat with a 1% variation.

Do you have any more suggestions how I can debug this problem?

Thanks.

I haven’t used the User Agent pane in months because it basically showed the same figures fairly consistently. I just re-installed it and I’ll let it go a few days, then compare it to some older screenshots I made.

I still think the tweaks to mySQL and the server by the support team at my ISP somehow affected Mint because I noticed the change in Mint immediately afterward.

I also just checked to see if they made any changes to the httpd.conf file but except for domain accounts I added in the past week, and Max Clients which they raised from 150 to 250, everything is identical. They didn’t touch any of the other variables related to Max Clients.

I have full access to all the logs — I just have to find the PHP error log. I looked in /var/log and in the php directory and even used phpinfo() but the latter only says error_log values are “error_log”.

Gimme a hint. Where is that puppy supposed to be?

Apparently PHP is set up on my server to send its errors to the main Apache system log rather than a separate log file. I found a few errors relating to Mint but certainly not enough to account for 15-20% and they all seemed to refer to incorrect links—Mint apparently generated an error message to the log file because the page requested didn’t exist. Again, there were only a few dozen of these out of 140,000 log entries for a part of today.

After a few hours the User Agents pane is stabilizing around 72% IE, 19% Firefox, 6% Safari and the rest at 3%. This looks close to the numbers we had a few months ago.

What makes this frustrating is seeing those big red blocks and the missing data in the Mint debugger window yet there’s no apparent solution. I agree with your logic about the browser but the only browser version that is close to the discrepancy percentage is Firefox 2.0.0.7, which is around 12% after a few hours of User Agent tracking. But it was released a few days ago, well after this problem began (around Aug 31). All of Firefox is closer, at around 19%. What might cause all Firefox browsers to globally interact badly with Mint?

@SDJL

Thanks for the suggestion. I asked a senior support person at my ISP about the resolv.conf change and he replied:

Nameservers are simply servers running a DNS service (named) that performs lookup requests for servers. Your server runs the same DNS server (named) as most other nameservers and it should be returning the same DNS records. Why do we set it to localhost? Because your server runs named locally and it also is the authoritative nameserver for your domains. That means when changes are made to your domain’s DNS Zones, they are made at the local server and then propagate to other nameservers slowly over time.

Here is an example of a situation where the nameserver is set to something other than localhost which will reveal why “nameserver 127.0.0.1” is most efficient:

• You decide one day to purchase a new dedicated IP and switch forkmedia.com to that IP address.
• The DNS Zone for forkmedia.com is updated on the authoritative nameservers (your dedicated server) so that the domains are set to start resolving to the new IP address.
• Your dedicated server is using a nameserver located elsewhere on the network or even in another part of the world. Because of this, forkmedia.com will continue resolving to the old IP address on the server for 4 hours or more because of DNS caching and propagation times. Only when the server it is using for lookups has its cached entry for forkmedia.com expire and it performs a new lookup request will the IP address change when looked up locally.
• Contrastingly, if 127.0.0.1 were the first resolver in /etc/resolv.conf, a lookup for forkmedia.com would reveal the new IP address immediately.

If you really don’t like seeing 127.0.0.1 in /etc/resolv.conf - The following would be exactly the same:

nameserver [my nameserver IP in format 000.000.000.001] nameserver 000.000.000.002

That’s because those IPs are both on your server and so they would essentially send the lookup request to the same place that 127.0.0.1 would - Technically however 127.0.0.1 would still be preferred because if (hypothetically) all the IPs on your server were changed the above configuration would stop working, however a configuration using 127.0.0.1 would always work.

In the end, you can use whatever nameservers you want, regardless of where it is located, as long as it is responding to DNS lookup requests. You just have to worry about the stability of that nameserver and deal with a delay on the local server after you make any changes to your DNS zones. If you want to remove 127.0.0.1 from /etc/resolv.conf and test it with other nameservers that shouldn’t do any harm as long as the nameservers you use are responding to lookup requests.

end quote

As a side result of the 127.0.0.1 addition to my resolv file, I also noticed the Google Analytics “Network Locations” pane is now showing 90% of my visits coming from my site, rather than individual IPs.

I haven’t commented out the 127.0.0.1 from the resolv file yet as I asked for some clarifications from my ISP.

I also noticed the difference between GA and Mint has creeped up from 15-20% to 20-25% difference in the past few days…