Skip to end of metadata
Go to start of metadata

Hanging execNatives

(warning) Problem/Phenomenon:

automaIT jobs hang and wait for within execNatives defined system processes while they are already finished on the managed system.

(info) Reason:

The problem mainly occurs with short running service control processes which keep their standard out and/or standard error open for future output. The control process for PostgreSQL database pgctl, for example finishes database startup within tenth of a second but doesn't close his stdout and stderr to print possible occurring errors on the console. In this case, the job waits for the end of the execNative until the database was shut down or the execNative timed out.

(tick) Solution:

For such processes the output should be piped into a file or into /dev/null within the exec-command resp. its arg-elements. Using one of the assigning execNative-elements like (assignOutput or assignError) isn't useful in such a case cause the agent won't get any output if piped and waits for closing of stdout and stderr again if tried to "pipe" with outputFile or errorFile.

SuccessfulTimes out

Agent Execution doesn't terminate on Cancellation

Whenever the agent execution should be cancelled (e.g. timeout or manual cancellation), the automaIT agent sends a signal to the currently running process. However, some commands do not respond to the signal. For example, "sleep" will not terminate on Unix systems.

Automatic Quoting (Windows only)

When using the "echo" command on Windows, quotes may be added automatically.

Actually, this is the behaviour of the Windows implementation of "echo": Whenever a single argument contains spaces it is quoted automatically.

Using execNative with inputText prints "more?" statements in output  (Windows only)

(warning) Problem/Phenomenon:

When performing execNative executions on Windows systems by piping commands into cmd using stdin there might be More? statements in process output like these:

The statements are executed correctly but the More? statements can be somehow annoying.

The output is the result of the following plan:

(tick) Workaround:

Replace the if-else statements spanning multiple lines with a single line statement.

Using <inputText> to define inline-scripts for Windows PowerShell

(warning) Problem/Phenomenon:

When performing execNative executions on Windows systems by piping commands into PowerShell using stdin one might recognize unexpected behaviour, for example regarding if-conditions written over multiple lines.

(info) Reason:

Different from script file execution, PowerShell aborts execution on in-lined code blocks when the script is piped through stdin.

(tick) Workaround:

Define your code in a PowerShell function or insert two empty lines at the top and bottom of your inline script.

FunctionTwo empty lines
  • No labels