The unisrvcntr command exits immediately and will not start an AutoSys service
Article ID: 251608
Updated On:
Products
Issue/Introduction
Scenario 1:
When attempting to start an AutoSys service using 'unisrvcntr start <service_name>', it immediately exits to a prompt with no output and the service is not started.
Scenario 2:
on GCP Linux VM while using the unisrvcntr command try to run start/ stop or status commands it is not executing and services are not being started on VM autosys sched, app, and agent services.
The command throws the below error message.
Can you help me with what is blocking here?
waae_sched.RC7.service - LSB: AutoSys Workload Automation Scheduler
Loaded: loaded (/etc/rc.d/init.d/waae_sched.RC7; generated)
Active: failed (Result: exit-code) since Tue 2022-09-06 15:46:35 UTC; 6 days ago
Docs: man:systemd-sysv-generator(8)
Sep 06 15:46:35 ats-int-waae systemd[1]: Starting LSB: AutoSys Workload Automation Scheduler...
Sep 06 15:46:35 ats-int-waae waae_sched.RC7[18149]: /etc/profile.CA: line 9: /atsope01/logiciel/Autosys/SharedComponents/Csam/SockAdapter/scripts/csamsetlibpath.sh: Permission denied
Sep 06 15:46:35 ats-int-waae systemd[1]: waae_sched.RC7.service: Control process exited, code=exited status=1
Sep 06 15:46:35 ats-int-waae systemd[1]: waae_sched.RC7.service: Failed with result 'exit-code'.
Sep 06 15:46:35 ats-int-waae systemd[1]: Failed to start LSB: AutoSys Workload Automation Scheduler.
Scenario 3:
When attempting to start an AutoSys service using 'unisrvcntr start <service_name>', it immediately exits to a prompt with no output and the service is not started.
Environment
Release : 11.3.6/12.0/12.0.1
Component : CA Workload Automation AE (AutoSys)
O/S: Linux
Resolution
There are two possible solutions to this issue:
Scenario 1 Solution:
Run 'unisrvcntr stop <service_name>' once and then run 'unisrvcntr start <service_name'.
The service should start after that.
NOTE:
When you start the AutoSys services using unisrvcntr, it creates files under /var/lock/subsys for each service.
When you stop the services using unisrvcntr, those files are removed.
The unisrvcntr command will check /var/lock/subsys when you run 'unisrvcntr start <service_name>' and if the file for that service exists, it assumes the service is already running.
It will then just exit to the command prompt with no output.
If one of the AutoSys services ever stops outside of unisrvcntr (crash, STOP_DEMON, etc.), the file in /var/lock/subsys for that service does not get removed.
Therefore, when you try to start it back up with unisrvcntr, it just exits to a prompt.
If you run a stop on the service first, that will remove the file and allow the service to be started again by unisrvcntr.
Scenario 2 Solution:
The encountered problem was related to "SELinux” not allowing the systemd to execute the necessary files.
You can consult the following Red Hat documentation page for more information :
Chapter 2. Changing SELinux states and modes
Resolved by setting selinux=permissible and now it is working fine.
Scenario 3 Solution:
If the application terminated unexpectedly the /etc/init.d command will not work properly.
You will need to use:
systemctl start <Service name>:
Example:
systemctl start waae_sched.PRN
Feedback
