When the memcache infrastructure is updated, patched, or auto-scaled, its network address gets updated dynamically, and your running Drupal 7 application does not natively look up the address. During such period, such Drupal 7 applications may experience temporary slowness or brief periods of 5xx errors. This is an existing issue with Drupal 7 and memcache.
Workaround:
Add the following configuration to your settings.php file:
$conf['memcache_persistent'] = FALSE;
This ensures that the application handles connection resets gracefully. However, this may increase the baseline response time by typically 1-2 seconds. Nevertheless, Acquia recommends that you add this property as it provides greater stability during platform maintenance. In addition, having this property in the settings.php file reduces impact during maintenances that result in a memcache clear. By implementing the provided workaround, you can mitigate the impact.
Copy or import of databases fails
If the definition of a VIEW contains the database name in its defining query, you cannot copy or import databases.
Workaround:
To remove any instances of the database name db-name-printed-here from the VIEW:
Confirm the database name as follows:
mysql> show databases;;;
+----------------------------------+
| Database |
+----------------------------------+
| information_schema |
| db-name-printed-here |
+----------------------------------+
2 rows in set (0.02 sec)
Identify the views that contain references of the database name as follows:
mysql> SELECT TABLE_NAME AS VIEW_NAME,TABLE_SCHEMA AS DB_NAME FROM INFORMATION_SCHEMA.VIEWS WHERE VIEW_DEFINITION like '%db-name-printed-here%';
+-------------------------------------------+----------------------------------+
| VIEW_NAME | DB_NAME |
+-------------------------------------------+----------------------------------+
| some-view-name | db-name-printed-here |
+-------------------------------------------+----------------------------------+
1 row in set (0.06 sec)
Review the VIEW and remove all occurrences of the database name from the SQL query as follows:
mysql> SHOW CREATE VIEW some-view-name \G
*************************** 1. row ***************************
View: some-view-name
Create View: CREATE ALGORITHM=UNDEFINED DEFINER=`s10628`@`%` SQL SECURITY DEFINER VIEW `some-view-name` AS select `db-name-printed-here`.`watchdog`.`wid` AS `wid`,`db-name-printed-here`.`watchdog`.`severity` AS `severity`,`db-name-printed-here`.`watchdog`.`message` AS `message` from `db-name-printed-here`.`watchdog` where (`db-name-printed-here`.`watchdog`.`type` = 'cron')
character_set_client: utf8
collation_connection: utf8_general_ci
1 row in set (0.00 sec)
Process limit for Drupal, SSHD, Scheduled Tasks, and Cloud Hooks
You cannot have more than 5000 processes for Drupal, SSHD, scheduled tasks, and Cloud Hooks. If you exceed the process limit, the system restarts the service. This interrupts running requests and results in 50x errors for Drupal.
Note
If you run Shell commands from PHP in the background, such processes become defunct processes.
You cannot check the current number of processes on Drupal pods. However, you can view the process list on SSH pods.
Interruption in web requests taking longer than 10 minutes
Web requests that take longer than 10 minutes might be interrupted by routine platform maintenance activities.
Two daily backups
The Cloud Platform user interface may occasionally display two daily backup tasks for the same day, indicating the backups taken at different times of the day.
“End of script output before headers” error occurs if the HTTP response header exceeds 8 KB
Cloud Platform 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
File copy operation takes longer in Cloud Platform compared to the non-Kubernetes version
The file copy operation in Cloud Platform takes longer as compared to the time taken in the non-Kubernetes version. This occurs because the files are first copied from the production environment to an intermediate ODE environment, and then to a migration environment. After the copy operation is complete, the system deletes the ODE environment, thereby keeping only the migration environment. This additional step in the migration process consumes more time.
Currently, you cannot increase the PHP file upload size values beyond the limits available in the Cloud Platform user interface. The maximum size for Cloud Platform is 1024 MB.
Upload a small dummy file of the next version of your software through the Drupal user interface. After that, you can access the Acquia Cloud service through SSH or SFTP, push the actual file, replacing the original dummy file. This process enables you to reference the file in Drupal and utilize it visually according to your preferences in Drupal.
memcache_admin incompatibility for FedRAMP customers
For FedRAMP customers, Cloud Platform uses individual mcrouter instances on each pod. This obscures information such as cache hits or misses and might misreport metrics on each report. Therefore, the memcache_admin module does not correctly report the status of memcache instances. Cumulative statistics, available memory, and evictions are reported as zero. In addition, other statistics might be misreported.
Workaround:
To gather memcache statistics, run the following command in an SSH session:
acquia-memcache stats
This command displays statistics from the available memcache instances.
Known issues
Issue with memcache in Drupal 7 applications
When the memcache infrastructure is updated, patched, or auto-scaled, its network address gets updated dynamically, and your running Drupal 7 application does not natively look up the address. During such period, such Drupal 7 applications may experience temporary slowness or brief periods of 5xx errors. This is an existing issue with Drupal 7 and memcache.
Workaround:
Add the following configuration to your settings.php file:
$conf['memcache_persistent'] = FALSE;
This ensures that the application handles connection resets gracefully. However, this may increase the baseline response time by typically 1-2 seconds. Nevertheless, Acquia recommends that you add this property as it provides greater stability during platform maintenance. In addition, having this property in the settings.php file reduces impact during maintenances that result in a memcache clear. By implementing the provided workaround, you can mitigate the impact.
Copy or import of databases fails
If the definition of a VIEW contains the database name in its defining query, you cannot copy or import databases.
Workaround:
To remove any instances of the database name db-name-printed-here from the VIEW:
Confirm the database name as follows:
mysql> show databases;;;
+----------------------------------+
| Database |
+----------------------------------+
| information_schema |
| db-name-printed-here |
+----------------------------------+
2 rows in set (0.02 sec)
Identify the views that contain references of the database name as follows:
mysql> SELECT TABLE_NAME AS VIEW_NAME,TABLE_SCHEMA AS DB_NAME FROM INFORMATION_SCHEMA.VIEWS WHERE VIEW_DEFINITION like '%db-name-printed-here%';
+-------------------------------------------+----------------------------------+
| VIEW_NAME | DB_NAME |
+-------------------------------------------+----------------------------------+
| some-view-name | db-name-printed-here |
+-------------------------------------------+----------------------------------+
1 row in set (0.06 sec)
Review the VIEW and remove all occurrences of the database name from the SQL query as follows:
mysql> SHOW CREATE VIEW some-view-name \G
*************************** 1. row ***************************
View: some-view-name
Create View: CREATE ALGORITHM=UNDEFINED DEFINER=`s10628`@`%` SQL SECURITY DEFINER VIEW `some-view-name` AS select `db-name-printed-here`.`watchdog`.`wid` AS `wid`,`db-name-printed-here`.`watchdog`.`severity` AS `severity`,`db-name-printed-here`.`watchdog`.`message` AS `message` from `db-name-printed-here`.`watchdog` where (`db-name-printed-here`.`watchdog`.`type` = 'cron')
character_set_client: utf8
collation_connection: utf8_general_ci
1 row in set (0.00 sec)
Process limit for Drupal, SSHD, Scheduled Tasks, and Cloud Hooks
You cannot have more than 5000 processes for Drupal, SSHD, scheduled tasks, and Cloud Hooks. If you exceed the process limit, the system restarts the service. This interrupts running requests and results in 50x errors for Drupal.
Note
If you run Shell commands from PHP in the background, such processes become defunct processes.
You cannot check the current number of processes on Drupal pods. However, you can view the process list on SSH pods.
Interruption in web requests taking longer than 10 minutes
Web requests that take longer than 10 minutes might be interrupted by routine platform maintenance activities.
Two daily backups
The Cloud Platform user interface may occasionally display two daily backup tasks for the same day, indicating the backups taken at different times of the day.
“End of script output before headers” error occurs if the HTTP response header exceeds 8 KB
Cloud Platform 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
File copy operation takes longer in Cloud Platform compared to the non-Kubernetes version
The file copy operation in Cloud Platform takes longer as compared to the time taken in the non-Kubernetes version. This occurs because the files are first copied from the production environment to an intermediate ODE environment, and then to a migration environment. After the copy operation is complete, the system deletes the ODE environment, thereby keeping only the migration environment. This additional step in the migration process consumes more time.
Currently, you cannot increase the PHP file upload size values beyond the limits available in the Cloud Platform user interface. The maximum size for Cloud Platform is 1024 MB.
Upload a small dummy file of the next version of your software through the Drupal user interface. After that, you can access the Acquia Cloud service through SSH or SFTP, push the actual file, replacing the original dummy file. This process enables you to reference the file in Drupal and utilize it visually according to your preferences in Drupal.
memcache_admin incompatibility for FedRAMP customers
For FedRAMP customers, Cloud Platform uses individual mcrouter instances on each pod. This obscures information such as cache hits or misses and might misreport metrics on each report. Therefore, the memcache_admin module does not correctly report the status of memcache instances. Cumulative statistics, available memory, and evictions are reported as zero. In addition, other statistics might be misreported.
Workaround:
To gather memcache statistics, run the following command in an SSH session:
acquia-memcache stats
This command displays statistics from the available memcache instances.
Change in mod_headers behavior in Cloud Platform
In the non-Kubernetes version, mod_headers directives in the .htaccess file are ignored for PHP and Drupal requests, and are only applied to static files. However, in Cloud Platform, 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.
MySQL 5.7 features incompatibilities on Cloud Platform
Cloud Platform leverages AWS Aurora MySQL. A few of the MySQL 5.7 features are not supported on Cloud Platform. For more information, see list of unsupported MySQL 5.7 features.
Scheduled jobs must not use hardcoded host names in log paths
Scheduled jobs or cron jobs in Cloud Platform must not use hardcoded host names in log paths. However, if you use /shared/logs as the directory, you can use hardcoded paths.
Limitations with scheduled jobs
When you create scheduled jobs in Cloud Platform, your cron task duration must not be more than 3 hours. If your cron job lasts longer than that, it terminates.
Limitations with Cloud Hooks
The maximum duration of Cloud Hook scripts is 3 hours. If your Cloud Hook script lasts longer than that, it terminates.
Cloud Hook scripts and all child processes have a maximum memory limit of 2000 MB. If these processes exceed the available memory, the Cloud Hook logs display messages such as Killed or Exit status 137.
TLS connection issues in Ubuntu 22.04
OpenSSL 3.0.x enforces strict TLS compliance in Ubuntu 22.04. This compliance causes connection errors with external services that have improper TLS implementation. For example, you might get the following error:
Ensure that your external services are updated to meet TLS standards.
Issues in connecting with locally-installed MySQL Workbench
If you have MySQL Workbench installed locally, you might not be able to connect to Cloud Platform environments. This issue occurs for a few versions of MySQL Workbench.
If you face such issues :
Locate the database credentials listed on your Databases page.
Open Terminal on your local machine and 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.
Code deployment in Cloud Platform can take a maximum of 1 hour. Environments on Cloud Platform may intermittently experience code deployment times taking more than 5 minutes. Ensure that you close your SSH session before starting your code deployment. If you are in an SSH session and start code deployment, the process might fail.
Git repositories in Cloud Platform must not exceed 2 GB. If your repository size exceeds this limit, code deployment tasks might fail without displaying any public logs. In such a case, you must verify that the combined size of all files in the specified Git branch or tag is less than 2 GB. For more information, visit Disk Storage.
Drupal watchdog logs not captured for SSH
Tasks executed through SSH do not run the syslog service. Logging done through the Drupal Logging API, also known as Watchdog, is only sent to the standard output and standard error channels, and not to the drupal-watchdog logs that can be downloaded from the Cloud Platform user interface or Cloud API.
If an application uses the Log Forwarding feature, this same logging is not sent to a log forwarding destination.
As a workaround, you must configure tasks to execute through HTTP request with the HTTP Drush Wrapper module. HTTP requests have an expiration of 10 minutes.
The database copy, backup, and restore operations are updated to maintain compatibility between MySQL 5.7 and MySQL 8. This ensures that these operations continue to function as expected during database version upgrade of MySQL. This update modifies any data in your database from utf8mb4_0900_ai_ci to utf8mb4_general_ci during these operations. Acquia could not target the specific collation or charset. Therefore, if your database contains content with the utf8mb4_0900_ai_ci collation, the system updates it to utf8mb4_general_ci.
This update does not apply to database dumps and restores that are done manually with Drush. Therefore, such operations might fail when you copy them between databases on different MySQL versions.
The automatic collation conversion described previously applies only when the destination database is MySQL 5.7. Customers who use MySQL 8.0 as the destination are not affected by this behavior. Therefore, the sed-based workaround is not required for MySQL 8 environments.
Workaround:
If you have a database dump that you have exported manually and you cannot import it properly, you can convert the file by running a command similar to the following:
You have a database backup file that is gzip-compressed in the current folder.
You are running a Cloud Platform SSH connection or Cloud IDE.
Therefore, you must update the command depending on your requirements.
Custom Varnish configurations with Acquia Purge
If your Cloud Platform application uses a Custom Varnish Configuration (cVCL) file to restrict access based on IP addresses, you might experience issues with the Acquia Purge module. This occurs because purge requests originate from Web EIP addresses. By default, such requests are blocked if you do not explicitly allowlist the Web EIPs in your cVCL.
Workaround:
Contact Acquia Support to enable Web EIPs.
Update your custom VCL to allowlist the Web EIP addresses.
Extra or missing logs in log downloads
When you download logs, you might get extra entries or missing logs in your downloaded file. However, the time displayed on the downloaded logs is correct.
Workaround: If you are missing specific logs, try to download logs for the previous or next day in addition to your original date range. Therefore, you can access logs that did not appear in your initial download.
Did not find what you were looking for?
If this content did not answer your questions, try searching or contacting our support team for further assistance.
Change in mod_headers behavior in Cloud Platform
In the non-Kubernetes version, mod_headers directives in the .htaccess file are ignored for PHP and Drupal requests, and are only applied to static files. However, in Cloud Platform, 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.
MySQL 5.7 features incompatibilities on Cloud Platform
Cloud Platform leverages AWS Aurora MySQL. A few of the MySQL 5.7 features are not supported on Cloud Platform. For more information, see list of unsupported MySQL 5.7 features.
Scheduled jobs must not use hardcoded host names in log paths
Scheduled jobs or cron jobs in Cloud Platform must not use hardcoded host names in log paths. However, if you use /shared/logs as the directory, you can use hardcoded paths.
Limitations with scheduled jobs
When you create scheduled jobs in Cloud Platform, your cron task duration must not be more than 3 hours. If your cron job lasts longer than that, it terminates.
Limitations with Cloud Hooks
The maximum duration of Cloud Hook scripts is 3 hours. If your Cloud Hook script lasts longer than that, it terminates.
Cloud Hook scripts and all child processes have a maximum memory limit of 2000 MB. If these processes exceed the available memory, the Cloud Hook logs display messages such as Killed or Exit status 137.
TLS connection issues in Ubuntu 22.04
OpenSSL 3.0.x enforces strict TLS compliance in Ubuntu 22.04. This compliance causes connection errors with external services that have improper TLS implementation. For example, you might get the following error:
Ensure that your external services are updated to meet TLS standards.
Issues in connecting with locally-installed MySQL Workbench
If you have MySQL Workbench installed locally, you might not be able to connect to Cloud Platform environments. This issue occurs for a few versions of MySQL Workbench.
If you face such issues :
Locate the database credentials listed on your Databases page.
Open Terminal on your local machine and 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.
Code deployment in Cloud Platform can take a maximum of 1 hour. Environments on Cloud Platform may intermittently experience code deployment times taking more than 5 minutes. Ensure that you close your SSH session before starting your code deployment. If you are in an SSH session and start code deployment, the process might fail.
Git repositories in Cloud Platform must not exceed 2 GB. If your repository size exceeds this limit, code deployment tasks might fail without displaying any public logs. In such a case, you must verify that the combined size of all files in the specified Git branch or tag is less than 2 GB. For more information, visit Disk Storage.
Drupal watchdog logs not captured for SSH
Tasks executed through SSH do not run the syslog service. Logging done through the Drupal Logging API, also known as Watchdog, is only sent to the standard output and standard error channels, and not to the drupal-watchdog logs that can be downloaded from the Cloud Platform user interface or Cloud API.
If an application uses the Log Forwarding feature, this same logging is not sent to a log forwarding destination.
As a workaround, you must configure tasks to execute through HTTP request with the HTTP Drush Wrapper module. HTTP requests have an expiration of 10 minutes.
The database copy, backup, and restore operations are updated to maintain compatibility between MySQL 5.7 and MySQL 8. This ensures that these operations continue to function as expected during database version upgrade of MySQL. This update modifies any data in your database from utf8mb4_0900_ai_ci to utf8mb4_general_ci during these operations. Acquia could not target the specific collation or charset. Therefore, if your database contains content with the utf8mb4_0900_ai_ci collation, the system updates it to utf8mb4_general_ci.
This update does not apply to database dumps and restores that are done manually with Drush. Therefore, such operations might fail when you copy them between databases on different MySQL versions.
The automatic collation conversion described previously applies only when the destination database is MySQL 5.7. Customers who use MySQL 8.0 as the destination are not affected by this behavior. Therefore, the sed-based workaround is not required for MySQL 8 environments.
Workaround:
If you have a database dump that you have exported manually and you cannot import it properly, you can convert the file by running a command similar to the following:
You have a database backup file that is gzip-compressed in the current folder.
You are running a Cloud Platform SSH connection or Cloud IDE.
Therefore, you must update the command depending on your requirements.
Custom Varnish configurations with Acquia Purge
If your Cloud Platform application uses a Custom Varnish Configuration (cVCL) file to restrict access based on IP addresses, you might experience issues with the Acquia Purge module. This occurs because purge requests originate from Web EIP addresses. By default, such requests are blocked if you do not explicitly allowlist the Web EIPs in your cVCL.
Workaround:
Contact Acquia Support to enable Web EIPs.
Update your custom VCL to allowlist the Web EIP addresses.
Extra or missing logs in log downloads
When you download logs, you might get extra entries or missing logs in your downloaded file. However, the time displayed on the downloaded logs is correct.
Workaround: If you are missing specific logs, try to download logs for the previous or next day in addition to your original date range. Therefore, you can access logs that did not appear in your initial download.
Did not find what you were looking for?
If this content did not answer your questions, try searching or contacting our support team for further assistance.
Cloud Platform