Acquia FAQs

Issue

There are a number of reasons why your Drupal installation could run out of memory (oom). Insufficient allocation at install, additional modules, and large tasks are all causes for out-of-memory problems. These often manifest asPHP Fatal Error: Out of memorynotices.

Resolution

Here are some techniques to help you figure out what is using significant amounts of memory:

Logging and memory profiler

Memory Profiler module is a lightweight module that can be used on a production site. However, we recommend testing memory consumption on staging or development servers.

Increase your PHP Memory limit incrementally until the errors subside.

Install and enable syslog (for thedrupal-watchdog.log) and the Memory profiler module. Disable the dblog module.

Repeat the steps that led to the initial high memory usage or oom error.

Disable theMemory profilermodule when testing is completed.

Each page will then log an entry to thedrupal-watchdog.log, with a tag ofmemory profilerand the amount of memory that page used. You can easily search and analyze this. You can then either create conditional memory increases for those paths as described in Conditionally increasing memory limits, or determine if an overall site memory boost is required.

This is also a small enough footprint to use safely in production, but if you can replicate the issue on a development or staging environment, that is usually better.

If you download your logs and have UNIX command line tools such as grep available, you can use this query to help parse the memory profiler output for today's log:

# Run this from the shell in your /var/log/sites/[site.env]/logs/[servername] folder.

#

# This gets the latest 50 (see $num) memory-exhaustion errors from php-errors.log,

# and then shows the corresponding lines found in $logfile (e.g. access.log, drupal-watchdog.log, etc)

# NOTE: Large values in $num can place load on your server while this runs--you should download files if you plan to do any heavy analysis.

#

num=50; logfile=access.log; grepstring=`grep "Allowed memory size" php-errors.log |tail -$num |grep -o 'request_id="[^"]*"' |awk -F'"' 'NR>1 { printf "|"; } { printf $2 }'`; egrep "$grepstring" $logfile

XHProf

XHProf can trace script execution times, as well as enable memory profiling. Memory profiling is not on by default, however, and must be enabled. TheXHPROF_FLAGS_MEMORYflag will enable this feature. More information on both enabling xhprof and the xhprof contstants is on PHP.net. For specific information on enabling and using XHProf on your Drupal site, see Using XHProf to evaluate code performance.

Other applications

Many performance management software applications can also help you figure out if it's a memory, database, or other issue. Newrelic is able to be used on Acquia Cloud

New Relic

If you have a New Relic account,you can use that for determining where bottlenecks may be occurring for code, network or databases.

For information on increasing memory limits, see the article on Conditionally increasing memory limits.

Itis important to understand the layers of execution of varioussettingsfiles used on Site Factory sites despite customers not having direct access to modify these files.

For example, let's look at the differences between/sites/default/settings.phpand/sites/g/settings.php.

/sites/default/settings.php

The following file/sites/default/settings.phpis only executed when no site is found for a domain.

Other key concepts:

Includes references to various*.settings.phpfiles (* = files, cron, dev, testing, etc.)

Settings configuration in this file, as well as the*.settings.phpfiles are all duplicated in eitherpreorpostcloud hooksettings.phpfiles

Does not get run on Acquia Cloud Site Factory, as all settings configuration is handled bysites/g/settings.phpandcloud-hooks

/sites/g/settings.php

The file/sites/g/settings.phpis not allowed to be changed.

Key concepts:

Added via initialization of theacsfmodule

Invokes pre/post cloud hooks

Includes site-specific settings file that is not in the code repository, but hosted separately on Acquia Cloud Site Factory

Immutable. All changes to this file should come via theacsf-initdrush command. More information aboutacsf-initcan be found at Using your own Drupal distribution

Additional settings should be added via the respective pre/post factory hooksettings files

Factory hooks are used to perform various website actions that occur during runtime, or to perform code execution after runtime events. More information about using Factory hooks can be found in our documentation on Triggering code execution.

Issue

How can I fix PHP errors on my website?

Resolution

When it comes to performance tuning your Drupal application onAcquia Cloud and in other hosting environments; or, just figuring out why your site may be running slower than expected, there is a wealth of information that can be gleaned from your PHP errors log (php-errors.log), Drupal Watchdog log (drupal-watchdog.log) and FPM errors log (fpm-error.log).

PHP Memory Limit errors

The PHP memory limit is the maximum amount of RAM memory, in M, that a single PHP process can consume. Memory used by the MySQL client counts against the PHP memory limit.The default setting for PHP memory is adequate for most Drupal applications on Acquia Cloud, but you may see the following errors which are clear signs that the memory limit may be set too low.

WSOD (White Screen of Death) errors, these are characterized by going to the page, and seeing a blank page (a blank white screen) with no error message.

Temporary Unavailableerrors - on a page, or on a site action, for example, uploading large files, or running long reports.

Check thephp-errors.log for errors similar to this one:

[20-Feb-2017 19:26:10 America/New_York] PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 15990062 bytes) in docroot/includes/database/database.inc on line 2227

The best way to resolve these issues is within the application. Use How investigate Memory Consumption problems to help you identify resource intensive areas of your application. We recommend making changes in your code to reduce the memory use; however, it can help to increase the PHP memory limit in some cases. This can be changedeither through the Acquia Cloudweb site for our Acquia Cloud Professional and Acquia Cloud Enterprise products (more information in Configuring PHP Settings ) or through a support ticket for Site Factory products.

PHP Max Execution Time

PHP Max Execution is the amount of time a single PHP process can run (in seconds). We recommend that you resolve this problem by identifying slow processes and refactoring the code that makes the request or set_time_limit() function.

Search the the fpm-error.log for max_children errors - which can indicate that the available PHP/FPM processesare consumed. This can also be indicated by Temporarily Unavailable, or White Screen of Death errors.

Our Acquia Cloud Professional and Acquia Cloud Enterprise products can adjust PHP Max Execution time through the Acquia Cloudweb site ( Configuring max execution time ).

PHP OPcache

OPcache is the cache for thepre-compiled bytecode. It is faster than using PHP to load andparse the PHPscripts that make up your Drupal applicationfor each and every HTTP (HTTPS) request. The OPcache in PHP 7 should be set to be large enough to store compiled code for your applications' PHP scripts, but we recommend that you also set this value to be low enough to avoid allocating too much RAM to an underused cache. This is called APC in PHP 5.5 and below.

Check thephp-errors.log for errors similar to this one:

Warning: require_once() [function.require-once]: Unable to allocate memory for pool.

This value can be changed under APC memory settings(this is called APC in PHP 5.5 and earlier) through the Acquia Cloudweb site for our Acquia Cloud Professional and Acquia Cloud Enterprise products (more information in Configuring PHP Settings ) or through a support ticket for our Site Factory customers.

There is a tool available that will help you analyze what is in OPCache for your application: https://github.com/rlerdorf/opcache-status.

OPcache Interned Strings buffer

The Interned Strings buffer isthe amount of memory (in M) used to store identical strings (detected by PHP). By default, this is a shared buffer allowing all Drupal PHP processes to reference it across multiple PHP/FPM processes - saving memory.

Drupal 8 applications, in general, make greater use of the interned strings buffer, we recommend that you check the fpm-error.log for the following type of error

[23-May-2017 18:53:47] WARNING: [pool sitegroupname] child 19109 said into stderr: "Tue May 23 18:53:47 2017 (19109): Warning Interned string buffer overflow"

This value can be changed under OPcache interned strings buffer through the Acquia Cloudweb site for our Acquia Cloud Professional and Acquia Cloud Enterprise products (more information in OPcache interned strings buffer ) or through a support ticket for our Site Factory customers.

APCu or APC user_cache errors

APC User cache is PHP the part of APCthat is not a part of OPcache. It wasrarely used in Drupal 7(for example, the default Acquia Valueapc.shm_size=8M is ok for most sites).

In general, Drupal 8 sites make much greater use of the APC user cache. For a single web site, we recommend increasing the PHP user cacheapc.shm_size=16M or the default PHP value of 32M. If you are using our Site Factory applications, or a larger multi-site, you may need to increase the APC user_cache setting even further.

A clear sign that the APC User cache is set too small is this type of error in your php-errors.log:

[20-Feb-2017 13:54:16 America/New_York] PHP Warning: apcu_store(): Unable to allocate memory for pool. in /mnt/www/html/somenamedev/docroot/core/lib/Drupal/Core/Cache/ApcuBackend.php on line 177

Having your application try to allocate too much information in a small cache can result in slow site performance, and 'hung' PHP/FPM processes that cause your site to fail.

This value can be changed under APCu size through the Acquia Cloudweb site for our Acquia Cloud Professional and Acquia Cloud Enterprise products (more information in APCu size ) or through a support ticket for our Site Factory customers.

See this article How to monitor and tune APCu for additional tips and tools to improve the performance of your application.

See the following references for information about how to find, and search through your log files:

Searching the error logs to troubleshoot problems

About Acquia Cloud logging

Acquia Products

Acquia Cloud

Topics

drupal7

drupal8

php

External Links

How investigate Memory Consumption problems

Configuring PHP settings

set_time_limit()

https://github.com/rlerdorf/opcache-status

Opcache interned strings buffer

APCu size

How to monitor and tune APCu

Searching the error logs to troubleshoot problems

About Acquia Cloud logging

Problem

You're troubleshooting a problem with a part of your application that deals with the session data (temporary user preferences, shopping cart data, etc.) that Drupal stores in its database for authenticated users on your site. You've logged in, and can reproduce the problem by requesting a page as a logged-in user. However, you'd like to track that logged-in user's session back to the database in order to check the data currently associated with it.

Solution

In order to accomplish this, you'll need to retrieve thesession ID of your user's current login session. This session ID is stored in a cookie in your site's web browser when you initially log in, and this cookie is sent with every subsequent request to your site from that browser. Drupal uses this identifier to determine that a request is from a specific authenticated user, and retrieve information from the database (stored in a table called "sessions") that may have been set for your user previously during your current login session.

Before we begin:

Please note that if someone has access to your session ID, they'll be able to log into the site as your user until that session is deleted or expires. For this reason,you should be extremely careful when sharing or publishing session identifier information, as it could be used to gain unauthorized access to the Drupal user account on your site.

If you've already logged in to Drupal and can reproduce this problem in your web browser, finding the ID of your current login session is as simple as reading that cookie's value from your web browser:

Make sure you're logged into your Drupal site.

Open your web browser's cookie management page

In Google Chrome, open the "Settings" page, click "Show advanced settings", and under the Privacy section, click "Content Settings". Then, under "Cookies", click "All cookies and site data" to open the cookie management page (or simply click here ).

In Mozilla Firefox, open the "Preferences" page, and click the "Privacy and Security" tab (or simply click here ). Under the "History" section, click the "delete individual cookies" link to open the cookie management window.

In the cookie management window, locate the cookies that correspond to your Drupal site (e.g: "www.example.com"), and look for a cookie whose name starts with "SESS" or "SSESS".

View the cookie described in Step 3. The session ID will be the "Content" or "Value" of this cookie.

You can can use this ID to look up your session in your site's database, in the "sessions" table, under the "sid" column.

Ifyou can't log in as the affected user, or want to find the session ID for another Drupal user, you can look up that identifier (and the data associated with it) directly in the "sessions" table of your site's database. All you'll need is the numeric user ID of the user you'd like to look up (e.g: the user ID of your site's administrative user is 1). You can query the database for entry with a value in the "uid" column that matches this user ID. However, please note that a single user ID may have multiple active sessions associated with it (e.g: if a user is logged into your Drupal site on multiple web browser). Also, if your site sets user data for anonymous users (i.e: user ID 0), looking up a value in the "uid" column won't be an effective way to narrow in on an individual user's session.

Reduce Memory consumption in Comoposer builds by removing legacy symfony tags

Problem:

Out of control Memory use on Composer builds got you down? Running out of memory on Pipelines builds?

Consider adding the composer optimizations project, to remove legacy symfony builds with:

composer require zaporylie/composer-drupal-optimizations

See more information about the project: https://github.com/zaporylie/composer-drupal-optimizations

and Check out Jeff Geerlings' blog post https://www.jeffgeerling.com/blog/2018/make-composer-operations-drupal-way-faster-and-easier-on-ram

Issue

Pipelines builds that run "composer install" are failing with this, or similar, message in pipelines logs:

Killed composer install -v

You may also see the following, with no detail.

System Failure

Pipelines container running out of memory is one way that pipelines can run into a system failure.

Resolution

Check the "composer.lock" file into your code repository. This will reduce the memory requirements of running "composer install" in this pipelines container.

Cause

Resources on the pipelines container are limited, and exceeding those limits can cause pipelines jobs to fail. Those resources defined here: https://docs.acquia.com/acquia-cloud/container/resources/

Running "composer install" without a lock file will use a LOT more memory than running the same with the lock file. This can be demonstrated by running the following tests:

Test memory usagewithout lock file:

Remove vendor folder (rm -rf vendor)

Clear composer cache (composer clearcache)

Remove composer.lock file (rm composer.lock)

Run an install and report memory consumption (composer install --profile)

[258.2MB/109.74s] Memory usage: 258.23MB (peak: 496.64MB), time: 109.74s

Test memory usagewith lock file:

Remove vendor folder (rm -rf vendor)

Clear composer cache (composer clearcache)

Run an install and report memory consumption (composer install --profile)

[8.1MB/64.02s] Memory usage: 8.13MB (peak: 49.72MB), time: 64.02s

In the test outlined above, running "composer install" with the lock file in place used8.13MB of memory.

Running "composer install" without the lock file and forcing composer to generate it used258.23MBof memory for the same project.Acquia Products

Acquia Pipelines

Topics

Pipelines

External Links

https://docs.acquia.com/acquia-cloud/container/resources/

If you're an Acquia customer and are expecting an event that will send a significant amount of traffic to your website, we encourage you to contact Acquia Support in advance, so that they can help you prevent a website outage. Events that can cause enough traffic to affect your website's availability include:

Website launches

Marketing campaigns

Performances

Creating a support ticket

To help prevent a website outage during a traffic event, contact Acquia support and provide as much of the following information as you can:

The date and time of the website launch or event (including the timezone).

The expected website traffic during the event.

Will traffic be primarily either authenticated user traffic or anonymous traffic?

Will the entire website see increased traffic, or just specific URLs?

The more accuracy that you can provide, the better Acquia Support's recommendations will be. For example, if your website expects mostly anonymous traffic, and not authenticated traffic, aggressive caching may be a better (and less expensive) option.

You may be asked if you would like for Acquia to upsize your server based on load for you. This often involves an additional cost, and you may wish to involve your account manager. Acquia Cloud Enterprise customers may be upsized without warning, based on their contract, in order to maintain service during unexpected demand.

Logs on Acquia Cloud are not kept in the event of upsizing. If you want to ensure that logs are stored permanently, you should routinely copy log files to permanent storage. Learn more.

If an upsize is requested, be as prepared with as many details as possible on the specific anticipated amount of authenticated versus anonymous high traffic.

Note

Acquia recommends providing notice at least seven days in advance of an expected upsize.For more information about resizing your server, see the Resize section of the Managing your servers Acquia Cloud documentation.

If you are using elastic load balancers (ELBs), you may also find Amazon's suggestions on pre-warming the load balancer useful. ELBs are not intended to handle traffic spikes -they're intended to handle a steady increase in traffic. The balancers should be set to expect the highest level of traffic before the test begins.

If you think this may be necessary for your event, contact your Acquia account manager for details, and be prepared to provide the following information:

What is the DNS name for the ELB(s) that require manual scaling?

An approximate increase percentage in traffic, or expected requests/sec that will go through the load balancer (whichever is easier to answer).

The average amount of data passing through the ELB per request/response pair.

The rate of traffic increase expected. This can be a qualitative value such as "this should increase steadily over the span of an hour," or "we expect traffic to increase suddenly once our sale/event is announced."

Expected percent of traffic going through the ELB that will be using SSL termination.

Is the back-end currently scaled to the level it will be during the event?

When will your event start?

When do you expect the event will end?

A brief description of your use case, with a detailed explanation of your expected (if you're going to deviate from the normal request pattern) and normal traffic patterns.

Website launch recommendations

If your anticipated event is a website launch, we recommend reviewing the prelaunch checklist to ensure that you have addressed the basics of website readiness requirements.Topics

high traffic

traffic spike

Issue

What can cause Drupal cache to be cleared accidentally?

Resolution

Drupal cache-clearing functions use a$wildcardvariable when set, they can be used to empty the entire cache. They're commonly used, but can cause a number of problems. Using a wildcard clear with Memcached can cause the accidental clearing of items that you want to remain in the cache.

Accidentally clearing your cache

Contributed modules may use the generic Drupalcachetable. However, a wildcard cache clear causes Memcached to wipe an entire bin. In the case of thecacheorcache_bootstraptable, this forces the variable cache to be rebuilt.

When used incorrectly, two Drupal functions, cache_clear_all and variable_set, can also dump all of your cache entries. Any method of clearing the entire cache (includingdrush cc all) can have a significant impact on website performance, because every request will have to be fulfilled from the origin server until the cache is rebuilt.

Preventing an accidental cache clear

Checking all cache-clearing calls in your code before deployment is a good start, but it's easy to miss one in the process.

Memcache

Because of Memcached's architecture, the Memcache module has to treat each wildcard clearing as a purge of an entire bin. For example, if a module uses the main cache bin and does a wildcard clearing of its cache items, the main cache bin is the one that gets purged. The main cache bin includes variables and the schema cache. In a multiserver cluster, this can lock the database.

For websites that you plan to deploy with Memcache, you should audit calls to cache_clear_all ( ). Look for this behavior since performance problems may not be apparent until the website is experiencing live traffic.

cache_clear_all

If you're using this in your codebase, make sure it's there for a good reason. Documentation oncache_clear_allfor Drupal 7 is available. This function can remove part of your cache, or all of it. This can be extremely useful either when content is updated or when new content is generated, but if this isn't used carefully, you can inadvertently cause website slowness.

Drush users can also use drush cache clear or drush cache rebuild. Users with a multisite installationcan clear on a per-site basis.

$ drush --uri=$SITE cache-clear all

variable_set

Documentation onvariable_setis here for Drupal 7.

If you suspect or just want to check to see if there are issues withvariable_set, you can use some debugging codeto watch what this function is doing.Topics

cache

drupal7

performance

External Links

cache_clear_all

variable_set

drush_cache_clear

drush_cache_rebuild

Multisite definition

Debugging using debug_backtrace

The Akamai module for Drupal 8 stores the Purge status in a key_value pair. On a busy site with many content updates, this can create performance problems as keeping track of a large amount of data in a single table row is poor design.

An example of how this key_value can grow to the point where it's not-performant, this is the size of this table relative to other tables on the same site.

+-----------------------------------------+-------------+

| name | Size in MiB |

+-----------------------------------------+-------------+

| akamai.purge_status | 10.04 |

| media.field_storage_definitions | 0.04 |

| node.field_storage_definitions | 0.04 |

| paragraph.field_storage_definitions | 0.03 |

This drupal.org issue describes an alternate design https://www.drupal.org/project/akamai/issues/3001392

We recommend:

Disable the Akamai module.

Use the Purge and Acquia Purge module. With those youhave Cache tag based content purging enabled on your CMS. These work well with Content Delivery Networks like Akamai

Set the Edge Cache TTL (Time To Live) low 1 minute - 5 minutes depending on your application requirements.

Browser Cache TTL 1 minute, or the same value as Edge Cache TTL

Occasionally, an application may require a shorter Edge Cache TTL lifetime. If you reduce the amount of your Edge Cache TTL, be sure to change the Browser Cache TTL to the same value.

When configured properly, the Acquia Purge module will cause content updates to purge selected portions of Varnish cache. The next time Acquia Cloud Edge CDN requests the asset from Varnish, it will receive the newly-updated content.

If you need to have the Akamai module installed, then from from the purge settings, /admin/config/akamai/config set the Purge Status expiryto0

Issue

Your site is experiencing a traffic spike, and you'd like to know more about where the traffic is coming from, or what is being targeted.

Resolution

If youre noticing that your site is responding more slowly than normal, you can use the Acquia Log Streaming tool to see if youre receiving more traffic than usual.

But how do you determine if there are patterns to the traffic?

You will need the raw logs to analyze. You can download these from the Log Streaming page, or you can SSH in to the server.Accessing the logs via the Acquia Cloud log streaming interface is quick, but provides limited search customization. Accessing the logs via SSH will allow greater search flexibility. Here are some examples:

Find the most frequent IP addresses

awk '{print $1}' access.log| sort | uniq -c | sort -nr| head

What can I do with this information?

If this is malicious traffic, you can block it.

If this is an aggressive bot that you do not want to block at this time, you can increase the crawl-delay in robots.txt. Note that it is up to the bot whether it respects this directive.

If you need this traffic to continue, and your sites performance is being impacted, you can see if these performance recommendations help.

Find the most frequent User Agents

awk -F\" '{print $6}' access.log | sort | uniq -c | sort -nr | head

What can I do with this information?

If this is malicious traffic, you can block it.

If this is an aggressive bot that you do not want to block at this time, you can increase the crawl-delay in robots.txt. Note that it is up to the bot whether it respects this directive.

If you need this traffic to continue, and your sites performance is being impacted, you can see if these performance recommendations help.

Find the most frequent URLs visited on your site

awk -F\" '{print $2}' access.log| awk -F? '{print $1}' | sort | uniq -c | sort -nr | head

This query strips the variables (anything after a question mark in your URL).

What can I do with this information?

If the URLs that appear typically have a variable string at the end, there is a good chance that these are bypassing Varnish if they are varied enough. These are often intentional so the site can process the requests appropriately. If these are required but the sites performance is being impacted, you may want to see if these performance recommendations help, or if an upsize is needed.

If there is no variable string, confirm if Varnish is serving this page.

If it is, but the amount of traffic hitting the webs is impacting performance, increase your page cache maximum age until the traffic subsides.

If it is not, investigate why the site is bypassing Varnish cache. If you need assistance determining why Varnish is not serving the page, contact Acquia Support.

Performance Recommendations

Make sure that Drupal core and all modules are updated. Many updates include performance improvements (and bug fixes) that can make a big difference in how your site responds.

Increase the page cache maximum age. If you are concerned about stale content remaining on the site after an update, Acquia Purge can prevent this.

Make sure dblog is disabled. Dblog writes log entries to the database, which can cause a performance impact. We recommend syslog.

Do not include memory limit overrides in settings.php. If you need a higher PHP memory limit for certain pages, we recommend increasing the limit just for these specific pages.

Enable memcaching.

Check for opcache errors.

Acquia Products

Acquia Cloud

External Links

Restricting website access

Introduction to Varnish

Varnish: Bypassing the cache

Acquia Support

Using Varnish

Installing Acquia Purge

Conditionally increasing memory limits

Improving application performance

Using Memcached

Understanding and Resolving PHP OPcache and OPcache Interned Strings buffer errors

On 30 July 2018, the Drupal security team issued DRUPAL-PSA-2018-07-30 advising of a moderately critical security release for an update to a vendor library only for Drupal 8.

It is advised that customers set aside time to plan for a core upgrade immediately following the release on 1 August 2018 between 16:00:00 - 19:00:00 UTC (12:00pm - 3:00pm EDT/ 9:00am - 12:00pm PDT).

Remote Administration

For customers with Remote Administration (RA) services, Acquia will begin providing security updates immediately following the release on August 1. However, due to the large volume of applications we update, customers should expect to receive an update within 48 hours of the update being released. We highly recommend you plan to move this update to your production environment as soon as you can.

Note for Drupal 8.3.x and 8.4.x users: RA automation will update your application to the currently supported 8.5.x release. This release will not be backported to 8.3.x and 8.4.x as these branches are no longer supported. You should consider moving off of these branches to the 8.5.x branch as soon as possible.

For customers still on the 8.3.x and 8.4.x branches, if you wish to remain on these branches, we recommend you update the vendor library on your end independently of Drupal core. This is outside of the scope of Remote Administration.

As soon as you receive an update ticket from us we strongly recommend you test and respond as soon as possible to update your production application. Acquia will not move forward with updates until they are tested and explicitly approved in the RA ticket.

Platform Mitigation

Acquia has developed and implemented a mitigation to the Acquia platform based on the Drupal core release ( SA-CORE-2018-005 ) issued Wednesday, 1 August 2018. This mitigation covers all customers with Acquia Cloud Free, Acquia Professional, Acquia Cloud Enterprise, and Acquia Cloud Site Factory applications. We highly recommend Acquia customers apply this Drupal core security update regardless of Acquias platform mitigation.

Additional Questions

Should you receive an update ticket and are already in the process of updating your application, no further action is required. Simply set the ticket to solved.

This article will be updated as new information becomes available.

Last updated: {2-August-2018 / 17:01:00 UTC}

Release Date2018-07-31

Issue

Your Drupal site is triggering warnings that mention igbinary, similar to (but not limited to) the following:

Warning: igbinary_unserialize_header: unsupported version: [NUMBER], should be [...]

Warning: igbinary_unserialize_header: unsupported version: "[STRING]"..., should begin with [...]

Warning: igbinary_unserialize_zval: unknown type [...]

Warning: igbinary_unserialize_chararray: end-of-data in [...]

Resolution

Add this configuration in the Memcache section of your site's settings.php file:

// Force memcache to use PHP's core serialize functions

$conf['memcache_serialize'] = 'serialize';

Cause

Later versions of the Memcache module default to using theigbinaryserializer, however, within Acquia Cloud the best practice is to use the PHP native serializer.

If you are usingself-service SSL through the Acquia Cloud UI, with the SSL certificate on an Elastic Load Balancer (ELB), a bare domain will not work with this certificate. With an ELB, the only DNS available is a CNAME, which means that bare domain names are not supported because bare domains only support an IP in the A-record, and not a CNAME.

Domain name providers that support ALIAS/ANAME records can be used to work around this issue. One method that's available to Acquia Cloud Enterpriseand and Acquia Cloud Site Factorywebsites, allowing them to use bare domains, is to use Acquia Cloud Edge.

Another way around this is to use Amazon's Route 53 to host your DNS, which allows you to point your bare domain directly to the ELB. Amazon's documentation describes the steps necessary to route a bare domain name to an ELB using Route 53.

Customers who elect to host their DNS through Amazon's Route 53 service will be responsible for setting up and configuring their DNS records and troubleshooting any issues that may arise.

Here's an example of how to configure Route 53 services:

Go to the Route 53 admin interface.

If your domain DNS isn't currently hosted through Route 53, click the Add Hosted zone button to add the domain to Route 53.

In Route 53, select your newly added domain, and click Go to Record Sets.

Click Create Record Set, and then enter the following values:

Name: Leave the default for the bare domain.

Type: Click A - IPv4 address.

Alias: Click Yes to use a hostname rather than an IP address.

Alias target: Enter the hostname of the ELB as it is listed in your [acquia-product:ais] UI.

After you've saved the record set, you'll need to go to your domain provider and update your name servers to point to the Amazon name servers as reported on your Route 53 dashboard. These name servers are listed under Delegation Set. After the DNS for the domain name has propagated (24-48 hours), your bare domain name will point to the ELB of your load balancer.

Other possible providers

Acquia Support has also been informed that the following DNS providers may support the following record types:

DNSimple: ALIAS

DNS Made Easy: ANAME

easyDNS: ANAME

Acquia Products

Acquia Cloud

Acquia Cloud Site Factory

Topics

ssl

domain

External Links

Amazon Route 53

Amazon Documentation for Route 53

Zone Record at Dyn

File permissions on Acquia Cloud and other Acquia offerings require careful handling when you are changing code or other files on your website. For security reasons, write permissions are disabled in both the live website and in the website repository. This prevents malicious individuals from attacking not only your website, but also your website's repository.

Your website has three major areas: the docroot (where the website is actually served from), the repository (where a duplicate of your codebase and PHP files are stored), and the distributed file system. The docroot is not a writable area. Any folder with an activesettings.phpfile (often found insites/default/files) will add a symlink to the distributed file system. With the symlink in place, files placed in distributed file system appear as though they are located within the file directories where Drupal expects them to be without requiring write access to the code repository files in the docroot.

Note

We recommend the use of relative symlinks on Acquia Cloud to ensure that symlinks remain correct across server environments.

Anatomy of your website

This figure shows the directory structure of a generic website, from repository to docroot, and where the symlink lies within that docroot.

simplesamlphp_auth Anatomy of the docrootUnderstanding how this works is important because without the right permissions, your website may fail to work in ways that are either simple or completely confusing. This can be a problem when you expect things to stay the way that you set them in version control. Git, for example, does not store any permissions (aside from the executable bit). Read and write, sticky, or Access Control List (ACL) bits are lost when you commit changes. For more information, see What does git do to files that are a symbolic link?

If you're experiencing a problem with permissions, you might see an error like the following:

file system: The selected file /mnt/tmp/mystg/filemyfile could not be uploaded, because the destination sites/default/files/js/myjsfile.js could not be found, or because its permissions do not allow the file to be written.

In multisite installations, things can be a bit trickier. Because these websites all can share the same codebase, they also can share the same symlinks.

Note

If you have one website directory symlinked to another in the Acquia Cloud system, when a symlink is created, it will take on the name of the first website in the directory by alphabet. This means that if you have two websites,docroot/sites/test, anddocroot/sites/a-test, regardless of which website the symlink was initially created under, the symlink will use the pathdocroot/sites/a-test.

The best practice is to symlinkonlythe directory that needs write access. As an example, to create the correct links for a module that needs its own cache directory, you would use commands like this:

Note

These instructions delete a directory; before you process the delete (rm -rf), ensure that you have copied the files to the new location or to local storage for later replacement.

git clone [email protected]:yoursitename.git

See the instructionsto checkout your code.

cd yoursitename/docroot/sites/all/modules/examplemodule

rm -rf cache

ln -s ../../../default/files/cache cache

git add cache

git commit -m "creating symlink for examplemodule cache"

git push origin master

Once this is completed, you will need to access the server and create the newcachedirectory in yourfilesdirectory. If not, when the code is deployed, the symlink will point at a non-existent target. Once you've created the directory, use either SCP (Secure Copy) or SFTP (Secure File Transfer Protocol) to transfer any files you had temporarily stored and need to replace.

Known problem modules

With the Acquia Cloud setup, several modules are known to have problems because they require the ability to write to their own module folder. You will need to link modules to the files area.

CKFinder

TCPDF

Contact Importer (due to its reliance on Open Inviter )

HTML Purifier

WURFL

SimpleSAMLPHP Authentication

This is by no means a complete list, and you may also need to link additional modules to the files area.Drupal Projects

WYSIWYG-CKFinder

tcpdf

contact_importer

htmlpurifier

wurfl

Git is a distributed system for version control, as well as for source code maintenance. You can use Git to manage all of your code revisions for your Drupal websites.

Git is one of the most popular version control systems available. The following documentation, references, and tutorials are handy for understanding Git and the concept of a distributed version control system (DVCS).

Getting started

Git basics

Acquia's article on the basics of using Git.

Git Immersion

Recommended resource for step-by-step instructions on how to use Git.

Learn Git

Code Academy's course on learning Git.

Introduction to Git on Drupal.org

Git terms and concepts, and how they relate to Drupal.

Introduction to version control

BuildAModule's introductory resource for learning Git.

Understanding Git Conceptually

This site provides a simple tutorial on understanding Git concepts.

Visualizing Git Concepts with D3

Visual demonstrations of Git concepts.

Additional References

Using Git on Drupal.org (Video)

This is a screencast that explains how to set up a new user, create a development environment, and use Git to commit what you develop.

Official Git Tutorial

A Git tutorial that explains how to import a new project into Git, make changes, and distribute those changes to others.

Git training site

A reference site for finding and learning Git commands, provided by GitHub.

Pro Git

A free, online version of the book Pro Git (Apress 2009), written by Scott Chacon.

Git Magic

A free, online version of the book Git Magic (CreateSpace 2010), written by Ben Lynn.

Intro to Distributed Version Control (Illustrated)

This site provides an illustrated explanation of a distributed version control system (DVCS).

Topics

git

Take a look at the ACSF Tools (https://github.com/acquia/acsf-tools) project. It includes, among other things, a drush command to generate your alias file for you, as well as a drush command to run any other drush command against all sites in the factory (acsf-tools-ml).Acquia Products

Acquia Cloud Site Factory

Topics

drush

drush aliases

Drupal Projects

drush

External Links

Issue

I see errors in the PHP error log. What do they mean?

Resolution

PHP's error log is where you will find most of the problems caused by faults in PHP, whether those faults are caused by problems in the code itself, or by the code being unable to function properly due to other issues. Problems you might find include out-of-memory errors (OOM), undefined exceptions, and so on.

While you should ensure that the PHP error log is not overloaded with messages, it's also important to ensure that errors in the production environment are logged in case problems do arise. Failure to log these errors can cripple your ability to troubleshoot an issue. In most cases, disablingNOTICEmessages is enough to keep the messages down to critical notifications. To suppress these, place this code into yoursettings.php file:

if (isset($_ENV["AH_PRODUCTION"]) && $_ENV["AH_PRODUCTION"] == 1)

{ error_reporting(E_ALL & ~E_NOTICE & ~E_DEPRECATED & ~E_STRICT); }

See the PHP page on error_reporting() for more examples. The method of suppression may change between PHP versions, so be sure to test if you update PHP.

Errors

Allowed memory size of 134217728 bytes exhausted (tried to allocate 19600 bytes) in

/mnt/www/html/sitename/docroot/modules/system/image.gd.inc on line 232

This is a memory exhaustion error and will cause a page load to fail. In this case, it's occurring in the Image module, but it can occur in a number of other modules. This error most often occurs when there's too much data or logic being processed for the standard amount of memory (128 MB) to handle. This is most commonly seen on administrative pages.

You have two possible approaches to this issue. You can troubleshoot the issue, or if you're an Acquia Cloud customer, you can increase your PHP memory limit in the UI. While it may be easier to just increase your PHP memory limit, this can have negative consequences. Higher memory levels can reduce the number of available PHP processes for handling uncached page requests. As a result of that, you may need to resize your server.

Important

Acquia recommends troubleshooting the issue whenever possible, before increasing memory limits. In the event that you need to increase your memory limit, you may find the following Help Center articles useful:

Conditionally increasing memory limits - This can help you increase memory limits for particular processes.

How to change the PHP memory limit - This article explains how to change memory limits in code.

Acquia recommends that you attempt to isolate the root cause of the higher memory usage, especially if the need for memory begins to exceed 192 MB or 256 MB. Beyond this point, there are usually code or configuration changes that would be more beneficial and cost-effective. If possible, determine what code or configuration changes may have taken place that could cause a jump in memory usage. This may not be the sole culprit, as many pages behave normally until a certain point.

If you need help with troubleshooting, you may find the Help Center article on Memory consumption tracking tools to be useful.

Note

Overriding this globally in the site'ssettings.phpfile isnotacceptable on Acquia Cloud because it creates a mismatch between the Acquia server'sexpectedlimit compared to theactualmemory configured for your site, which can cause your server(s) to run out of memory if there is a traffic spike.

Look for resource-intensive queries, modules, views, or functions. Determine if anything has changed in the site's code or configuration that might have caused these alerts to suddenly appear.

Common buffer sizes

For your reference, here's a table of common large buffer sizes that you may encounter in your site's PHP error logs:

Human Readable

Mathematical

Literal (PHP logging)

128 MB

227bytes

134217728 bytes

256 MB

228bytes

268435456 bytes

512 MB

229bytes

536870912 bytes

1 GB

230bytes

1073741824 bytes

4 GB

232bytes

4294967296 bytes

Warnings

[pool sitename] server reached max_children setting (6), consider raising it

This issue is commonly referred to asskip-spawningorrequest queueing. This occurs when a request bypasses caching and hits a web server when there are no available PHP processes to handle it. This results in the request getting queued, which means that pages may be slow to load or eventually time out, resulting in aTemporarily Unavailableerror on the site and HTTP 503errors in your request logs.

You can address this type of issue in a number of ways. Turn on caching, which offloads requests to your load balancers instead of your web servers. You can optimize code and reduce the amount of data loading on a page to allow page requests to complete faster, reducing the likelihood of requests backing up. It's important to balance the need for memory with the number of available PHP processes. If your PHP memory limit is above 128 MB, you are limiting the number of available processes. Consider adjusting the memory limit to best accommodate your site's memory needs with the number of concurrent connections. Finally, if none of the preceding solutions are sufficient or possible, you can upsize your server(s) to gain additional memory and more PHP processes.

Topics

logs

memory

php

Our implementation of SSL uses Server Name Indication (SNI), and that allows you to potentially have multiple environments on the same server, each with its own SSL certificate that you have uploaded through our Acquia Cloud web interface.

When making more traditional ssl connections, you use a syntax to connect to the IP of the server.

For exampleopenssl s_client -connect dev.yourdomain.com:443

This will return the SSL certificate that's installed on the server, but since it looks for the certificate by IP - and doesn't pass the-servernameargument you get the default certificate (Acquia's certificate) and not the certificate you installed via the Acquia SSL upload tool

and you may get a Certificate Error message that looks like this:

[Thr 140052323628800] Peer not trusted

[Thr 140052323628800] Certificate

[Thr 140052323628800] Certificate

[Thr 140052323628800] Subject :[email protected], CN=*.acquia-sites.com, OU=Acquia Hosting, O=Acquia Inc,

[Thr 140052323628800] Issuer :[email protected], CN=acquia.com, OU=Hosting, O=Acquia Inc, SP=MA, C=US

[Thr 140052323628800] Serial number :0x06

[Thr 140052323628800] Verification result

[Thr 140052323628800] Status :Not successful

[Thr 140052323628800] SignerStatus :Not successful

[Thr 140052323628800] SignerVerificationResult :None

To be able to successfully negotiate a connection with an SNI type certificate, the-servernameargument must be used, this isfundamental to the protocol.

This successful command correctly uses the-servernameargument:

openssl s_client -showcerts -servername dev.yourdomain.com -connect dev.yourdomain.com:443

Keep in mind that the SSL negotiation must occurpriorto sending the HTTP request through to the remote server. That means that the browser and the server have to do the certificate exchange earlier in the process and the browser wouldnt get the opportunity to specify which site its trying to reach. SNI fixes that by allowing aHost:header type of exchange during the SSL negotiation process.

Issue

How can I evaluate a slow query log?

Resolution

One serious performance-impacting area on websites is queries, because slow queries cause slow page loads. This article provides several methods that you can use to log and examine your website's slow queries.

Enable logging of slow queries

On Acquia Cloud, queries running longer than one second are logged by default. Read about downloading a slow query log in our documentation. Otherwise, refer the site's database administrator to MySQL's documentation regarding slow query logging.

Typical slow query log entry

This is an example of a typical entry from a MySQL slow query log:

# Time: 130323 8:41:20# User@Host: username[username] @ database-1234.prod.hosting.acquia.com [127.0.0.1]# Thread_id: 738333 Schema: databasename Last_errno: 0 Killed: 0# Query_time: 1.459942 Lock_time: 0.000000 Rows_sent: 0 Rows_examined: 0 Rows_affected: 1 Rows_read: 0# Bytes_sent: 11 Tmp_tables: 0 Tmp_disk_tables: 0 Tmp_table_sizes: 0# InnoDB_trx_id: 14AE3A4use databasename;SET timestamp=1364028080;INSERT INTO semaphore (name, value, expire) VALUES ('variable_init', '2082304334514d6aaf7a92c8.53638468', '1364028080.4921');

Lines beginning with the pound sign (#) provide metainformation about a query, including when the query was logged, the user that executed the query, and the time it took for the query to complete. After the metainformation, the log might include an optionaluse databasestatement and an optionalset timestampquery, and then the slow query itself.

Analyze logs using Percona Toolkit for MySQL

The Percona Toolkit for MySQL (formerly known as Maatkit) is a collection of useful command-line utilities for database administration. It includes the pt-query-digest utility, which can produce a summary of the entries in a slow query log. You can download this utility individually using the following command:

wget http://percona.com/get/pt-query-digest

In order to execute the script, set the executable bit on the file:

chmod +x ./pt-query-digest

Finally, run the tool with the slow query log as an argument, being sure to redirect its output to a separate file:

./pt-query-digest /path/to/slow-query-log.sql> digest-output.txt

Note

When you download your website's slow query log, it only downloads the current day's log file. Your Acquia MySQL Statistics page may show past slow queries, so your log file may not contain everything you see on the Please Replace These Missing Tokens.

By default, the digest produced bypt-query-digestwill have a summary of the top 5-10 slowest queries based on the total response time. The summary table shows how many times the query was performed and the average time per query. Following the summary are detailed statistics of each slow query, with representative examples of the queries.

Review slow query logs in other ways

The MySQL server installation includes a rudimentary utility, mysqldumpslow, that you can use to review slow query logs.

There is also a MySQL slow query parser on GitHub that converts your slow query logs into a more usable format.Acquia Products

Acquia Cloud

Topics

percona

performance

mysql

External Links

Downloading a slow query log

Slow Query Log MySQL documentation

Percona Toolkit for MySQL

pt-query-digest Percona reference

mysqldumpslow MySQL documentation

MySQL slow query parser on GitHub

On 16 February 2016, a libssh security vulnerability was announced (see CVE-2018-10933 for additional details.)

A vulnerability was found in libssh's server-side state machine before versions 0.7.6 and 0.8.4. A malicious client could create channels without first performing authentication, resulting in unauthorized access.

Q: Is my site affected?

At this time, Acquia has performed an analysis of this vulnerability. Acquia's standard platform configuration mitigates this vulnerability. At this time, we have no reason to believe that Acquia or any of its customers' sites are impacted by this vulnerability.

Note: LibSSH vs LibSSH2

LibSSH is a distinct project that is separate from LibSSH2. LibSSH is not used on the Acquia Cloud Platform, while we are removing support for algorithms used by versions of LibSSH2 below version 1.7.0. For more information on the difference between these two projects see: "libssh2 vs libssh - A comparison".

If you have any questions, you can contact Acquia Support by creating a ticket at https://insight.acquia.com/support or visiting the Help Center.Acquia Products

Acquia Cloud

Acquia Cloud Enterprise

Acquia Cloud Site Factory

Release Date2018-10-23

External Links

libssh2 vs libssh - A comparison

CVE-2018-10933

Introduction

You can use two major methods to instruct Varnish to redirect a URL: use a module, or edit the.htaccessfile. Acquia Cloud caches 301 redirects in Varnish for a minimum of 15 minutes by default. If you need to change the length of time the 301 is cached, you can use one of the following methods:

Note

Although 302 redirects can also be cached, the default Acquia VCL does not cache 302 redirects. Because of this, caching these responses requires a custom VCL.

Redirect module (Drupal 7)

The Redirect module creates the max-age header that is sent to Varnish for redirects. The header is also created later when you enableAllow redirects to be saved into the page cachein the module's settings.

Custom VCL The Redirect module cache settings also apply to other redirects. You can override these on a global or per redirect basis.

Note

Starting with Drupal 7.4 you no longer need to set the$conf['page_cache_invoke_hooks']variable.

Redirects using .htaccess

To set Varnish-cachable 301 redirects from.htacess, you must set an environment variable usingmod_rewriteand conditionally add caching headers with mod_headers. Because Acquia Cloud already sets a 15 minute cache, this variable is only needed if you want to cache in Varnish for more than 15 minutes.

As an example, this is an.htaccessrule to create a 301 redirect fromhttp://example.com/foo/*tohttp://example.com/bar/*that Varnish will cache for two weeks:

RewriteRule ^foo/(.*)$ http://example.com/bar/$1 [R=301,L,E=longcache:1]

Header always set Cache-Control "max-age=1209600" env=longcacheAcquia Products

Acquia Cloud

Acquia Cloud Site Factory

Topics

.htaccess

drupal7

drupal8

varnish

Drupal Projects

redirect

External Links

Issue

The Boost module creates static copies of a website's webpages in an attempt to improve the website's perceived performance for website visitors.

Resolution

Due to both of these reasons, while Boost is perfectly acceptable for use on single-server websites that don't use a network-attached file system, Acquiadoes notrecommend using it with Acquia Cloud-hosted websites.

Cause

Anonymous website visitors are served static pages instead of Drupal having to access its database to create a webpage from scratch, which can be noticeably faster for website visitors depending on the complexity of the webpage.

This technique is effective on traditional single-server websites. However, because of Acquia Cloud's infrastructure, any improvement Boost can offer is superseded by Varnish caching. Comparing the two methods, Boost saves its static webpages as files; Varnish serves its cache from memory on load balancers. Because of this, Varnish can serve webpages much faster to website visitors.

Also, with Boost enabled, the increased interaction with the distributed file system on Acquia Cloudcan negatively impact the server. Boost uses file system reads and writes with great frequency when setting and accessing the page cache, which can cause the server to experience heightened CPU usage.Acquia Products

Acquia Cloud

Topics

drupal7

Drupal Projects

boost

External Links

Module incompatibilities with Acquia Cloud

Possible solution 1:

Add the following block of RewriteRule(s) to your.htaccessfile, directly after the RewriteEngine On statement:

RewriteBase /

# If there are caps, set HASCAPS to true and skip next rule

RewriteRule [A-Z] - [E=HASCAPS:TRUE,S=1]

# Skip this entire section if no uppercase letters in requested URL

RewriteRule ![A-Z] - [S=28]

# Replace single occurance of CAP with cap, then process next Rule.

RewriteRule ^([^A]*)A(.*)$ $1a$2

RewriteRule ^([^B]*)B(.*)$ $1b$2

RewriteRule ^([^C]*)C(.*)$ $1c$2

RewriteRule ^([^D]*)D(.*)$ $1d$2

RewriteRule ^([^E]*)E(.*)$ $1e$2

RewriteRule ^([^F]*)F(.*)$ $1f$2

RewriteRule ^([^G]*)G(.*)$ $1g$2

RewriteRule ^([^H]*)H(.*)$ $1h$2

RewriteRule ^([^I]*)I(.*)$ $1i$2

RewriteRule ^([^J]*)J(.*)$ $1j$2

RewriteRule ^([^K]*)K(.*)$ $1k$2

RewriteRule ^([^L]*)L(.*)$ $1l$2

RewriteRule ^([^M]*)M(.*)$ $1m$2

RewriteRule ^([^N]*)N(.*)$ $1n$2

RewriteRule ^([^O]*)O(.*)$ $1o$2

RewriteRule ^([^P]*)P(.*)$ $1p$2

RewriteRule ^([^Q]*)Q(.*)$ $1q$2

RewriteRule ^([^R]*)R(.*)$ $1r$2

RewriteRule ^([^S]*)S(.*)$ $1s$2

RewriteRule ^([^T]*)T(.*)$ $1t$2

RewriteRule ^([^U]*)U(.*)$ $1u$2

RewriteRule ^([^V]*)V(.*)$ $1v$2

RewriteRule ^([^W]*)W(.*)$ $1w$2

RewriteRule ^([^X]*)X(.*)$ $1x$2

RewriteRule ^([^Y]*)Y(.*)$ $1y$2

RewriteRule ^([^Z]*)Z(.*)$ $1z$2

# If there are any uppercase letters, restart at very first RewriteRule in file.

RewriteRule [A-Z] - [N]

RewriteCond %{ENV:HASCAPS} TRUE

RewriteRule ^/?(.*) /$1 [R=301,L]

Possible solution 2:

Use the Transliteration module for fileswhich has the option to transliterate existing paths.

Possible solution 3:

This has also been documented in the following Drupal.org issue Make Drupal handle incoming paths in a consistent and case-insensitive fashion for routing Acquia Products

Acquia Cloud

Drupal Projects

https://www.drupal.org/project/transliteration

https://www.drupal.org/node/2075889

Issue

The "Fulltext Ngram" fieldtype available inthe Drupal 8 moduleSearch API Solr(which enables partial-word matching) does not seem to work with an Acquia Search backend.

Resolution

Pick the Solr configuration file set for your Acquia Search Solr cores that is compatible with Search API Solr:

Log into the Acquia Cloud UI

Go to Applications > [your application name] > Acquia Search > "Edit"

Under"Acquia Search configuration set", pick the one compatible with Search API Solr 8.x-1.x. Screenshot below:

Drupal.org issue #2896432

Do wait a few minutes for changes to be deployed into the Acquia Search Solr instance.

From your Drupal site, trigger a full reindex, and after finishing, do wait a few more minutes (3-5) for the index changes to become available in queries.

Clear your Drupal caches. Clearing your Varnish cache is also recommended.

Additionally, remember that any Drupal View that tries to query this "Fulltext NGram" fieldtype should have this setting within any Fulltext Search filter:

Cause

Previously-available Solr configuration files crafted by the Drupal community did not properly implement NGram fields. See .

Problem

Your site is down, and you're receiving an error message with the following large, bold text:

"This server is experiencing technical problems. Please try again in a few moments. Thanks for your continued patience, and we're sorry for any inconvenience this may cause."

Solution

This error message indicates that the error preventing users from accessing your site is being encountered byVarnish, the page caching technology that runs on your Acquia Cloud load balancers. You don't have direct access to logs and configuration files for Varnish, and we'll be more than happy to help you look into any Varnish problems your site may be experiencing. However, there are a few Drupal application configuration issues that are known to cause Varnish problems on Acquia Cloud. Checking your application for the following problematic configuration issues may help you to work around the problem more quickly.

Is page compression enabled in Drupal? Not only is Drupal's gzip compression mechanism not needed on our platform (Varnish automatically saves compressed and uncompressed versions of any pages it caches), but it can also cause problems when Varnish attempts to unzip certain pre-compressed pages before delivery. You can disable Drupal's page compression mechanism on your site by navigating to the "/admin/config/development/performance" page, and under "BANDWIDTH OPTIMIZATION",uncheck the box next to "Compress cached pages.", and click the "Save configuration" button.

Are you delivering a large number of response headers?Varnish on our platform is configured to serve a maximum of60 individual response headers (or a combined 23kb of header data) before responding with an error like the one mentioned above. Drupal applications that set a large number of response headers may cause your server to exceed this limit during the course of delivering a response. Drupal 8 sites experiencing Varnish errors for authenticated users only are likely experiencing a known issue with the "Link" response headers set by Drupal. Luckily, D8 site developers should be able to work around this issue with a simple code fix, as explained in our documentation here.

While the application issues above cause a good portion of the Varnish problems we see on our platform, you may be experiencing a Varnish issue that isn't mentioned above, and whose fix may lie beyond your control. As mentioned before, we're happy to help you look into these issues, and have some additional diagnostic tools that can be run on your load balancers to trace the cause of these Varnish errors. If you'd like our help with one of these issues, simply file a support ticket with the following information:

The URL of the page you were attempting to access when you received the error.

Whether you're receiving the error as an anonymous user, or only when logged-in to Drupal.

A screenshot of the the full error message you're receiving (including all the smaller text below the large header).

This information should help us to more quickly narrow in on the type of error that Varnish is experiencing, and reproduce the problem on our end if needed.

Issue

Is it possible to rename a site collection?

Resolution

Site collections in Acquia Cloud Site Factory cannot be renamed; however, you are able to create a new site collection with the preferred site collection name, and then move the sites into that new collection.

For governance best practices, we recommend naming your site collections with a pattern, e.g. if the site is called www.example.com, then the collection might be called "example-sc". In general, creating a naming standard for your Site Factory site collections is recommended.Acquia Products

Acquia Cloud Site Factory

Topics

site collections

Until a platform-wide solution is in place, the best practices approach is to add the following code to your codebase:

In the `.htaccess` file in the docroot, add

# Ensure non-live sites prevent robots from crawling. This is similar to what

# Acquia Cloud does for the *.acquia-sites.com domains.

RewriteCond %{HTTP_HOST} \.acsitefactory\.com$ [NC]

RewriteCond %{REQUEST_URI} /robots.txt [NC]

RewriteRule ^ no_robots.txt [L]

And add a file called `no_robots.txt` to the docroot with the following contents:

#

# no_robots.txt

#

# This file prevents indexing of domains in the acsitefactory.com DNS zone

#

# See also: https://docs.acquia.com/cloud/configure/domains#robots

#

User-agent: *

Disallow: /

Acquia Products

Acquia Cloud Site Factory

Acquia Drupal was a Drupal 7 distribution that packaged several recommended modules together to make setup of new sites easier. Acquia Drupal has been deprecated in favor of Lightning ( https://docs.acquia.com/lightning, https://www.drupal.org/project/lightning ). Fortunately, uninstalling the Acquia Profile is a simple process.

Create a new development branch locally using git.

git checkout -b <dev_branch_name>

Copy any modules in the acquia profile that your site has enabled and that are not already in your sites/all/modules/contrib directory:

cp profiles/acquia/modules/<module_name> sites/all/modules/contrib/

If you copy acquia_connector from the profiles/acquia/modules directory, youll also want to check the following file:

profiles/acquia/modules/acquia_connector/acquia_agent_drupal_version.inc

You may see:

/**

* Is this an Acquia Drupal install?

*/

define('IS_ACQUIA_DRUPAL', TRUE);

Which should be changed to:

/**

* Is this an Acquia Drupal install?

*/

define('IS_ACQUIA_DRUPAL', FALSE);

Delete the acquia profile from your site:

rm -rf profiles/acquia

Commit your changes to the branch and push the changes:

git add .

git commit -m initials: Uninstalling acquia profile and moving modules to sites/all/modules.

git push --set-upstream origin <dev_branch_name>

Deploy the new branch to one of your non-production environments along with a copy of your production database.

SSH into the environment and run a registry rebuild.

drush @sites registry_rebuild

Visit the site in your browser and test to ensure that everything is working as expected.

Review your logs in the Cloud UI by clicking on the environment header and then clicking on Logs on the left side of the page.

Acquia Products

Remote Administration

Topics

acquia drupal

profile

distribution

drupal7

Issue

How can we successfully integrate Demandbase with Acquia Lift without abandoning the supported Drupal module?

Resolution

Acquia Lift will soon introduce a feature that will allow you to continue to use the Acquia Lift module in conjunction with custom data from sources such as Demandbase without completely moving to Google Tag Manager.

Here's how:

To install, go to Drupal's site configuration > Acquia Lift settings page, and Set Advanced > Bootstrap Mode to Manual.

Save settings.

Open browser and access the JavaScript console, and go to a personalized page. Observe that no Lift content injection personalization, or data collection has occurred since you've set the manual bootstrap mode.

Perform all your pre-personalization steps:

Upddate AcquiaLift object with additional data

Change HTML markup

Once you are done, and want to resume Lift personalization and data collection, call AcquiaLiftPublicApi.personalize(). This can be done by the user (e.g. open browser JavaScript console, and run AcquiaLiftPublicApi.personalize()), or via automation (e.g. via page script or Google Tag Manager).

Cause

In the current release of the Acquia Lift module, the process to integrate custom data sources like Demandbase is complicated by the need to write custom JavaScript to query values using the data source's API.

The next release of the Acquia Lift module (versions after 8.x-3.7, or 7.x-3.4) will add this new feature that willmake the integration processmore straightforward and usable with the Acquia Lift module.Acquia Products

Acquia Lift

Topics

personalization

Drupal Projects

acquia_lift

External Links

Demandbase

Issue

How do I change the contact phone number I have on file with Acquia?

Resolution

Log in to http://accounts.acquia.com. Select "Profile." Click on the blue "Edit" link next to your name. You will then be able to edit both your Office phone number and your Mobile phone number.

An issue has been discovered with the 7.x-2.4 release of the contrib module " xmlsitemap " which may cause sites to go offline, with an error message similar to:

TypeError: Argument 1 passed to xmlsitemap_node_create_link() must be an instance of stdClass, boolean given, called in docroot/sites/all/modules/xmlsitemap/xmlsitemap_node/xmlsitemap_node.module on line 28 in xmlsitemap_node_create_link() (line 194 of docroot/sites/all/modules/xmlsitemap/xmlsitemap_node/xmlsitemap_node.module).

This was reported on Drupal.org, and an updated version of the module has been released (7.x-2.5) which corrects this issue. Acquia recommends upgrading to the latest version of this moduleimmediately, or disabling the module until you can do so.

External Links

"xmlsitemap" module page on Drupal.org

Bug report on Drupal.org

Acquia provides a high level configuration overview and script to aid in SimpleSAMLphp setup. Recently we have updatedthe script with new functionality. The earlier script contained the following block:

// $ah_options['database_name'] should be the Acquia Cloud workflow database name which

// will store SAML session information.set

// You can use any database that you have defined in your workflow.

// Use the database "role" without the stage ("dev", "stage", or "test", etc.)

$ah_options = array(

'database_name' => 'mydatabasename',

'session_store' => array(

'prod' => 'memcache',

'test' => 'memcache',

'dev' => 'database',

),

);

Under the prior script, any new environments beyond prod, test, and dev would require manual config changes. The script now containssession storage logic thatautomatically scales to additionalenvironments without manual configuration. This is particularly helpful for Acquia Cloud CD customers that frequently spin up new on-demand environments.

Symptoms to look out for

A SimpleSAMLphp site with the older configuration will not work on an environment that isn't explicitly specified in the config. The site will respond correctly for anonymous users. Authenticated users will encounter the following error in the browser:

The website encountered an unexpected error. Please try again later.

The corresponding drupal-watchdog.log entry reveals more information:

Sep 5 21:04:52 172.16.2.188 exampleapplication: https://exampleapplication.prod.acquia-sites.com|1536181492|php|207.173.24.186|https://exampleapplication.prod.acquia-sites.com/user/1/edit?pass-reset-token=LkwDM45klrukl4ZLlD1bLKyioM4GfBBjhjhBEpAjhDolldhOR8V7hFiW-1jWcMWQ||1||Notice: Undefined index: ode1 in acquia_session_store_config() (line 1033 of /mnt/www/html/exampleapplication/simplesamlphp/config/config.php) #0 /mnt/www/html/exampleapplication/docroot/core/includes/bootstrap.inc(582): _drupal_error_handler_real(8, 'Undefined index...', '/mnt/www/html/b...', 1033, Array)

Steps to resolution

If you have implemented SimpleSAMLphp prior to June 2018 and use environments beyond dev, stage, and prod, we recommend updating the config.php script to implementthe new script. Doing so will ensure your SimpleSAMLphp authentication will continue to work on all current and future environments of your application.

An alternative solution would be to manually add the additional environment and storage type to the array after thedevline. For example, to add an environment namedodewithdatabasestorage, one would add the following after thedevline:

'newenv' => 'database',

Full example:

$ah_options = array(

'database_name' => 'mydatabasename',

'session_store' => array(

'prod' => 'memcache',

'test' => 'memcache',

'dev' => 'database',

'ode' => 'database',

),

);

Please note the alternative solution will need to be done for every new environment.Acquia Products

Acquia Cloud CD

Topics

saml

Drupal Projects

simplesamlphp_auth

Issue

Users running Google Chrome version 70 or later will see an SSL error for any sites using Symantec SSL Certificates issued prior to June 1 2016.

This change comes after Google Chrome version 66 started issuing SSL warnings for users accessing sites using these certificates on March 1 2018.

Affected Applications

All websites using SSL certificates issued by Symantec and the following subsidiaries prior to June 1 2016:

Thawte

Verisign

Equifax

GeoTrust

RapidSSL

You can check whether your SSL certificate is impacted by this issue using Symantecs SSL checker tool.

Resolution

SSL Certificates issued prior to this date by any of the above providers need to be replaced. We recommend that this is done as soon as possible to minimise any impact to users on your site.

We recommend reviewing Symantecs published documentation on renewing or reissuing your SSL certificate.

To manage your SSL certificate on Acquia Cloud please see Managing SSL Certificates in the Acquia Help Centre.Acquia Products

Acquia Cloud

Acquia Cloud Site Factory

Acquia Cloud Enterprise

Topics

ssl

External Links

SSL Checker

Symantecs Published Documentation

Managing SSL Certificates

Issue

Visiting some/all pages show "A client error has occurred"

Watchdog log contains errors similar to this:

... Symfony\Component\HttpKernel\Exception\BadRequestHttpException:

The request has both a trusted "FORWARDED" header and a trusted

"X_FORWARDED_FOR" header, conflicting with each other. You should

either configure your proxy to remove one of them, or configure

your project to distrust the offending one. in Symfony\Component

\HttpKernel\HttpKernel->handle() (line XX of /mnt/www/html/

[sitename]/vendor/symfony/http-kernel/HttpKernel.php) ...

This issue has been reproducedwith the following steps when aDrupal siteexhibits the problem:

Clear Drupal cache

Visit site without the Google Data Saver extension enabled, confirm a page is a HTTP status 200

Enable the Data Saver extension

Clear Drupal cache again

Visit site again; page status code should bea 400 Bad Request (You can see this in the browser inspector)

Affected Applications/Limitations

This issue stems from a combination of:

having a recent update of Drupal (and the Symfony components)

incoming requests from a web browser (desktop or mobile) using Google Data Compression ( https://developer.chrome.com/multidevice/data-compression )

with the results of the problem potentially ending up cached in Drupal's internal cachefor other browsers (regardless of them using the Google Compression proxy or not).

This issue is being handled in the Symfony project here: https://github.com/symfony/symfony/issues/20215

Resolution

You can do either of the following actions:

Roll back your Drupal updates to sidestep the problem

Avoid using Google Data Saver

Apply some of the advice/patches provided in https://github.com/symfony/symfony/issues/20215

External Links

Symfony Github Issue #20215

Issue

If the mobile version of your site's CSS files are only partially rendering when CSS is aggregated, but the desktop version is rendering properly, one or more of your CSS files may contain an error. The syntax errors could include, but are not limited, to a missing semicolon, closing brace, or end quote.

Resolution

To confirm the issue, you can temporarily disable CSS aggregation under the Administration >> Configuration >> Performance page of your Drupal website. Flushing Varnish cache may also be required after the configuration change.

To identify errors in a CSS file it's helpful to use a CSS linter, which should be able to detect such errors more efficiently than a manual perusal.

CSS linters and validation tools

W3C CSS online validation service

CSSLint online CSS linter

StyleLint (a command-line tool for validating and linting CSS files during development)

Cause

These types of syntax errors are gracefully ignored by Desktop web browsers where newlines are still present to delimit between CSS rules. However, Drupal's CSS aggregation functionality removes the newlines, resulting in parsing problems starting at the point in the file where the syntax errors occur.Topics

css

mobile

Issue

Can you provide an overview of how Panels caching works?

Resolution

Note

Panels is an API in Drupal 8.

In order to use panels, you must use an implementing module. Currently, Page Manager and Panelizer implement panels.

In Drupal 7, if you use the Panels module on your website and you're not making big changes to panes, you can cache Panel pages in their entirety. To do this:

Sign in to your site, and then go tohttp://[site_URL]/admin/structure/pages.

ClickEditnext to the panel you want to cache.

Click theContentsubtab.

Near the top of the pane, click theDisplay Settingslink.

A menu opens where you can change your page cache settings.

Caching overview

Although individual Panel panes aren't cached by default, you can cache them as well.

To cache Panels panes:

Find the Panel pane that you want to cache.

In the pane itself and not the region, click its gear icon.

In the menu'sCachingsection, clickChange.

Determine the best method for your site. Panel panes use a simple cache with increments between 15 seconds and a week. You can also break out the cache based on the Panel pane's arguments and contexts.

You should cache any pane that doesn't need to be updated frequently.

Note

Be careful when you're using Views and Panel caching at the same time. Users can be confused when one cache is cleared and items on a page don't change because the other cache hasn't cleared.

Several modules can help with additional caching for Panels. The Panels Hash Cache module provides a hash-based cache for Panels. In addition, the Cache actions module provides integration with the Rules module, allowing the cache to be cleared on specific triggers.

Additional caching information

For more information about caching on your Drupal website, see the Caching overview Help Center article.Topics

cache

drupal7

drupal8

Drupal Projects

page_manager

panelizer

panels

panels_hash_cache

cache_actions

rules

External Links

After you've downloaded the Slow Query log for your site, you may find that it's unlike some of your other logs. We've included information here about the different pieces of the slow query log and how to read them.

Information about the log

The first part of a slow query log is the digest information.

# 1.6s user time, 20ms system time, 32.08M rss, 61.39M vsz

# Current date: Tue Aug 7 13:10:57 2012

# Hostname: staging-1047.prod.hosting.acquia.com

# Files: mysqld-slow.log

# Overall: 3.16k total, 404 unique, 0.14 QPS, 0.80x concurrency __________

# Attribute total min max avg 95% stddev median

# ========= ======= ======= ======= ======= ======= ======= =======

# Exec time 18105s 1s 935s 6s 12s 28s 2s

# Lock time 29s 0 2s 9ms 4ms 67ms 0

# Rows sent 62.37M 0 6.03M 20.19k 33.17k 196.65k 0.99

# Rows exam 73.95M 0 6.03M 23.94k 92.42k 197.17k 0.99

# Time range 2012-08-07 06:47:17 to 2012-08-07 13:05:53

# bytes 3.54M 11 1.30M 1.15k 537.02 32.70k 88.31

# Rows affe 89.04k 0 3.11k 28.83 0.99 250.23 0

# Rows read 75.64M 0 6.03M 24.49k 97.04k 198.56k 0.99

The log includes the following items (with specific references from the example):

When was it run?Tue Aug 7 13:10:57 2012

On what hostname?staging-1047.prod.hosting.acquia.com

How many lines were processed?3.16k total, 404 unique

Identifying problems

The next section provides an overview of what queries were the slowest. They're ranked in descending order, with the worst offender having aRankof 1:

# Profile

# Rank Query ID Response time Calls R/Call Item

# ==== ================== ================ ===== ======== ================

# 1 0x67A347A2812914DF 3689.6381 20.4% 351 10.5118 SELECT watchdog

# 2 0x2FA97A9508A98849 3337.4335 18.4% 18 185.4130 SELECT watchdog

# 3 0x13071EB1C98EA90B 1356.7068 7.5% 58 23.3915 SELECT variable

# 4 0x30FE5C2032672827 1093.2228 6.0% 804 1.3597 SHOW TABLE STATUS

# 5 0x748DEEF28EA5992D 952.6171 5.3% 8 119.0771 DELETE cache_fpe

# 6 0xF080ABC5341CBEE1 320.7495 1.8% 81 3.9599 UPDATE apachesolr_index_entities_node taxonomy_index

# 7 0x7AF789F9862CBC08 301.1504 1.7% 40 7.5288 SELECT search_total search_index

# 8 0x6BCD96962189B14D 261.2722 1.4% 22 11.8760 SELECT apachesolr_search_node node

# 9 0xCE1FFB25CB1ACF8E 191.9873 1.1% 47 4.0848 SELECT cache_bootstrap

# 10 0xD92183ACD7A21D6A 185.5956 1.0% 43 4.3162 SELECT field_data_body

The remaining column headers are described as follows:

Query ID- A hash of the query. You're not likely to need this.

Response time- The average amount of time needed to execute this query.

Calls- What percentage of the slow query log is this query?

R/Call- The mean response time per execution.

Item- A truncated version of the query.

From this, you can determine that watchdog queries occupy the two top slots, accounting for nearly 40% of of the calls to the database.

In-depth analysis

After the overview, the script provides an in-depth detail section about each query. Some of it is of interest, while other sections may be less useful. Let's look at the #2 ranked query from the previous section. Because of the amount of output for this section, we'll break it into sections:

Runtime statistics

Users, databases, and time range

Visual breakdown of execution time

Note

Some of the data will contain database names or aliases. If you're not sure, you can check your database credentials.

Runtime statistics

One of the first lines in this section provides the column headers for the query's table of information. Pay attention to the following columns:

pct(Percentage) - The percent of the total for the whole analysis run.

total- The actual value of the specified metric.

95%- The 95th percentile; 95% of the values are less than or equal to this value.

stddev(Standard deviation) - How tightly grouped the values are.

The standard deviation and median are both calculated from the 95th percentile, discarding the extremely large values.

# Query 2: 0.00 QPS, 0.15x concurrency, ID 0x2FA97A9508A98849 at byte 1909177

# This item is included in the report because it matches --limit.

# Attribute pct total min max avg 95% stddev median

# ========= ====== ======= ======= ======= ======= ======= ======= =======

# Count 0 18

# Exec time 18 3337s 1s 652s 185s 314s 145s 167s

# Lock time 0 56ms 0 56ms 3ms 0 13ms 0

# Rows sent 0 0 0 0 0 0 0 0

# Rows exam 1 1.34M 1003 97.67k 76.19k 97.04k 39.91k 97.04k

You can also examineRows sent/Rows exam(examined) as an indicator of query problems. These numbers should ideally be nearly a 1:1 ratio. A large number of rows examined, but a small number of rows sent, means that the query is examining much more data than it's returning this may mean the query is inefficient. Indexing may help with queries like this.

Users, databases, and time range

The next section displays statistics regarding the users, databases, and time range for the query. The users and databases are displayed as a count of distinct values, followed by the values. If there's only one, it's displayed alone; if there are many, the section displays each of the most frequent ones, followed by the number of times that it appears:

# Users 3 website1... (14/77%), websitestg (3/16%)... 1 more

# Hosts 1 staging-1047.prod.hosting.acquia.com

# Databases 6 website1add... (7/38%), website1add... (7/38%)... 4 more

# Time range 2012-08-07 07:03:41 to 2012-08-07 13:05:51

# bytes 0 6.82k 388 388 388 388 0 388

# Rows affe 0 0 0 0 0 0 0 0

# Rows read 0 0 0 0 0 0 0 0

Visual breakdown of execution time

The log then displays a graph that provides a visual breakdown of the amount of time this query typically needed to complete. This query sometimes only needed approximately one second to run, but generally needed over 10 seconds to complete. The one second benchmark is where Acquia Support generally starts looking for issues with queries, as these can start having performance impacts.

# Query_time distribution

# 1us

# 10us

# 100us

# 1ms

# 10ms

# 100ms

# 1s ##################

# 10s+ ################################################################

Query review

Finally, the log includes the query that was problematic. The\Gflag at the end is an instruction to format the query across multiple lines for easier reading. The lines beginning with#are comments, and are not part of the query being examined.

Here's how an example query would be presented:

# Tables

# SHOW TABLE STATUS FROM `website1addb2886` LIKE 'watchdog'\G

# SHOW CREATE TABLE `website1addb2886`.`watchdog`\G

# EXPLAIN /*!50100 PARTITIONS*/

SELECT w.message AS message, w.variables AS variables

FROM

watchdog w

WHERE (w.message LIKE 'login attempty failed%' ESCAPE '\\') AND (w.timestamp > '1344294002')

AND (w.message NOT IN ('UPGRADE.txt', 'MAINTAINERS.txt', 'README.txt', 'INSTALL.pgsql.txt',

'INSTALL.txt', 'LICENSE.txt', 'INSTALL.mysql.txt', 'COPYRIGHT.txt', 'CHANGELOG.txt'))

ORDER BY w.timestamp DESC

LIMIT 10 OFFSET 0\G

Slow queries grouped by database

You can also usept-query-digestto provide output that is grouped by database.

pt-query-digest --limit 100% --group-by db slow.log > slow-db.txt

This returns information similar to what's been previously described on this page, with an addedItemfield that identifies the database.

# Profile

# Rank Query ID Response time Calls R/Call Item

# ==== ======== ================== ====== ======== ===============

# 1 0x 2128815.3618 76.9% 161869 13.1515 db1

# 2 0x 289770.3525 10.5% 10281 28.1850 db2

# 3 0x 156921.2035 5.7% 5567 28.1877 db3

# 4 0x 50476.0517 1.8% 1151 43.8541 db4

General

There is an extensive page on drupal.org for solving problems with cron: Solving cron problems.

There are a few modules aimed at helping debug cron. The one most commonly used is Cron debug.

If you're having problems with cron and search (or think you might be), see Debugging Cron / Search Indexing.

There are a number of ways explored here :

Drush

Modules

Drush php-eval

Modify Drupal Core

Note for Acquia Cloud customers

Please see the Acquia Cloud page Using Cron to schedule tasks for information on redirecting debug output, and using thecron-wrapper.shscript for debugging.

Drush

Drush offers a multitude of methods to troubleshoot cron and just about everything else.

Modules

The Drush Debug Tools are a group of extensions for Drush, written by Acquians, with more extensive cron debug capabilities.

Note that this is only forDrupal 7.

php-eval

You can debug cron by using the Drush utility using php-eval.

The code below runsdrush php-evalusing the respective functions :

the module_implements() function (for Drupal 7) and

the ModuleHandler::getImplementations() function (for Drupal 8)

It logs each part of cron as cron runs, and then outputs that to the terminal.

There is a version ofdrush php-evalforDrupal 7andDrupal 8:

Drupal 7 Code

drush php-eval 'global $timers; $return = $args = array();foreach (module_implements("cron") as $module) { $function = $module . "_cron"; print($function ." - "); timer_start($function); $result = call_user_func_array($function, $args); if (isset($result) && is_array($result)) { $return = array_merge_recursive($return, $result); } else if (isset($result)) { $return[] = $result; } timer_stop ($function); print($timers[$function]["time"] ."\r\n");} '

This code will return results like:

ctools_cron - 9.74

field_cron - 83.14

node_cron - 3.91

search_cron - 1.97

system_cron - 1282.06

trigger_cron - 7.53

update_cron - 1036.85

Drupal 8 Code

drush php-eval 'use Drupal\Component\Utility\Timer;global $timers; $return = $args = array(); foreach (\Drupal::moduleHandler()->getImplementations("cron") as $module) { $function = $module . "_cron"; print($function ." - "); Timer::start($function);$result = call_user_func_array($function, $args);if (isset($result) && is_array($result)) {$return = array_merge_recursive($return, $result);} else if (isset($result)) {$return[] = $result;} Timer::stop($function); print($timers[$function]["time"] ."\r\n"); }'

This code will return results like:

Starting execution of dblog cron .... Execution of dblog cron took 10.18ms

Starting execution of field cron ..... Execution of field cron took 11.19ms

Starting execution of file cron ..... Execution of file cron took 27.31ms

Starting execution of history cron ..... Execution of history cron took 0.91ms

Starting execution of node cron ..... Execution of node cron took 0.03ms

Starting execution of scheduled_updates cron ..... Execution of scheduled_updates cron took 43.72ms

Starting execution of search_api cron ..... Execution of search_api cron took 26.54ms

Starting execution of system cron ..... Execution of system cron took 20.58ms

Updater Publish multiple nodes at a certain time complete. Results: No updates were performed. [status]

Updater Publish single node at certain time complete. Results: No updates were performed. [status]

Modifying Drupal Core

Note

It is not encouraged to modify core, especially for a Production environment!

This should be used as a last resort.

Alternately, you can use the following code to help you debug cron. The code is a replacement function that goes inincludes/module.incin place of the existing module_invoke_all() function (for Drupal 7). It logs each part of cron as cron runs, and then logs that to the system log.

There is a version forDrupal 7:

<?php

/**

* Invokes a hook in all enabled modules that implement it.

*

* @param $hook

* The name of the hook to invoke.

* @param ...

* Arguments to pass to the hook.

*

* @return

* An array of return values of the hook implementations. If modules return

* arrays from their implementations, those are merged into one array.

*/

function module_invoke_all($hook) {

$args = func_get_args();

// Remove $hook from the arguments.

unset($args[0]);

$return = array();

foreach (module_implements($hook) as $module) {

// BEGIN CRON LOG

if ($hook == "cron") {

watchdog('cron', 'Running cron for: %module', array('%module' => $module), WATCHDOG_NOTICE);

}

// END CRON LOG

$function = $module . '_' . $hook;

if (function_exists($function)) {

$result = call_user_func_array($function, $args);

if (isset($result) && is_array($result)) {

$return = array_merge_recursive($return, $result);

}

elseif (isset($result)) {

$return[] = $result;

}

}

}

return $return;

}

?>

This file is able to be downloaded also.

Note

Remember to remove this code when you're not actively debugging a problem, because it will fill your logs with additional logging during each cron run.

After you upgrade Drupal, cron sometimes fails to run. In some cases, the Search module is at fault, and you can disable the Search module to resolve the problem temporarily, but after you re-enable the Search core module, cron fails again.

If cron fails in this way, use a debugging tool that provides more verbose logs to help you resolve the problem. One such tool is Drupal's watchdog logger. The following is an example of debugging this problem with watchdog. Add the node_update_index function text to /modules/node/node.module. Notice the line that begins with watchdog. The last node referenced in the watchdog log will most likely be the one that is causing cron to fail.

Drupal 7 node update index

Drupal 6 node_update_index

Additionally, more verbose cron-related messages will now be written to the Drupal watchdog log (and to syslog, if it's enabled in Drupal).

Another useful place to look is the search.module to confirm that it is definitely a search issue, and to see which hook_update_index is failing.

You can debug statements like this:

Drupal 7

Edit search_node_update_index() to include a DEBUG statement, as shown here:

/** * Implements hook_node_update_index(). */function search_node_update_index($node) { // Transplant links to a node into the target node. $result = db_query(\"SELECT caption FROM {search_node_links} WHERE nid = :nid\", array(':nid' => $node->nid), array('target' => 'slave')); $output = array(); foreach ($result as $link) { //BEGIN DEBUG CODE watchdog('cron', \"about to index node \" . $node->nid); //END DEBUG CODE $output[] = $link->caption; } if (count($output)) { return '(' . implode(', ', $output) . ')'; }}

Drupal 6

Edit search_node_update_index() to include a DEBUG statement, as shown here:

/** * Implementation of hook_cron(). * * Fires hook_update_index() in all modules and cleans up dirty words (see * search_dirty). */ function search_cron() { // We register a shutdown function to ensure that search_total is always up // to date. register_shutdown_function('search_update_totals'); // Update word index foreach (module_list() as $module) { //BEGIN DEBUG CODE watchdog('cron', \"about to run hook_update_index for \" . $module); //END DEBUG CODE module_invoke($module, 'update_index'); } }

Other methods

There are other ways to figure out where cron may be failing due to search indexing. One method is to use php-eval in Drush. The command steps through each of the cron hooks and prints each one by name, followed by how many milliseconds each one took to execute. If an error occurs, you'll see cron either hang and never complete, or you'll see the errors in sequence.

Execute the following code snippet from either the sites/default/ or sites/default/[sitename]/ directory of your website.

drush -dv php-eval 'global $timers; $hook = \"cron\"; $return = array(); $args = array(); foreach (module_implements($hook) as $module) { $function = $module . \"_\" . $hook; echo \"Trying to execute $function...\\n\"; print($function .\" - \"); timer_start($function); $result = call_user_func_array($function, $args); if (isset($result) && is_array($result)) {$return = array_merge_recursive($return, $result); } else if (isset($result)) { $return[] = $result; } timer_stop($function); print($timers[$function]['time'] . \" - memory_get_peak_usage()=\" . sprintf(\"%2.1fMB\", memory_get_peak_usage()/1024/1024) . \"\\n\"); }'

It can be useful to send the output of the command to a file. If you want to be able to see the output and store it in a file at the same time, you can use tee. (Note that the following example redirects stdout and stderr to tee. If you don't use tee, drush displays any errors in the console display, but not to a file.)

// start a new debug file or overwrite the existing onedrush php-eval '// cron commands snipped' 2>&1 | tee /tmp/cron_debugging.txt // start a new debug file or append to the existing one drush php-eval '// cron commands snipped' 2>&1 | tee -a /tmp/cron_debugging.txt

Example output

These commands can provide some important information, including which processes are taking time and how much time. They can also provide insight into what part of cron is timing out:

acquia_agent_cron - 959.08 acquia_spi_cron - WD acquia agent: request timed out (-1): https://nspi.acquia.com/xmlrpc.php - acquia.nspi.update [error] 122831.94 clientreport_cron - 189.42 ctools_cron - 6.77 field_cron - 11.16 node_cron - 5.6 search_cron - 4.51 system_cron - 349.38 update_cron - 4381.43

From these results, you can determine that acquia_spi_cron had a problem. From there, you can debug that cron specifically.

Drupal 6 and Apache Solr

If you are using Drupal 6, and Apache Solr, you could use watchdog to debug it. Add the following code to the modules/acquia/apachesolr/apachesolr.index.inc file and the sites/all/modules/apachesolr/apachesolr.index.inc file.

/** * Given a node ID, return a document representing that node. */ function apachesolr_node_to_document($nid, $namespace) { // Set reset = TRUE to avoid static caching of all nodes that get indexed. $node = node_load($nid, NULL, TRUE); //BEGIN DEBUG CODE watchdog('cron', \"about to index node \" . $node->nid); //END DEBUG CODE if (empty($node)) { return FALSE; }}

As an alternative, you could execute the following PHP script to check the Apache Solr index, indexing one index at a time.

#!/usr/bin/php <?php chdir(dirname($_SERVER['argv'][0])); include_once('./includes/bootstrap.inc'); drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL); ini_set('memory_limit', '1024M'); ini_set('max_execution_time','180'); $cron_limit = 1; $rows = apachesolr_get_nodes_to_index('apachesolr_search', $cron_limit); var_dump($rows); apachesolr_index_nodes($rows, 'apachesolr_search');?>

Other useful Drush commands

Drush provides some other command capabilities you can use for manually viewing the index.

Manually indexing nodes

You can manually index one or more nodes at a time by using one of the following commands, depending on your Drupal version. The number at the end is the number of nodes that will be indexed. In these examples, we're using 10.

Drupal 7

drush php-eval 'module_load_include(\"inc\", \"apachesolr\", \"apachesolr.index\"); apachesolr_index_entities(apachesolr_default_environment(), 10);'

Drupal 6

drush php-eval 'apachesolr_index_entities(apachesolr_default_environment(), 10);'

You may also find the drush solr-index command useful.

Node information

If you need to know more about the next nodes to be indexed, you can use one of these commands. In this case, we are using 1 to return a single node. You can view more than one by changing this value.

Drupal 7

drush php-eval 'module_load_include(\"inc\", \"apachesolr\", \"apachesolr.index\"); $rows = apachesolr_index_get_entities_to_index(apachesolr_default_environment(), \"node\", 1); foreach ($rows as $row) { print_r($row); }'

Drupal 6

drush php-eval 'print_r(apachesolr_get_nodes_to_index(apachesolr_default_environment(), 1));'

If you are using an older Solr 6-x-1.x module version, this command may be more suited to your environment:

drush ev 'print_r(apachesolr_get_nodes_to_index(\"apachesolr_search\", 1));'

Topics

cron

Search

Issue

Acquia Cloud Drush commands can be confusing when referencing an environment specific database. Luckily, the API infers from your command which environment the database is in.

Resolution

You might be tempted to add the environment to your database name:

drush @mysitegroup.test ac-database-instance-backup mysitegroupstg

Which will result in an error:

message : Resource not found

API status code 404

The 404 occurs because the API cannot find a database namematch for"mysitegroupstg."

Instead, use the database name, whichis the same across all environments. For example:

drush @mysitegroup.test ac-database-instance-backup mysitegroup

More Information

Acquia Cloud Drush Topics

drush

cloud api

Issue

What is the timeout set inlift.jsand/decide-js?

Resolution

The timeout set in bothlift.jsand the/decide-jsendpointis 30 secondsfor authentication.

Other requests are also configurable usingwindow.AcquiaLift.loadTimeout, but not all requests are controlled there so be sure to contact Acquia Support regarding other specific requests.

Thewindow.AcquiaLift.loadTimeoutcannot be used to override authenticationwhich remainsat 30 seconds; however, the timeout value for other calls can be changed here.

Cause

The default authentication timeout is 30 seconds. More information can be found in our Lift documentation on capture - Acquia Lift JavaScript API.Acquia Products

Acquia Lift

Occasionally, Acquia Support will send notices to Acquia-hosting customers regarding important maintenance issues. If you have not signed up for these notices, please see the Acquia Status documentation page to learn how to sign up for alerts.

In most cases, customers shouldn't have issues receiving these emails (which are sent using Marketo). If you've configured your email server to not accept certain content, you may have to add certain IP address ranges to your server's whitelist to ensure that you receive these emails.

If this is the case, add the following IP addresses from Marketo to your email server's

https://docs.marketo.com/display/public/DOCS/Configure+Protocols+for+Marketo#ConfigureProtocolsforMarketo-Step2:WhitelistMarketoIPs

If you continue to have problems receiving maintenance notices, contact Acquia Support for additional assistance.Topics

email

Support

External Links

Whitelist Marketo IPs

Issue

Every time I create a content type, there are new roles created per content type. Is this a D8 feature or something in Lightning, and can it be turned off?

Resolution

For an existing site, just uninstalllightning_roles. If you want to exclude it entirely from new site builds, use a sub-profile and addlightning_rolesto theexcluded_dependenciesarray.

Cause

Auto role creation is a part of the Lightning Roles component. More information can be found in our documentation on Lightning Roles.Acquia Products

Lightning

Topics

roles

content types

External Links

Lightning roles

Issue

Personalized slot is not visible in Experience Builder on the following x and y pages.

Resolution

To identify whether Slot "A" was actually defined for a particular page, perform the following steps:

Navigate to the page in question and open up the browser "inspector" tool.

Navigate to the Network tab and reload Experience Builder, if you have it open in administrative mode. Make sure your Network tab is filtered toAllorXHR.

Look for aslots?account_id=...GETrequest. There will be anOptionsand aGETrequest.

Click on theGETrequest, and clickPreviewwhich will display a list of slots. This list is what is being returned by the Lift API.

Creating slots in Experience Builder We are working on more extensive product documentation on how to use various tools to query the Lift API to get a list of all slots created on a site.

For now, you can reference Using the Acquia Lift APIs, specifically the section onTesting your API implementationswhich uses the tool Postman.

General steps:

Set up Postman for Decision API following the documentationin Github: https://github.com/acquia/http-hmac-postman.

Set up the Postman call for the slots endpoint of Decision API: http://docs.lift.acquia.com/decision/. Here is an example of a slot API endpoint:https://us-east-1-decisionapi.lift.acquia.com/slots?site_id=example1&account_id=EXAMPLE2.

Add parameters of what slots you want to locate, example by site.

Once you have determined, the original page that a slot was defined on,go ahead and add/define the other page paths thatthe slot shouldappear on via theConfiguretab, and add the page paths to theSlot Pagesfield as explained in Creating slots in Experience Builder.

Cause

The "missing" slot was not actually defined on the pages previously assumed.Acquia Products

Acquia Lift

Topics

personalization

slots

content

experience builder

External Links

Using the Acquia Lift APIs

Postman

Decision API

Issue

Can you explain how to set up Views caching?

Resolution

The Views module is a query builder; any view that it creates queries your database one or more times. This can result in multiple database queries for any given page load. By default, Views doesn't cache any of its queries or data. While Drupal's page caching will mask some of the problem, websites with a large amount of traffic coming from authenticated users will see heavier load unless you cache the Views.

Setting up Views caching

You can start caching your Views by setting up time-based caching on any View that will be seen regularly.

To set up caching for a View, complete the following steps:

Sign in to your website, and then go toStructure > Views

Find the view that you want to configure, and then click itsEditlink.

In theAdvancedsettings section, clickNonenext toCaching.

SelectTime-based, which gives you the opportunity to cache query results or rendered output.

ClickApplyto save the new caching value.

ClickSaveto save the edits to your view.

You need to consider settings individually per View. Even a five-minute cache can make a significant difference in website performance. A blog post on Optimizing Drupal Views the Right Way offers several suggestions for Views caching.

If you need more control over when the cache for each View is cleared, and do not want to set up the Rules and Acquia Purge modules to clear caches based on Rules, look into the Views content cache module to set up per-View cache clears when content of certain types is added to the database.

Additional caching information

For more information about caching on your Drupal website, see Caching overview.

More Information:

Caching in Drupal Modules Topics

best practices

cache

Drupal Projects

views

views_content_cache

rules

acquia_purge

External Links

Optimizing Drupal Views the Right Way

Caching overview

Configure Views caching

Issue

I am having issues retrieving completed file information that is exported to my specific customerAmazon S3 Directory.

This is the on-screen error I am receiving:

Login Failed The AWS Access Key Id you provided does not exist in our records. Please contact your web hosting service provider for assistance.

Resolution

Make sure you are accessing the Amazon S3 Directory associated specifically with your Lift account, and that you are using the specific S3 keys associated with your customer account, andnotyour individual user account.

The correct URL should be theS3 Bucket URLs3://lift.prod.api-file.[region]/[customer/and the directory should look like:

Profile manager The customer keys should be theAWS Access Key IDand theAWS Secret Access Keythat are listed by the S3 Bucket URL atAdmin > Manage Customers > Customer Detailsin your Lift Profile Manager account.Acquia Products

Acquia Lift

Topics

export

amazon s3

External Links

Issue

I would like to understand the security implications of Cross Site Scripting (XSS)?

Resolution

We've talked about Cross Site Scripting (XSS) before, and for good reason; it's a risk far too many websites are vulnerable to. The basic threat of XSS to your website's security is that it runs in the context of the trusted relationship between your browser and a website.

XSS cookie theft

Another example of an XSS exploit is using XSS to steal administrative access to a website:

An attacker enters JavaScript that steals the visitor's browser cookie.

An administrator unknowingly executes this JavaScript.

The administrator's browser sends the cookie to the attacker's website.

The attacker uses the stolen cookie to use the administrator's access on the website.

Mitigation

XSS vulnerabilities are extremely common in web applications, so you should audit your configuration and custom code for adherence to Drupal best practices.Topics

security

xss

best practices

drupal7

External Links

Anything you can do, XSS can do better

Securing your site

Writing secure code in Drupal 7

Issue

Cross-site scripting (XSS) is the number-one vulnerability in Drupal code, and can be one of the scariest forms of exploitation, because anything you can do, XSS can do better. Note that this doesn't mean that the JavaScript that the XSS uses can do things that you can't do but it can certainly make changes to your site faster than you can.

Note

XSS is the number-one vulnerability in Drupal code based on the times reported in Drupal core and the contributed project Security Advisories, as published by the Drupal Security team.

Resolution

Demonstrating the problem

During XSS demos and vulnerability testing, it's easy to use some code likealert('xss')to cause JavaScript to be executed where it shouldn't but an alert box isn't scary.

It's scary when JavaScript can put your Drupal site offline. And it's even more frightening when it locks you out of signing back in because it changed your administrator account username, password, and email address. The following short video includes a demonstration of what's possible.

To sum up, the malicious JavaScript entered by the attacker, when unknowingly executed by an administrator, affected the website in the following ways:

Changed the site title and site email address.

Changed the administrator's username, email, and password.

Set a site-offline message and put the site in offline status.

And finally, signed the current user out of the site. The final piece of the attack by the JavaScript is actually a different class of attack known as cross-site request forgery (CSRF).

Protecting against XSS

The most effective method to protect against cross-site scripting is to disable the use of the Full HTML input format by anonymous users. In general, you should understand how to configure your site securely and know what actions you allow untrusted users to perform.

Note that Drupal doesnotcome by default with Full HTML enabled for anonymous users.

Be mindful of contributed modules

It's also common that contributed modules print user-supplied data insecurely, which can make the site more vulnerable for an XSS attack. Popular modules are often more vetted and secure, and thus safer to use. Also, if you're developing your own code, be sure that you're correctly using the APIs and following best practices.Topics

xss

security

javascript

External Links

Securing your site

The importance of user roles and permissions for site security

Writing secure code (overview)

Issue

How can I stay informed about Drupal security updates?

Resolution

Staying on top of updates to Internet software is a big responsibility. It's critical to the security of your website and yet can take a lot of time. The traditional advice about updates is to subscribe to the updates mailing list: that works well for most projects.

For broad software projects like Drupal, however, that advice is increasingly unmanageable. Drupal update emails cover not just Drupal core, but also many of the contributed modules, themes, and distributions available on drupal.org over 20,000 of them. Any individual website may have 50, 100, or more. So, if you sign up to get emails about security issues across 20,000 modules and you only care about 200 of them, the chances of getting a message about a module you don't need are very high.

Here are some ways you can receive updates; see which one is the best for you.

Note for Acquia subscribers

With an additional subscription, Acquia customers can enable the Remote Site Administration service, which, depending on your preferences, provides you a range of automatic update services from informing you of necessary patches to complete module deployment.

Method

Pros

Cons

Enable the Update core module with security focused settings (configured atAdministration > Reports > Available Updates)

It's a focused report to your needs on your website.

It can be sent to multiple inboxes, including a ticketing system or support team.

This relies on the cron mechanism. In Drupal 7, you can either set up cron to run on your server (for example, using crontab), or it runs using the so-called poor man's Cron, which runs periodically after a page visit by a website visitor. If Cron isn't working, this won't work for you.

If email from your server isn't working, then this report won't be delivered to you.

It can negatively impact performance. We recommend using it on test environments because the production server shouldn't need to spend time and resources on polling drupal.org.

Subscribe to the security notification newsletter

You get all the important information as soon as possible.

It can can help give you an idea of trends in issues; for example, CSRF is less common now than it once was, and seeing the advisories helps you realize that.

It has an overwhelming amount of information about core and all other projects, which is very likely more than you need when managing your specific websites with specific modules.

Follow @Drupalsecurity onTwitter

This is fast and simple for people who love Twitter.

You can place it into a high-importance Twitter list that you can check before visiting other parts of Twitter.

Twitter content tends to be easily forgotten.

The Twitter feed contains updates about all content, leading to the same overload problem that you have with the mailing list.

Subscribe to one of the RSS feeds from drupal.org/security and subtabs

There are separate feeds for Core, Contrib, and Public service announcements (PSAs).

It's formatted for easy import into systems (for example, ticketing systems) that can import from RSS.

It can be paired with a tool like If this then that to trigger other events. These events could include scripts to start automated testing of a new build, email alerts, and so on.

For personal consumption, it may get lost among other RSS items.

The/contribfeed still shows information about projects you may not need.

Use Drush to apply security updates

Drush is highly customizable for integration with other systems.

It's very specific to the needs of your websites.

If you're monitoring with a tool like Nagios, it could create an alert if there's no data at all (for example, to prevent problems with cron not running).

Drush requires special access (that is, SSH) and some extra work on the server.

Topics

drupal7

security

External Links

Remote Administration

Remote Administration preferences

Security advisories

If this then that

Use Drush to apply security updates

Issue

Unable to add a user, to one or more of the teams in your Acquia Cloud application, through the Acquia Cloud UI.

Resolution

There are a few reasons why you may not be able to add a user to one or more of the teams in your Acquia Cloud application through the Acquia Cloud UI.

Scenario 1

Only Owners and Administrators of an application can add users to a team. If you are not an Owner or Administrator, please have the Owner or Administrator perform this action.

Scenario 2

Be sure that the user you are attempting to add has created an Acquia Account. A user can not be added to a team without first having an Acquia Account.

If you attempt to add a user to a team through the Cloud UI, and they do not have an Acquia Account, you can refer them to this link and have them create an account.

All users who are added to a team through the Acquia Cloud UI will receive an email like this:

Acquia Cloud Site Factory You can see in the screen shot above, that the user will be directed to create an Acquia Account. Once the user has done this, please try to add the user to the team again.

Scenario 3

Be sure that emails coming from Acquia, in particular from [email protected] are not being either blocked on your side or being filtered to spam.

Cause

This can be caused by:

1. The user being added by someone who is not an Owner or Administrator.

2. The user does not have an Acquia Account.

3. The email is being blocked or filtered to spam.Acquia Products