Lifecycle Components Toolkit (LCT) for Linux/Unix - Best Practices and Troubleshooting guide

General

  1. Uncheck the Blocking? checkbox on the Script Definition while testing. This will cause the workflow to not initiate a destroy on failure. Or, the other option is to test your script on a Specific Host instead of on the Provisioned Node.
    Enable blocking once testing is completed.

  2. Use descriptive logging in your custom scripts at key points so failures are clear.

  3. Re-execute failed workflow runs from Orchestrator for testing (Requires Blocking? to be disabled, or execution against Specific Host)

  4. Monitor the Script Temporary Directory for the script to copy and verify that the user account has the appropriate permissions on the server/endpoint

  5. Include logic and output in your scripts to check for successful execution

  6. Set exit code based on expected results

 Script Definition Naming

  1. Include the EBS state and script priority in the script name 1190_10_Install Apache

  2. Also helpful to include VC Name and OS for script in name 1190_10_VC01_CENT_Install_Apache

Template Preparation

  1. If you're using a Script Temporary Directory other than /tmp you may want to create the new folder in your template so it's on every new VM.

  2. Make sure the directory has appropriate permissions for user (rwx------)

  3. If using sudo for running scripts as another user, prep the template with appropriate sudoers configuration.

  4. Disable automatic VM Tools Upgrade (optional)

Scripting Guidelines

  1. Redirect stdout and stderr to /dev/null by adding 2&1>/dev/null to the command line.

  2. Do not use interactive prompts (such as read) in scripts to be run via automation.

Both of these guidelines will prevent scripts from hanging indefinitely and causing failures in the LCT workflow. If you encounter a linux or unix script hanging, check the items above in your custom LCT script.

3. Exercise best practices around execution of scripts in a non-interactive shell such as explicitly setting needed environment variables and using full paths for commands and file locations instead of relative paths. If a script executes fine from the command line but fails during the automated run, quite often these can be the culprit.

Troubleshooting

Error: File was not found Please see the server log to find more detail regarding exact cause of the failure.

Solutions:

  1. Look at the Script Definition and verify that the directory you're using exists on the server

  2. Log into the server and verify the script is getting copied to the server

    1. If not, validate permissions are set correctly

Error: Unable to access file Please see the server log to find more detail regarding exact cause of the failure.

Solutions:

  1. Log into the server and verify the script is getting copied to the server

    1. If not, validate permissions are set correctly on the folder.

Related articles

Have more questions? Submit a request

0 Comments

Please sign in to leave a comment.