-
Bug
-
Resolution: Unresolved
-
Normal
-
None
-
None
-
False
-
Moderate
-
sat-endeavour
-
None
-
None
-
None
-
None
Description of problem:
After updating a content host, and then running the api/hosts/[ID]/traces command to list the services that need restarting, the auditd service is being shown to be restarted with the systemctl command:
{ "id": 20, "application": "auditd", "helper": "systemctl restart auditd", "restart_command": "systemctl restart auditd", "app_type": "daemon", "host_id": 10, "host": "rhel9.example.com", "reboot_required": false },
However, this doesn't work, as the auditd command can't be restarted with systemctl:
systemctl restart auditd Failed to restart auditd.service: Operation refused, unit auditd.service may be requested by dependency only (it is configured to refuse manual start/stop). See system logs and 'systemctl status auditd.service' for details
And running the traces/resovle api call will result in the same error in the dynflow remote execution task:
--- proxy_output: result: - output_type: stdout output: | Failed to restart auditd.service: Operation refused, unit auditd.service may be requested by dependency only (it is configured to refuse manual start/stop). See system logs and 'systemctl status auditd.service' for details.
This kcs explains that the service command should be used instead:
https://access.redhat.com/solutions/2664811
How reproducible:
always
Is this issue a regression from an earlier version:
No
Steps to Reproduce:
1. Update a content host
2. Run the traces api call to list the services needing a restart
3. If auditd is present, it will show it should be restared with systemctl
Actual behavior:
Traces api call will try and restart auditd with systemctl
Expected behavior:
Traces api call should try and restart auditd with the services command
Business Impact / Additional info: