Workload Automation Agent Jobs Failing with Permission Denied (Error 13) on Linux

Products

• Workload Automation Agent
• Autosys Workload Automation

Issue/Introduction

Jobs executed via the Workload Automation Agent fail to report their status back to AutoSys. The jobs may complete on the local machine, but the status remains stuck in STARTING (ST) or RUNNING (RU) on the scheduler.

Error Symptom: The agent spool or job log contains the following error:

cybspawn: [Date]: Error sending return status AFM to cybAgent: error 13 (Permission denied). Return status AFM: [AFM details]

Environment

• Agent version: 24.0.00-7794
• Operating System: Red Hat Enterprise Linux RHEL 8 / RHEL 9 and later
• Kernel Feature: fs.protected_regular enabled (default in newer kernels)

Cause

Newer Linux kernels (such as RHEL 8 and later versions) have enhanced security protections for regular files in world-writable sticky directories (like /tmp or certain spool structures).

The cybspawn process, when running as a specific job owner, may be blocked from communicating or writing status files back to the cybAgent process due to these kernel-level "Protected Regular" file restrictions, resulting in the Error 13 (Permission denied).

Resolution

This issue is resolved in Workload Automation Agent version 24.1.01-8235 and later. The updated agent includes changes to how status files and inter-process communication are handled to comply with modern Linux kernel security requirements.

Steps to Resolve:

1. Verify Agent Version: Run cybAgent -v from agent installation directory to confirm the current version.
2. Upgrade Agent: Download and apply the upgrade for the Workload Automation Agent to version 24.1.01-8235 or the latest available maintenance release.
3. Restart Services: Restart the System Agent services after the upgrade.
4. Test Job: Run a test job (e.g., using the env or whoami command) to verify that the status is correctly relayed back to the controller as SUCCESS (SU).

Additional Information

As a temporary workaround (not recommended for production security), the kernel parameter can be checked using: sysctl fs.protected_regular

However, the permanent and supported fix is to upgrade the agent to the compatible version listed above.