Troubleshooting application imports | Cloud Platform

As described in Importing an existing application, there are several different methods you can use to import a Drupal application into Cloud Platform. In the majority of cases, the import process works quickly and smoothly. Here are some things you can do to make the import work better and some things to check for in those cases where it does not work.

Before you import your application¶

Read Preparing a Drupal application for export, which lists recommended steps to take before you import your Drupal application to Cloud Platform.

Use manual import process for multisite¶

Multisite Drupal installations use a separate database for each website within the application. The site import process used by Cloud Platform can import only applications with a single database. If you want to import a multisite Drupal installation, you need to import it using the manual import process.

Check for dependency on unsupported PHP libraries or unsupported PHP version¶

Cloud Platform runs a specific set of PHP libraries on the versions of PHP listed in Cloud Platform technology platform. If your application requires a later or earlier PHP version or PHP libraries that do not run on Cloud Platform, your application may not work on Cloud Platform.

Check your PHP memory limit¶

Cloud Platform configures a PHP memory limit for your infrastructure. If your application is configured with a larger PHP memory limit, it will not be able to start. The PHP memory limit might be set in one of three places:

The memory_limit parameter in php.ini
The php_value parameter in .htaccess
The memory_limit parameter in the Drupal settings.php file in sites/default/settings.php

For Cloud Platform applications, you should never set any of these parameters in these files. Cloud Platform Professional customers can configure the PHP memory limit for an environment. Cloud Platform Enterprise customers can create a Support ticket requesting a change in the PHP memory limit. If you have memory_limit settings in .htaccess or settings.php files, delete them before you import your application.

See also Conditionally increasing memory limits and Memory consumption tracking tools for tips about controlling the amount of memory your application requires.

Checking for import success¶

Importing an application into Cloud Platform is usually fairly quick, but it is not instantaneous. Depending on which import method you choose, the import process has three major steps:

Creating a site archive
Sending the site archive to Acquia
Opening the site archive and creating the application from it

Depending on the size of your application and your Internet connection, the first two steps can take from a few minutes to, in some cases, more than an hour. You can check the progress by signing in to the Cloud Platform interface, selecting your application, and clicking the activity button. After the site archive has arrived on the Cloud Platform infrastructure, you should see an entry like this in the activity log:

Import [archive-filename].tar.gz to environment Dev

In addition, you can see your site archive file on the infrastructure. Connect to the infrastructure with SSH. You should be able to find the site archive file in /mnt/gfs/[site]dev/import.

One factor in how long a site import can take is the size of of your site archive. You can minimize the size of the site archive by doing the following:

Clearing your cache before you start the site import
Removing any Drupal modules that have been disabled and that you are not using

My application is on Cloud Platform, but will not start¶

If you have verified that your application’s archive file has reached Cloud Platform, but your application does not start (will not serve pages), here are some things you can check.

Get your application status with Drush¶

Connect to your environment with SSH.
From the command line, run the drush status command, targeting your Dev environment:
```
drush @[site].dev status
```

Examine the output of drush status for errors that may give you clues about issues that are keeping your application from starting.

Look for errors in infrastructure and PHP logs¶

You can download your Apache infrastructure and PHP error logs from the Logs page for examination. As an alternative, you can obtain the logs by using SSH:

Connect to your environment with SSH.
Find your Apache infrastructure error log at /var/log/sites/[site].[env]/logs/[infrastructurename]/error.log and your PHP error log at /var/log/sites/[site].[env]/logs/[infrastructurename]/php-errors.log.

Any displayed error messages should indicate the root cause of the error. For more information about the format of these log files and their contents, see About Cloud Platform logging.

Disable problematic Drupal modules¶

One common reason why a Drupal application might not start on Cloud Platform is a custom Drupal module that will not run on Cloud Platform. If you know which module is causing the problem, you can disable it. For information about how to do this, see Disabling modules that block sites on Cloud Platform.

Troubleshooting Acquia Connector imports¶

Here are solutions to some issues you may encounter in importing an application using the Acquia Connector.

The Migrate button doesn’t do anything when you click it¶

If the Acquia Connector does not start to migrate your application when you click Migrate, clear your Drupal cache, and then retry the migration process.

To clear your Drupal cache, open your Drupal application’s Performance page at http://[site_URL]/admin/config/development/performance.

Cloud Platform displays an error message when attempting to migrate your application¶

If you are experiencing errors while migrating your application, clear the Migrate files directory checkbox, select the Reduce database export size checkbox, and then retry the migration process. These options are not displayed unless you have already attempted to migrate and encountered an error.

The following error messages describe the most common causes of problems with the migration process. If you don’t see your error message, or the actions associated with the message don’t allow you to migrate your application, contact Support or use a different application import method.

Error message	Explanation
`No compression libraries available`	The application’s installed PHP does not have available GZip or Zip libraries.
`Cannot create temporary directory [file-system-directory] to store site archive`	The Acquia Connector cannot create a directory in the Drupal files directory. Examine the file system permissions for the Drupal files directory.
`Server error, please submit again`	The Acquia infrastructure did not respond. Retry the migration process. If the Acquia Connector displayed this message at the end of the migration process, examine the Cloud Platform interface Notifications panel to see if an import is in progress, and if so, you can ignore this error message.
`Signature from server is wrong`	Your Cloud Platform application did not respond with a correct signature, indicating possible transmission corruption. Retry the migration process.
`Server error, unable to retrieve environments for migration`	Make sure that your Development environment does not have a tag deployed. Environments with tags deployed will be excluded from the eligible list of environments.
`Transfer error`	The Acquia Connector encountered an unknown error during the site archive upload portion of the process. Retry the migration process.
`AJAX Error regarding ReadyState`	The Drupal batch process running the migration encountered an error. Consult Drupal logs for more information or retry the migration process.