Why do I get a notice after migrating the site to a new server?

Question

I am getting this error after migrating the site to a new server:

Notice: unserialize() [function.unserialize]: Error at offset 2 of 23 bytes in includes/bootstrap.inc on line 478

I'm sure somewhere a setting has been corrupted; however, the site does appear to be functioning correctly. This error does return inconsistently, for anonymous users, so I do need to take care of it.
The error does not occur on the old server.

I have full control of the server, both the new and the old are Amazon EC2 VMs. The only major difference in the infrastructure is that the old server used a MySQL DB in the same VM, while the new server is using a MySQL Server in RBS.

I've read somewhere that this issue could be caused by the SQL export/import process, and something regarding UTF8. I wasn't able to garner anything I could mold into instructions to follow, but I have a feeling that's a path I need to take; I'm not really sure where to start.

Answer 1

The problem might be the error handling settings have changed on the new server. You probably have a corrupt variable in the variable table that can't be unsterilized. Try using the variable check module.

Answer 2

This is rather difficult to debug, but you might edit includes/bootstrap.inc where the unserialising happens – this is from the variable_init() function, where I assume the error occurs.

The original code looks like this.

while ($variable = db_fetch_object($result)) {
  $variables[$variable->name] = unserialize($variable->value);
}

Try altering it to something like this:

while ($variable = db_fetch_object($result)) {
  $variables[$variable->name] = unserialize($variable->value);

  if (!$variables[$variable->name]) {
    drupal_set_message('Possible error while decoding ' . $variable->name);
  }
}

There will be some false positives here, given that some values are actually FALSE or 0, but it should narrow the field, helping you to identify the broken variable. Then you can inspect the variables table in the database to find and fix it :)

Answer 3

I have had this happen when I migrate a database from staging to live and have to hand edit the database for paths, domain name, etc.

What is happens in the case is that the search-replace matches a string in the variables table, and alters the row. The problem is that length (the number after the s: doesn't get changes, so the unserialize fails.

If you go into the variable editor via the admin menu, you will likely see a blank entry where there was a real variable. Either update it here and save, or use a MySQL tool and fix the length in that row.