This document contains official content from the BMC Software Knowledge Base. It is automatically updated when the knowledge article is modified.
TrueSight Capacity Optimization
TrueSight Capacity Optimization 11.0, 10.7, 10..5, 10.3, 10.0
Should I see the bgssd.exe process running on my Unix/Linux machines? On some machines I see the process running all the time but on other machines I don't see the bgssd.exe process running but I still have complete connectivity to the machine. What determines if the Service Daemon will be always running or not?
There are two different ways to configure the Service Daemon on Unix/Linux:
(A) Standalone mode (where the '/etc/bgs/SD/bgssd.exe -d /etc/bgs/SD -s' will always be up and running and listen directly on port 10128 and spawn off a separate process to handle requests
(B) Via [x]inetd where xinetd is listening on port 10128 and will start a Service Daemon process and pass requests onto it when it receives them
In general, if you see a LISTEN return from 'netstat -an | grep 10128' that will mean that the Service Daemon is configured on the machine.
If you run 'telnet localhost 10128' and then press ENTER you want to receive an 'SDPACK' message which is a very good indicator that the Service Daemon is configured on that machine.
Thus, if the bgssd.exe process isn't running but 'netstat -an | grep 10128' shows a LISTEN on port 10128 and the Service Daemon responds with the SDPACK message the expectation is that the machine has the Service Daemon configured to be executed by xinetd -- so xinetd is listening on port 10128 on the Service Daemon's behalf.
You can see how the machine was configured by the b1configVVVV.sh script (the root configuration script which generally configures the product on the machine) by checking the /[TSCO Installation Directory]/.b1configVVVV.sav file where VVVV is the product version, such as 10700.
In that file you'll find a line like this:
A 'y' there indicates that the b1configVVVV.sh script is going to attempt to configure the Service Daemon to run in standalone mode. A 'n' there indicates that it is going to attempt to configure xinetd to listen on port 10128 for the Service Daemon and pass requests it receives onto it.
That isn't a perfect indication though of the configuration since the b1configVVVV.sh can decide that the requested configuration isn't possible on the machine in question and change how it configures the during the configuration. There will be messages related to the Service Daemon configuration in the /[TSCO Agent Installation Directory]/B1DS_Release_V.V.VV_[datestamp] root configuration script log file.
One question to ask is whether there are any data collection problems on the machine.
This KA is a bit old but describes using the 'best1collect -q' command to test that a machine has received a collection request and is attempting to collect data for a Gateway Server(GWS):
000031506: What is the best way to test a new Perform agent installation to verify data collection is working properly on the machine? (https://bmcsites.force.com/casemgmt/sc_KnowledgeArticle?sfdcid=000031506)
If there is a collection problem to debug on this machine, capture and send the following to Technical Support, either:
(A) The entire contents of the $BEST1_HOME/bgs/log directory from the machine having the problem
-- or --
(B) The output of the bgsagent_logs command run against that machine.
000090065: Capturing the Perform log files from the remote node (https://bmcsites.force.com/casemgmt/sc_KnowledgeArticle?sfdcid=000090065)