APS 'Executing configuration script' task failures
The type of APS task that fails most often is the 'Executing configuration script' task. Parallels Operations Automation executes this task on every APS application provisioning operation. The task is executed with the required command - install/configure/upgrade/remove depending on the nature of the requested operation.
The task can fail on one of the stages described below.
The task fails when collecting data from the POA database to prepare and initiate the task.
The reason for this type of failure is usually a database inconsistency caused by:
Canceling/deleting previous tasks for the application instance being processed
Manual changes in the POA database
- Software problems
An example of an error reported on this stage is 'Statement that is supposed to always return result return empty resultset'. This error usually occurs if an application instance the task was executed for has already been removed from the POA database.
Check the list of pending//failed/processed tasks for the application instance in question. Use the Parallels Knowledgebase article #115693 How to find POA tasks for particular APS application instance to find all such tasks.
Analyze the POA debug log:
Log into the POA Management Node by SSH or RDP
Install the Support Tools Pack on the POA for Windows Management Node if it is not installed yet
Go to the folder where the POA debug log is located (use the Command Tool, cmd.exe, on Windows):
Windows: C:\Program Files (x86)\SWsoft\PEM\var\log
Run the command
'tail -fn0 poa.debug.log > failedtask.log'
Run the failed task in the POA Control Panel and wait until it fails again
- To interrupt the 'tail' command, press Ctrl-C in the Linux shell or the Windows Command Tool
After completing the above steps, the complete log of POA actions during the failed task execution will be stored in the failedtask.log file. Open it using the less utility (included in the Support Tools Pack for Windows servers) and find where POA threw the exception. You can search by the word exception in lines containing the task:TASK_ID signature, where TASK_ID is the ID of the failed task.
For example: If the failed APS task has the ID #14001, then all lines in the failedtask.log file containing the string task:14001 will be related to the task #14001 execution. When POA meets problem during task execution, it marks a log entry with the word exception.
So, searching the log for entries containing both keywords - exception and task:TASK_ID - will help you find the entry where the problem occurred.
Once you have found the exact entry with the exception during POA task execution, analyze the error message. This may contain the cause of the problem, which is not shown in the POA Control Panel.
The task fails when attempting to execute the provisioning script on a Shared Hosting server.
The reason for such failures is usually:
Incorrect permissions for application the provisioning script directory/files
- An absent PHP executable file, or incorrect permissions
Example of errors reported:
Script execution failed: executing 'env 'WEB__wp-content_DIR=/usr/local/pem/vhosts/102948/webspace/site.. /usr/bin/php-cgi -d open_basedir= -q configure 'configure'' for APS application instance with id 632 returned value '255' with output '**Access denied**. ' and errors ''.
Execution of configuration script for service instance with id 275 of instance with id 172 of application with id 104 failed - returned value: -1 output: '' errors: '**[env: /usr/libexec/php5-cgi/bin/php: No such file or directory](https://kb.odin.com/en/9546 "")**'
Check (and correct if necessary) the permissions on the PHP binary that is executed on a Shared Hosting server where the customer's webspace is located, or the Provisioning Gateway Host (for External System provisioning type APS applications). The PHP binary must be executable.
Check (and correct if necessary) the permissions for the provisioning scripts and the folder where they are located. The system (Linux or Windows) must be able to get access to the script and execute it. The scripts are located in the following folders:
(Where APP_NAME is the name of the APS application, INSTANCE_ID is the ID of application instance, POA_ROOT by default is /usr/local/pem on Linux and C:\Program Files (x86)\SWsoft\PEM on Windows.)
Check that PHP is installed on the host and install if it is not
- Check the version of PHP installed on the host (PHP 5 is required in most cases).
The ID of the host where POA is trying to execute APS provisioning scripts and the path to them may be found in the failed task properties:
In addition, the script name and command that POA passes to it may be found in the task properties:
In general, parameters related to APS task execution can be found in the failed task properties. This includes all parameters defined by the APS application's APP-META.xml file. Analyze the parameters carefully while investigating the failed APS tasks.
The task fails because the APS provisioning script returns an error.
This is the most common cause of problems with APS tasks.
The possible reasons for this failure are:
Invalid parameters are passed to APS provisioning script (e.g. a username with unsupported characters, an incorrect password, or a malformed email address such as jdoe@customer).
The Provisioning Gateway Host cannot access the external system contact point.
Manual changes in the external system which POA is not aware of. For example, POA tries to change a user that was manually removed from the external system.
POA is using an outdated/invalid call format while communicating with external system (for APS applications with the External System provisioning type).
- External system issues (for APS application with the External System provisioning type).
Refer to the Parallels Knowledgebase article #115694 Troubleshooting 'Executing configuration script' tasks for advices how to troubleshoot such cases.
See the main Knowledgebase article #115664 APS: General information, Best Practices and Troubleshooting for more information.