This page provides information about common errors encountered during Remote Administration (RA) environment security updates, along with possible solutions.

If you encounter an error during the first step of the RA security update process, you must first review the provided error, suggested steps, and documentation for guidance. If solutions are provided, attempt to deploy the suggested fix to your production environment. After deploying the fix, wait for the next automated update attempt to see if the issue has been resolved. Ensuring all documentation steps are carefully followed typically resolves the encountered errors.

If the problem persists, or if the security update is time-sensitive and you lack the necessary developer resources, consider enlisting a partner developer or engaging Acquia Professional Services to effectively address the issue. Timely resolutions are critical for maintaining site security.

• Error: Drush, All pending updates failed on RA for prod:siteName
  • Default multisite may not be functional
    • Configure the default multisite with a working settings.php file with a correct database include statement. See Configuring your application to use environment databases.
    • Point requests for default at a working multisite in the sites.php file. See Using sites.php to specify an alternate settings.php file.
  • Drush may not be configured to work on the RA environment.
    • Check any environment specific case statements or code accounts for the RA environment.
• Error: Unable to run drush #.#.# pm-updatestatus/pm:security on any Production multisite for prod:siteName, exiting.
  • Default multisite not working
    • Configure the default multisite with a working settings.php file with a correct database include statement. See Configuring your application to use environment databases.
    • Point requests for default at a working multisite in the sites.php file, using sites.php to specify an alternate settings.php file.
  • Drush symlink is missing from vendor/bin - Ensure vendor/bin/drush is committed to a branch and deployed.
  • An alternate .drushrc file was detected. - Remove it from the codebase and add it to your .gitignore file.
  • See Known issues with Drush for Drush specific solutions.
  • The website runs the current Drupal version, but is not Composer-based.
    • Convert to a Composer-based website: Acquia Automation: Composer builds.
• Error: Error performing task 16811 : StageDeploy with error message Staging failed because at least one site failed to stage during the process.
  • A previously staged website is no longer valid.
    • Give the RA team with a list of 5 to 10 domains for websites which should be staged in the RA environments.
• Error: Unable to run drush As this is a Drupal multi-site build, and you haven't specified a [status] pm-updatestatus/pm:security on any Production multisite for prod:siteName, exiting.
  • This error is related to the Domain Access module.
    • Give the RA team a list of 5 to 10 domains for websites to include in the update process.
    • Add domain aliases to your primary domain configuration on production that includes all non-production domains.
• Error: Unable to run drush [warning] "continue" targeting switch is equivalent to "break". Did you mean to use "continue"? file.module:898 pm-updatestatus/pm:security on any Production multisite for  prod:siteName, exiting.
  • This error indicates an outdated Drupal core running on PHP 7.3.
    • Update Drupal core.

Troubleshooting for failed updates on Composer-based websites

If you encounter an error during the RA automated update process, particularly with security updates for the current Drupal version, you might need to validate that that your site's Composer configuration is correct. For validation, you must ensure that:

• A composer.json file with your required modules is in place above the docroot,

• A composer.lock file is in place above the docroot,

• The /vendor directory is in place above the docroot, and

• The docroot/autoload.php file references the location of the vendor directory.

View the Composer log file attached to the ticket, search for the first occurrence of Error Output to find details of what caused the automated update process to fail.

Acquia recommends that your development team fixes the root cause of the error and closes the associated ticket. This ensures that the automated process for security updates can attempt to update the website in the next weekly run.

The following table documents the probable root causes for different error messages that you may encounter in the Composer log file, and serves as a starting point for fixing the errors.

Security update process common errors

core : exact version constraints

core : exact version constraints