Known issues in Cloud Next¶

Unable to get the expected output when using SSH¶

When using SSH in Cloud Next environments, you might not get the complete output.

Unable to increase PHP file upload size¶

Currently, you cannot increase the PHP file upload size values beyond the limits available in the Cloud Platform user interface.

Workaround: Acquia recommends that you use a contributed module. For more information, see Use contributed modules for file upload handling.

Unable to copy files between environments¶

The system might display the following error when you attempt to copy files between environments:

rsync: change_dir "/mnt/source/mnt/data/[UUID]-real-shared/sites/[SITENAME]/files" failed: No such file or directory (2)

Until Acquia provides a resolution, contact Acquia Support for assistance with copying files.

Memcache binary protocol is not supported¶

The Memcache binary protocol is not supported in Cloud Next environments. Cloud Next leverages mcrouter, which only supports the ASCII protocol for Memcache. If you enable binary protocol in Cloud Next environments, Drupal and PHP cannot communicate with Memcache servers. Therefore, the application fails to set or get cache items but does not return an error message.

“End of script output before headers” error occurs if the HTTP response header exceeds 8 KB¶

Cloud Next introduces a limit of 8 KB to HTTP response headers. When using HTTP headers, ensure that the header size does not exceed this limit. For example, this limit might be triggered when you use:

• Acquia Purge module that is configured to output debug headers
• Security Kit (seckit) module that is configured to output X-Content-Security-Policy headers

Change in mod_headers behavior in Cloud Next¶

In Cloud Classic, mod_headers directives in the .htaccess file are ignored for PHP and Drupal requests, and are only applied to static files. However, in Cloud Next, mod_headers directives in the .htaccess file are applied. This might result in unexpected or unwanted changes in application behavior. Acquia recommends that you review your .htaccess file for mod_headers usage.

Acquia Connector does not self-configure in Cloud Next¶

The Acquia Connector module does not self-configure in Cloud Next. After you upgrade to Cloud Next, the system displays the following notice:

Subscription not active.

Static IPs not supported for Log Forwarding¶

Currently, Cloud Next does not support sending logs from static IPs.

Limit of 1 GB for file uploads using Drupal or PHP¶

On Cloud Next, the following PHP directives are limited to 1 GB:

• upload_max_filesize
• post_max_size
• memory_limit

This limits Drupal to only accept file uploads smaller than 1 GB. You can consider integrating with external services if your application requires platform support for larger file uploads.

MyISAM tables are not supported on Cloud Next¶

The MyISAM table engine is not available on Cloud Next. The InnoDB table engine is the default in Drupal since the release of Drupal 7.0.

MySQL 5.7 features incompatibilities on Cloud Next¶

Cloud Next leverages AWS Aurora MySQL. A few of the MySQL 5.7 features are not supported on Cloud Next. For more information, see list of unsupported MySQL 5.7 features.

More than 20 databases are not supported¶

Currently, the number of databases connected to multisite environments on Cloud Next must not exceed 20.

Application codebase size must not exceed 2 GB¶

Application codebases exceeding 2 GB might experience timeouts during deployments, or failure of deployments.

If your codebase exceeds 2 GB, remove large files from the Git repository, and upload them separately to the files directory using SSH or SFTP.

To find your largest directories, do the following on your web server:

1. Change to your docroot directory.
2. Run the ncdu command to interactively browse by disk usage.
3. In your local git checkout, confirm that the public files directories, such as sites/default/files, are not committed to the repository. Once deployed to a web server, the distributed file system is mounted in that location. This hides anything that you have committed to the repository.

Scheduled jobs must not use hardcoded log paths¶

Scheduled jobs or cron jobs on Cloud Next must not use hardcoded log paths.

Scheduled jobs cannot run more frequently than once every five minutes¶

The frequency of scheduled jobs or cron jobs on Cloud Next cannot exceed once every five minutes. For jobs that must run once per minute, you might use a wrapper script that executes the desired command in a loop. For example, you can use the following:

#!/bin/bash

# The end timestamp is now + 300 seconds (5 minutes).
end=$(( $(date +%s) + 300 ))

while : ; do
   start=$(date +%s)

   # This is where you run the drush command, wget,
   # curl, etc. that you would like to execute once a
   # minute.
   drush queue-run example_queue

   # Ensure it does not run more frequently than once
   # per minute by sleeping if the command takes less
   # than a minute to execute.
   sleep $(( 60 - $(date +%s) + $start ))

   # Exit the loop if the current timestamp exceeds the
   # end timestamp.
   [ $(date +%s) -lt $end ] || break
done

After the wrapper script is added to your code repository, go to Scheduled Jobs page in the Cloud Platform user interface and define a new scheduled job that calls the wrapper script once every 5 minutes.

Pushing multiple commits causes code deployment failures¶

When you push multiple commits to a branch in quick succession, you get the following error in the task log in the Cloud Platform user interface:

Server does not allow request for unadvertised object <git-sha>

For example,

Server does not allow request for unadvertised object 48db8d8a88679468ccdc677753d8a2c9cb0ee117

For example, let us assume that you run the following commands in the same order:

git commit -m "Commit A" ; git push

git commit -m "Commit B" ; git push

git commit -m "Commit C" ; git push

Results:

• Deployment related to the A commit fails if you try to deploy the B or C commit before the push related to the A commit reaches the build step. In such a case, the system does not deploy code or run cloud hooks, and retries deployment for 60 minutes.
• Deployment related to the B commit fails. The system retries deployment for 60 minutes.
• Deployment related to the C commit succeeds.

You do not need to take any action unless you want the cloud hooks for the first push to run before the subsequent pushes.

SSH error with OpenSSH version 8.8 or later¶

After upgrading your local version of OpenSSH to 8.8 or later, you might get the following error while connecting to an Cloud Next environment over SSH:

###@###.ssh.prod.acquia-sites.com: Permission denied (publickey).

Workaround:

Add the -o PubkeyAcceptedAlgorithms=+ssh-rsa option when using SSH, or add the following to the ~/.ssh/config file:

Host *.ssh.prod.acquia-sites.com
PubkeyAcceptedAlgorithms +ssh-rsa

Issues connecting to Cloud Next environments with locally-installed MySQL Workbench¶

If you have MySQL Workbench installed locally, you might not be able to connect to environments on Cloud Next. This issue occurs for a few versions of MySQL Workbench.

However, you are not impacted if you are running Sequel Pro locally.

If you face issues connecting to Cloud Next environments from MySQL Workbench, do the following:

1. Locate the database credentials listed on your Databases page.

2. In a terminal in your PC, run:

   {ssh -L $LOCAL_PORT:$DB_HOST:3306 $SSH_STRING}

   Here,

   • LOCAL_PORT is the port to which Workbench must connect when using localhost.
   • DB_HOST is the hostname obtained from the Cloud Platform user interface.
   • SSH_STRING is the full connection string from the Cloud Platform user interface. For example, user@something.

Long code deployment times¶

Environments on Cloud Next may intermittently experience code deployment times taking more than five minutes.

Issue with BLT 11.x and Drupal 8¶

BLT 11.x resets the reverse proxy addresses set by Cloud Next. This issue is fixed in more recent versions of BLT. However, Drupal 8 can only run BLT 11.x. To fix this issue on a Drupal 8 site, make the following changes in settings/blt.settings.php:

# Replace line 41 with the following:
$settings['reverse_proxy_addresses'] =
isset($settings['reverse_proxy_addresses']) ?
$settings['reverse_proxy_addresses'] : [];

memcache_admin incompatibility¶