Login to download the latest version of Mint and your favorite Pepper, purchase additional licenses, or post in the Forum. Don't have an account? Create one!

In Partnership with Media Temple

Mint Forum

Details on the problem

Not sure if this is still common issue but I just ran into the issue on a client’s mint installation and while the problem was easily solvable, the solution and explanation was a bit elusive. After matching up the entries in Mint with the actual request in the Apache logs, I did a bit of investigation and figured out what was happening so I thought I’d post here:

Tl;dr: Change the IP field type to signed INT on 64-bit systems.

Let’s say you get a visit from IP address On a 32 bit system, when you run ip2long on the address you get the value -780539522. When you insert that value into a MySQL field with an unsigned INT type, there are no issues since that value is within the range that field can handle (-2147483648 to 2147483647).

Now let’s say you or your host make the move to a 64-bit system. The same IP passed through the ip2long function becomes 3514427774. When you try to insert that value into the same field, the value is too large for the field to handle so MySQL simply chokes and stores it as 2147483647 (the ceiling of the unsigned INT type). If you then pass the long value 2147483647 through the reverse function (long2ip), that function returns, unsurprisingly,

In fact, any IP address larger than (so and up) will become a long too large for the field to handle and will truncate to the value.

So as detailed here before, the solution is to convert the field to a signed INT type. The range of values that field can handle is now 0 to 4294967295. On a 64-bit system, even the “largest” IP possible ( becomes 4294967295 after passed through the ip2long function which the field can handle.

Anyway, that’s my notes on the problem which will hopefully help some of you fix any of these issues.

Posted on Apr 01, '13 at 06:12 pm


Are there any updates on this? Or just more details?

My host just upgraded to 64-bit FreeBSD and I am being bitten by this bug.

I have access to PHPMyAdmin for my database(s), but I admit I’m not sure what to do.

I have several different mint tables, with names ?mint* (where the ? is 1 or 2, and * is geo, hostnames, visit or config) or ?mint (where the first * is bak or mymint, and the ? can be 1,2,3 or 4).

When I look at those tables, there are lots of entries; it’s not clear which is the right one, but if I look at the int(10) entries with names like “ip_long”, there doesn’t seem to be a way to change them to a signed type.

Any ideas?

Posted on Apr 02, '13 at 07:23 am


A little self-followup: first, apologies that I hadn’t properly dealt with markdown syntax in the previous message, so underlines have come out as emphasis.

Anyway, there is some more info on the problem here, with details on which fields to change, and where the information on signed vs unsigned is found (it is, perhaps unsurprisingly, an “attribute” — sorry I missed it).

I haven’t taken the advice to empty the table, as this seems a bit dangerous — I’m waiting to see if the info just works its way through the displayed hits. (and I still don’t know why I have quite so many different mint tables… I suspect it’s some of my own backing-up and restoring in the distant past about which I’ve forgotten).


Posted on Apr 02, '13 at 02:35 pm

Hi again (is anyone listening?),

So, this seems to sort of work…

I ended up emptying the mint_visit table, and also changing the ‘ip’ column of mint_hostnames to unsigned int.

However, I am still seeing some strange behaviour: a lot of hits are being attributed to one particular hostname. I don’t think this is right, because (I think) that hostname is actually changing with time, and moreover, other ways of looking at the hostnames (e.g., newest unique) seem to show entries that aren’t in the usual ‘most recent’ list.

So: do I need to change anything else? or did I screw up by chaining the entry in mint_hostnames?

We had this problem, too, across the board in nearly every table. The solution, as you inferred, was to change all checksum-based INT(10) field types to INT(10) UNSIGNED. YMMV, of course, but our issue started when we moved the Mint htdocs to a 64-bit server, and our DB is on the same, 64-bit server.

You must be logged in to reply. Login above or create an account

Hey there, I have officially suspended sales and support of Mint. The Create Account, Add License, Transfer License, and Contact forms have been disabled. Existing customers may continue to login and download Mint.

More info Continue