SSLOGGER process is not starting/restarting automatically.

book

Article ID: 225305

calendar_today

Updated On:

Products

CA Spectrum

Issue/Introduction

We would like to have sslogger process able to start and restart automatically. In this scenario, the Spectroserver process is always stopped and we only want sslogger to be running.

We have tested manually and the following works well:

/var/spectrum/sslogger/sslogger.01/logs/SSlogger -modelfile /var/spectrum/sslogger/sslogger.01/models.dat -datafile /var/spectrum/sslogger/sslogger.01/sslogger.dat

Here is the content of the sslogger .idb file:

cat /usr/SPECTRUM/lib/SDPM/partslist/SSLOGGER-01.idb

# Processd Install Ticket for SPECTRUM CLI Daemon.
PARTNAME;SSLOGGER-01;
APPNAME;SPECTRUM SSLOGGER Application;
WORKPATH;/var/spectrum/sslogger/sslogger.01/logs;
LOGNAMEPATH;$WORKPATH/../../../../log/spectrum/SSLOGGER.01.OUT;
ADMINPRIVS;Y;
AUTORESTART;Y;
AUTOBOOTSTART;Y;
#STATEBASED;N;
NUMPROCS;20; /
RETRYTIMEOUT;0; // seconds
TICKETUSER;spectrum;
RETRYMAX;10;     // retries
STARTPRIORITY;30;
SERVERPROCESS;Y;

If running "systemclt restart processd" or "processd --restart", the sslogger is never started. And we cannot see any erros in processd_log.

Cause

In this scenario, the STARTPRIORITY parameter value was configured in the sslogger .idb file to a value equal or higher than the value for the same parameter configured in ss.idb file.

Environment

Release : Any Spectrum supported version

Resolution

As mentioned in the .idb file above, the value configured for the STARTPRIORITY parameter is "30":

STARTPRIORITY;30;

According to the product documentation, here is the description of the STARTPRIORITY parameter and its default values:

https://techdocs.broadcom.com/us/en/ca-enterprise-software/it-operations-management/spectrum/10-4-3/administrating/distributed-spectroserver-administration/setting-up-a-distributed-spectroserver-environment.html

Since the sslogger STARTPRIORITY was set to "30", it was configured to depend on the Spectroserver process to be started first, what would never happen in this scenario, since the Spectroserver process was stopped in the machine, as mentioned previously.

The solution (in this scenario) is to configure a smaller value (for the STARTPRIORITY parameter) in the sslogger .idb file than the one configured in the ss.idb file.