Automic Workload Automation

systemd unit file for CA Automic Service Manager without wrapper script 

07-11-2018 10:03 AM

The installation documentation for CA Automic Workload Automation or CA Automic Service Manager does not provide a example how to set up the Service Manager autostart with systemd. To get this working cost me a lot of time and i like to share the problems and solutions with the community to help others setting up.

 

The following script ist tested with version 12.2 of the CA Automic Service Manager on a Suse Linux Enterprise Server 12 Service Pack 3 but will work also on other linux systems using systemd.

 

The most important fact about systemd is, that it will ignore any profile, bashrc and envfile for the user you supply for the deamon to run. Paying attention to this fact you need to declare all variables to the Service Manager process which are needed by the child processes started via the Service Manager. For communication (cp) and work processes (pwp, wp) you need to provide the oracle variables like TNS_ADMIN, ORACLE_HOME and the path to oracle libraries at LD_LIBRARY_PATH. If you are using the CA Private Key Infrastructure the variables CALIB, CABIN annd CASHCOMP need to be provided.

 

Important: Don't set the CA Service Manager bin directory or other Automion Engine directories in the LD_LIBRARY_PATH. This can cause serious problems with Zero Downtime Upgrade (ZDU) as Carsten_Schmitz mentioned in his disccussion PSA: $LD_LIBRARY_PATH (again), now with bonus ZDU troubles. A possible solution is to work with the unit file section WorkingDirectory set to the bin directory of CA Automic Service Manager. 

 

# Systemd unit file for Automic Service Manager
[Unit]
Description=Automic Service Manager
Requires=network-online.target
After=network-online.target

[Service]
Type=simple

Environment=LD_LIBRARY_PATH=/oracle/client/12x/client/lib:/usr/lib:/lib
Environment=TNS_ADMIN=/opt/uc4
Environment=ORACLE_HOME=/oracle/client/12x/client
Environment=CALIB=/opt/uc4/capki/lib
Environment=CABIN=/opt/uc4/capki/bin
Environment=CASHCOMP=/opt/uc4/capki

WorkingDirectory=/opt/uc4/smgr/bin

ExecStart=/opt/uc4/smgr/bin/ucybsmgr -i/opt/uc4/smgr/bin/ucybsmgr.ini UC4D
ExecStop=/bin/kill -15 $MAINPID

User=uc4srv
Group=uc4

TimeoutStartSec=10
TimeoutStopSec=15
RestartSec=10

[Install]
WantedBy=multi-user.target

 

If you like to have a central place to put all your enviromental variables on there is another elegant way to provide these to the CA Automic Service Manager process via the unit file. If you have declared all variables to the user you can use the ExecStartPre section to generate a environmental file.

 

ExecStartPre=/bin/bash --login -c '/usr/bin/env > /opt/uc4/env'
EnvironmentFile=-/opt/uc4/env

 

The hyphen before the environment file ignoring any error if the file does not exists or could not be read. You can prevent also a lot of odd errors if you work with absolute paths everywhere at the unit file. Also keep in mind, variable expansion does not work for Environment sections.

 

This document was written with help of the information of Carsten_Schmitz at discussion Besonderheiten bei Installation der Automation Engine auf Linux mit systemd / init.d

If you have additional information feel free to comment or write me message.

Statistics
0 Favorited
3 Views
0 Files
0 Shares
0 Downloads

Tags and Keywords

Comments

07-12-2018 05:18 AM

I read your discussion and will update and test the unit file with your hints.

07-12-2018 05:10 AM

Good stuff.

 

One extra annotation to avoid a major pitfall:

 

you need to provide the oracle variables like TNS_ADMIN, ORACLE_HOME and the path to oracle libraries at LD_LIBRARY_PATH

 

this is correct. But never ever include directories with Automic libraries in the LD_LIBRARY_PATH. Doing this causes very exciting problems and has cost me the best part of a week. Actually, the

/opt/uc4/server/bin

as part of the $LD_LIBRARY_PATH in the example given above is something I would avoid at all costs, because you will sooner or later hit the same ZDU troubles I had, when running two Automic versions in "mixed mode", the way the ZDU is designed to be done, and when one set of libraries doesn't work with the binaries of the other version. The only safe way is to set the working directory to the service manager directory before starting the smgr binaries (as archaic and silly as that may be), so the smgr can use it's own shared objects, and then have the smgr set the correct working directory for any server binaries, so those can use their own respective shared objects from their own directories.

 

I wish Automic would care more about documenting this and not leave it to us, and how this is ever going to work with ZDU'ing the smgr itself is beyond me.

 

Best regards,

Related Entries and Links

No Related Resource entered.