Many newer Linux distributions now use systemd to manage services and daemons at boot, replacing the legacy System-V init scripts. While there is some legacy support for such init scripts in systemd, there are many useful features in systemd that are not available in the legacy and there is no guarantee that the legacy support will continue to remain in future releases of Linux Operating System.
This article gives some examples of how to create and enable a CA Workload Automation Agent service using systemd.
Basic Service 'unit' File Example
The key part of the systemd enablement is the creation of the unit file. Simply put, the unit file is a configuration file that systemd uses to configure and manage the unit.
Here is a systemd unit file for the CA WA System Agent service, at its simplest form.
# CA WA Agent systemd file (ca-wa-agent.service)
# Description of the service:
Description=CA Workload Automation Agent
# Starts CA WA Agent only after the following services are ready:
# local-fs, remote-fs, network, sockets, chronyd (or ntpd).
After=local-fs.target remote-fs.target network.target sockets.target chronyd.service
# Service directives follow:
# CA WA Agent is started by system call fork(),
# most suitable for daemonized services:
# Command to start the CA WA Agent service:
# Command to stop the CA WA Agent service:
# Sets the working directory for service:
# Describes the target for this service:
Save this file as ca-wa-agent.service inthe directory used for staging unit files /etc/systemd/system/
# ls -l /etc/systemd/system/ca-wa-agent.service
-rw-r--r--. 1 root root 306 Jul 21 01:39 /etc/systemd/system/ca-wa-agent.service
Now, we have the unit file ready. The following steps will set the CA WA Agent service up for systemd.
Tell the systemd that there's a new service unit file:
# systemctl daemon-reload
Read the service's unit file content using systemctl:
Enable the service (without this the service won't start-up on system boot):
# systemctl enable ca-wa-agent.service
Created symlink from /etc/systemd/system/multi-user.target.wants/ca-wa-agent.service to /etc/systemd/system/ca-wa-agent.service.
Start the service:
# systemctl start ca-wa-agent.service
Check the status of the service:
# systemctl -l status ca-wa-agent.service
? ca-wa-agent.service - CA Workload Automation Agent
Loaded: loaded (/etc/systemd/system/ca-wa-agent.service; enabled; vendor preset: disabled)
Active: active (running) since Sat 2017-08-19 23:28:08 EDT; 1min 11s ago
Process: 30879 ExecStart=/opt/CA/WA_Agent/cybAgent -a (code=exited, status=0/SUCCESS)
Main PID: 30881 (cybAgent.bin)
??30881 ./cybAgent.bin -a
Aug 19 23:28:08 lod-rhel7 systemd: Starting CA Workload Automation Agent...
Aug 19 23:28:08 lod-rhel7 systemd: Started CA Workload Automation Agent.
# ps ewwf 30881
PID TTY STAT TIME COMMAND
30881 ? Ssl 0:04 ./cybAgent.bin -a OLDPWD=/opt/CA/WA_Agent LD_LIBRARY_PATH=/opt/CA/WA_Agent:/opt/CA/WA_Agent/jre/lib/amd64/server:/opt/CA/WA_Agent/jre/lib/amd64: PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin PWD=/opt/CA/WA_Agent LANG=en_US.UTF-8 SHLVL=0
# cat /opt/CA/WA_Agent/status
CA Workload Automation Agent for Linux 11.3, Build 979
Started at: Sat Aug 19 23:28:08 2017
OS component - 30881
Stop the service:
# systemctl stop ca-wa-agent.service
# cat /opt/CA/WA_Agent/status
Other useful systemd directives
Unit files may contain additional options on top of those listed above. For instance, it is possible to set up the CA WA Agent service to be started by a specific OS user, let's say, autosys. Since the CA WA Agent inherits user limits (ulimits) of the user, the agent process (./cybAgent.bin -a) runs as, we can additionally specify custom limits on resources in the systemd unit file.
The unit file (/etc/systemd/system/ca-wa-agent.service) below tells systemd to run the CA WA Agent service as autosys user with unlimited nproc (maximum number of processes) and nofile (maximum number of open file descriptors).
DISCLAIMER: All examples in this article are provided as-is without warranty of any kind and will likely require modification and extensive testing prior to being used in any production environment. CA Technologies further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use of the examples and documentation remains with you. In no event shall CA Technologies, its authors, or anyone else involved in the creation, production, or delivery of the documentation be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the examples or documentation, even if CA Technologies has been advised of the possibility of such damages.
For more information about systemd and how to configure, control, or troubleshoot configuration, please have a look at the systemd project home page.