Agent fails to start with 'Permission denied' status=203/EXEC on RHEL 9

Products

• Workload Automation Agent

Issue/Introduction

After installing or upgrading to Workload Automation Agent 24.x on Red Hat Enterprise Linux (RHEL) 9, the agent service fails to start.

Checking the service status via journalctl -u waae_agent-####.service or systemctl status reveals the following errors:

text

 

Starting waae_agent-####.service...
waae_agent-####.service: Failed to locate executable /opt/CA/WorkloadAutomationAE/SystemAgent/####/waae_agent-####: Permission denied
waae_agent-####.service: Failed at step EXEC spawning /opt/CA/WorkloadAutomationAE/SystemAgent/####/waae_agent-####: Permission denied
waae_agent-####.service: Control process exited, code=exited, status=203/EXEC
waae_agent-####.service: Failed with result 'exit-code'.
Failed to start waae_agent-####.service.
```

Manual verification shows that the file permissions are correct (e.g., -rwxr-xr-x) and the file is owned by the autosys user, yet the service still fails with 'Permission denied'.

Environment

• Product: Workload Automation Agent
• Operating System: Red Hat Enterprise Linux (RHEL) 9.x

Cause

This issue is caused by SELinux (Security-Enhanced Linux) policies. On newer RHEL versions, SELinux may block the systemd service from executing the agent binary even if standard Linux file permissions are correctly configured. This often happens if the binary lacks the appropriate SELinux security context or if a policy transition is missing for the service.

Resolution

Important: To avoid conflicting with system security policies, consult your System Administrator before performing these steps. These adjustments may involve OS-level modifications such as SELinux to allow service execution.

Step 1: Verify SELinux is the cause

Temporarily set SELinux to permissive mode and attempt to start the agent:

bash

 

setenforce 0
systemctl start waae_agent-####.service

If the agent starts successfully in permissive mode, SELinux is confirmed as the blocker. Re-enable SELinux afterwards: setenforce 1.

Step 2: Identify and fix the denial

1. Check the audit logs for the specific Access Vector Cache (AVC) denial:
   bash

    

   ausearch -m avc -ts recent

2. Use the audit2allow tool to generate a custom policy module if necessary, or ensure the agent directory has the correct context:
   bash

    

   # Example command to restore default contexts if policies are defined
      restorecon -Rv /opt/CA/WorkloadAutomationAE/SystemAgent/
3. Engage your Linux System Administrator to create a permanent SELinux exception or policy for the System agent service to allow the EXEC operation.

Additional Information

Additional Diagnostics

If SELinux is not the cause, ensure the partition containing /opt/CA is not mounted with the noexec flag:

bash

 

mount | grep /opt