Troubleshooting Oracle Inventory Using the FlexNet Inventory Scanner

FlexNet Manager Suite 2022 R1 (On-Premises)

If you are using the FlexNet Inventory Scanner for Oracle discovery and inventory collection, a successful installation and invocation of the FlexNet Inventory Scanner is a prerequisite. As these processes are entirely in your control, the following guide assumes that you have validated them first.

To troubleshoot Oracle discovery and inventory gathering by the FlexNet Inventory Scanner:

  1. Before concluding that there is a problem, ensure that you have allowed sufficient time for:
    • Discovery and inventory processes on the target device (check the schedule you have configured for the FlexNet Inventory Scanner, and allowing just a few minutes to gather inventory, even for a large server)
    • File upload to the inventory beacon, and from there to the central application server (typically within several minutes of the data gathering being completed)
    • Inventory import from the inventory database to the main compliance database (typically scheduled overnight)
    • The license reconciliation calculations (typically scheduled overnight).

    If, after this process has completed, the target Oracle server does not appear in Discovery & Inventory > All Discovered Devices, it is time to continue troubleshooting. (If the device does appear in this listing, but the Oracle instance is not visible in Discovery & Inventory > Oracle Instances, skip forward to step 4.)

  2. On the target Oracle server, examine the tracker log file in the appropriate folder from this list:
    • On Windows: %temp%\ManageSoft\tracker.log (where $(TempDirectory) is the temporary folder for the account running the tracker), or your chosen location if you redirected the logging at the command line.
    • On UNIX-like platforms:
      • When the executable has run as the root account, in /var/tmp/flexera/log
      • When the executable has been run by any other user account (represented as UserName), in /var/tmp/flexera.UserName/log.
      • Your chosen location if you redirected the logging at the command line or in the ndtrack.ini file of preferences on UNIX-like platforms.
    Verify the following events:
    • The event Uploading file <filename.disco> indicates the generation of the discovery file has succeeded (upload is normally attempted immediately after creation of the discovery file).
    • The event File <filename.disco> removed from upload directory indicates the successful upload of the discovery file.
  3. If there is no evidence of a successful upload:
    1. Check the discovery upload folder on the target Oracle server, since files should be left behind when upload fails:
      • On Windows: $(TempDirectory)\FlexeraSoftware\, where $(TempDirectory) is the temporary directory for the account that is running the FlexNet Inventory Scanner
      • On UNIX-like platforms:
        • When the executable has run as the root account, in /var/tmp/flexera/uploads/Discovery
        • When the executable has been run by any other user account (represented as UserName), in /var/tmp/flexera.UserName/uploads/Discovery.
    2. If the relevant discovery upload folder still contains the .disco file, discovery is working but uploads are failing:
      • Double-check that the tracker command line options passed to the FlexNet Inventory Scanner correctly identified an accessible upload location on the correct inventory beacon.
      • Ping or otherwise check network access from the target Oracle server to the inventory beacon.
      • Ensure that the ManageSoftRL file share remains configured on the relevant inventory beacon (it is configured as part of the installation of the inventory beacon) and accessible.
      • Can you be sure there wasn't an intermittent network problem at last inventory time?
    3. If the relevant discovery upload folder on the target Oracle server is empty, upload to the inventory beacon may have worked as the first stage, and you can check for a later problem in the upload chain:
      Switch to the relevant inventory beacon, and:
      • Check $(CommonAppDataFolder)\Flexera Software\Incoming\Inventories. This is the staging folder for data uploaded from target devices but not yet uploaded to the parent of this inventory beacon. If a file is still here, the upload from this inventory beacon to its parent (another inventory beacon) has failed.
      • Check logs for any issues in $(CommonAppDataFolder)\Flexera Software\Compliance\Logging\BeaconEngine.
  4. If discovery is working but Oracle inventory is not, the target Oracle server is visible in Discovery & Inventory > All Discovered Devices, but there is no record of the Oracle instance(s) running on that server in Discovery & Inventory > Oracle Instances. To troubleshoot, return to the log file for the ndtrack component on the target Oracle server:
    Verify the following events:
    • Starting oracle inventory and Finished generating inventory indicate the start and end of the Oracle inventory collection process.
      Note: On a UNIX-like platform, the tracker attempts to use setuid to impersonate an appropriate user to gather Oracle inventory. If you are using eTrust Access Control on this server, by default it does not permit this impersonation, and inventory gathering fails. The fix is to change the configuration of eTrust to include ndtrack in the LOGINAPPL class. For more information, see the eTrust Access Control Administration Guide (
    • Uploading file <filename (Oracle).ndi.gz> indicates the upload of the compressed Oracle inventory file.
    • File <filename (Oracle).ndi.gz> removed from upload directory indicates the successful upload of the inventory file.
    Troubleshooting uploads is the same as covered earlier.
  5. If Oracle Database inventory gathering is failing, first ensure that the appropriate account can use sqlplus to connect to the database instance:
    1. Identify the account relevant to this database instance. For example, on UNIX-like platforms:
      • If you are using the OracleInventoryUser preference on this inventory device (server), use that account
      • If not, identify the account that started the database instance. For example, the following command line lists all database instances on this server in the format oraclesid_smon_ORACLESID (the placeholders are replaced with the instance's system identifier in lower- and upper-case), with each row beginning with the relevant account name for that instance:
        ps -ef | grep smon 
    2. Validate whether the OracleInventoryAsSysdba preference (in the config.ini file for the local FlexNet inventory agent on UNIX) has been set to false. This determines the command line parameters:
          sqlplus "/ " # when OracleInventoryAsSysdba=false
          sqlplus "/ as sysdba" # in all other cases 
    3. Still using UNIX as our example, log in as root (the FlexNet inventory agent runs with this level of privilege to collect Oracle Database inventory, and using this saves you providing a password with the su command), and then switch to the identified account to run sqlplus, ensuring that the environment variables are set for the Oracle home directory and the system identifier (SID) for the current database instance:
          su accountUnderTest
          export ORACLE_HOME=OracleHomeDirectory
          export ORACLE_SID=OracleSID
          cd $ORACLE_HOME/bin
          ./sqlplus "/ as sysdba" # or modified as noted above
      If the connection is successful, sqlplus prints a Connected to: summary for the current database instance. Validate that the permissions are adequate and the database instance is fully operational with a test query such as:
      A response of the full version ID for the Oracle Database confirms that inventory collection can proceed.

    If you cannot connect successfully, ask your Oracle DBA for assistance to resolve the problem. If connection was successful, continue with the following checks.

    • On UNIX-like systems, check whether the OracleHomeDirectory/bin/oracle executable may have been upgraded or replaced without restarting the database instance. Remember that the tracker examines process listings, and if the original process was not restarted, it is now referencing a file that is no longer available, because it has been updated or replaced. If you cannot determine whether the executable has been changed, restart the database instance to test whether this clears the problem. Of course, if the executable has been changed, a process restart is essential, if for no other reason than to allow the database instance to utilize the updated code.
    • Also on UNIX-like platforms, verify which version of the ndtrack executable is collecting inventory (versions earlier than 13.0.1 may fail to gather Oracle inventory on servers where permissions have been tightened to prevent global read access to Oracle directories or files). Use any of the following methods to verify the version of ndtrack:
      • If you already have a discovered device record for the server, navigate to its discovered device properties, select the Inventory evidence tab and the Software sub-tab. Find FlexNet inventory agent in the listing, which includes its version. (On UNIX-like platforms, for legacy reasons, this is listed as ManageSoft for platform Managed Devices.)
      • On the target inventory device (the Oracle server), read /var/opt/managesoft/etc/config.ini in a text editor, and validate the version of the inventory agent saved in the read-only ETCPVersion preference.
        Never edit this value manually.
      • Examine the log file for ndtrack, as this reports the version of the agent in use. The default paths for logging depend on the inventory collection method:
        • For the locally-installed FlexNet inventory agent, see /var/opt/managesoft/log/tracker.log (or check for a custom value saved as ManageSoft\Tracker\CurrentVersion\LogFile in the /var/opt/managesoft/etc/config.ini file)
        • For the lightweight FlexNet Inventory Scanner (presented as on UNIX-like systems), and also for zero footprint inventory collection, see /var/tmp/flexera/log/tracker.log
          Tip: If is executed by a non-root account userName, the log defaults to: /var/tmp/flexera.userName/log/tracker.log.
      • Open an .ndi file saved on the locally-installed FlexNet inventory agent, which reports the version creating the file. Between inventory collections, the most recent inventory file is saved on the inventory device in /var/opt/managesoft/tracker/inventories, and the version appears at the top of the file as the Tracker attribute of the Inventory XML element.
      • If you are using, this command line reports the version:
            cd directoryContainingScanner
            ./ --version
    • On all operating systems, if the preference OracleInventoryAsSysdba=true or is not specified (when the default is also true), make sure that the account running the database instance is listed in the ORADBA group (the local ora_dba security group on Windows and the dba group on UNIX-like platforms). By default this group exists, and the account running the instance is listed in it; but it is possible that the group has been removed on [some of] your Oracle servers. For full details about alternative accounts and all account requirements, see the OracleInventoryUser and OracleInventoryAsSysdba preferences in the Gathering FlexNet Inventory PDF, available through the title page of online help.
If the problem persists, please contact Flexera Support with the full details and the appropriate log files.

FlexNet Manager Suite (On-Premises)

2022 R1