TrueSight Capacity Optimization (TSCO) - After the installation of PATROL for Unix/Linux machine with an existing installation of Perform, the Perform agent is no longer working

Version 3
    Share This:

    This document contains official content from the BMC Software Knowledge Base. It is automatically updated when the knowledge article is modified.


    BMC Performance Assurance for Servers


    BMC Performance Assurance for Servers


    Servers upgraded from an older version to Patrol 9.0.20. Servers have both the BPA Performance Assurance (BPA) and Patrol agents installed on them. The BPA agent is still running at a backleveled version of BPA 7.5.10 because at this time the BPA consoles have not been upgraded.

    The PATROL installation image leaves Perform collection at 7.5.10 but enables BPA 9.0 dcm/bgscollect intergration for Patrol. After the install of PATROL, some installations have functional Patrol installs but the Perform Service Daemon is not communicating on port 10128 anymore. The Perform agent appears to still be correctly installed.

    Can I safely reinstall the BPA package to try to fix the BPA product? If so, since I'll be installing a back-leveled release of Perform which of the three PATROL interoperability options should I select: NONE, OLD, or NEW?

    LP: BMC Performance Assurance for Servers




    On one of the machines where the Perform agent isn't working run the following commands and send the output:

    • ls -l /usr/adm/best1_*
    • export BEST1_HOME=/usr/adm/best1_default
    • $BEST1_HOME/bgs/scripts/best1collect -q
    • ps -ef | grep bgs

    This will help to identify the communication problem, to answer the question: What error is being generated?

    Generally don't think that reinstalling the product on Unix is the right path forward for most problems (except where someone has manually deleted binaries from the $BEST1_HOME directory).

    Most problems can be more easily addressed by re-running the BPA root configuration script as the root user:
    # /[BPA Installation Directory]/ (where VVVV is the BPA product version, such as 7510 for BPA 7.5.10).

    If you are going to fully reinstall BPA 7.5.10 on the machine then the best option to select is the "NONE" integration option (such you don't want this install of BPA integrated with your BPPM install since it has a separate BPA 9.0 agent installation that it is integrated with). The benefit of selecting NONE is that this BPA Agent installation will totally ignore PATROL (it won't attempt to do any configuration of the PATROL Agent -- it will just leave it alone).

    > best1collect -q
    > Error: Unable to establish connection with service daemon
    > Connection refused. Most likely server is not running.
    > Tue Jan 28 09:28:18 2014
    > !Start: Request had no response from Service Daemon on node: [hostname]

    > ls -l /usr/adm/best1_*
    lrwxrwxrwx 1 root root 54 Sep 15 21:08 /usr/adm/best1_7.5.10 -> /apps/bmc/patrol/Patrol3/Linux-2-6-x86-64/best1/7.5.10
    lrwxrwxrwx 1 root root 54 Jan 23 01:11 /usr/adm/best1_9.0.00 -> /apps/bmc/patrol/Patrol3/Linux-2-6-x86-64/best1/9.0.00
    lrwxrwxrwx 1 root root 54 Sep 15 21:08 /usr/adm/best1_default -> /apps/bmc/patrol/Patrol3/Linux-2-6-x86-64/best1/7.5.10

    On a machine where the Perform product is working, can you run the following:
    ps -ef | grep bgssd

    Does that list a running bgssd.exe process?

    The problem is that the Service Daemon isn't listening on port 10128 on the machine.

    When they are doing the PATROL installation they aren't selecting the option to do a 'PATROL only' installation of the BPA product -- they are picking the option to do a full installation of the Perform agent on the machine. That is fine if you intend at some point in the future to begin using this full Perform version 9.0 agent installation on the machine for your BPA console. But it could be a problem if they aren't picking the correct options for configuring the Service Daemon.

    Assuming this problem is on Linux, please capture and send following additional output from this machine:
    * A copy of the /apps/bmc/patrol/Patrol3/B1DS_Release_9.0.00_* files
    * A copy of the /apps/bmc/patrol/Patrol3/B1DS_Release_7.5.10_* files
    * A copy of the /apps/bmc/patrol/Patrol3/.b1config9000.sav file
    * A copy of the /apps/bmc/patrol/Patrol3/.b1config7510.sav file
    * The output of 'rpm -qa | grep xinetd' from the machine
    * The output of 'uname -a'
    * The output of 'ls -l /etc/xinetd.d/bgssd'
    * A copy of the /etc/init.d/bgssd file
    * The output of 'netstat -an | grep 10128'
    * The output of 'ps -ef | grep xinetd'
    * The output of '/sbin/chkconfig --list'

    Note the .b1configVVVV.sav files are 'dot' files so you won't see then in 'ls' output you need to run 'ls -a' to see them.

    * How hard would it be to get someone with root access to run the following command on the machine:
    # service xinetd restart

    I think the problem you are likely to see is that there wasn't a LISTEN on port 10128 and, most likely, a restart of the xinetd process would have fixed that:
    # service xinetd restart

    Q: Is any of the debugging above applicable to Windows for the error message: "Error: Unable to establish connection with service daemon. Connection refused. Most likely server is not running"?


    For Windows machines the debugging path is very similar:
      (1) Identify if the problem is that the Service Daemon is the problem:

    best1collect -q

      (2) If so, validate that there is a LISTEN on port 10128:

    netstat -an | findstr 10128

      (3) Try to stop and restart the bgssd_service on the machine.

    But, there is no integration on Windows between PATROL and Perform so there shouldn't be any impact at all on Windows when you upgrade PATROL since it is a completely separate installation.

    Related Products:  
    1. BMC Performance Assurance for Servers


    Article Number:


    Article Type:


      Looking for additional information?    Search BMC Support  or  Browse Knowledge Articles