Description

Due to the limited space allocated for /tmp, receptor may occasionally consume all available space during JT executions, potentially leading to application or system crashes or unexpected behavior.

Customer Scenario:

In our Automation Controller a job was started for 69169 target hosts by accident.
The problem with this was the fact that on the controller node and one execution node the directory "/tmp/receptor/<hostname>/<id>/" included a file "stdout" that showed up with a size of 5 GB. That filled up the partition completely and caused an partial outage of the affected systems and a lot of job failures within the Automation Platform.

Findings:

• We do not have benchmarking results or suggestion in the documentation.
• While testing, we noticed that the temporary JT execution data gets stored in /tmp + /tmp/receptor + the execution node's /tmp and /tmp/receptor(ignore if no external execution node)
• We do have a KCS(https://access.redhat.com/solutions/7036473) that helps configure a different path for the receptor, but that is a reactive approach for the problem described above.

Ask

Looking for proactive solution for this issue.

It can be handled at the receptor level or documentation level.

Doc Level - Clearly mention the receptor requirements

Receptor Level - Provide an option to configure different path at the time of new installation.