snmpcollector fails to start with "Bind Exception" [8000-232] and NoClassDefFoundError

Products

• DX Unified Infrastructure Management (Nimsoft / UIM)

Issue/Introduction

The snmpcollector probe fails to start and remains in a "starting" state. It does not obtain a port or PID in the Infrastructure Manager or Admin Console.

The snmpcollector.log (at loglevel 5) shows the following stack trace:

ERROR Exception thrown creating StoreManager : Error opening database: "Bind Exception" [8000-232]Exception thrown initializing database: Error opening database: "Bind Exception" [8000-232]stderr: java.lang.NoClassDefFoundError: Could not initialize class com.nimsoft.probes.network.snmpcollector.database.PMFCaused by: java.lang.ExceptionInInitializerError: Exception java.lang.RuntimeException: javax.jdo.JDOFatalInternalException: Error opening database: "Bind Exception" [8000-232]

Environment

DX UIM any version

snmpcollector any version

Cause

The error indicates that the probe's internal H2 database (snmpcollector.mv.db) is locked. This typically occurs because:

1. A "zombie" Java process from a previous probe instance is still running and holding the file handle.
2. A stale .lock.db file was left behind after an ungraceful shutdown or server crash.
3. The database file has become corrupted due to the unexpected termination.

Resolution

Step I: Terminate Orphaned Processes

1- Deactivate the snmpcollector probe.
2- Log in to the robot server hosting the probe.
3- Check for any orphaned Java processes related to the probe:

Windows: Use Task Manager to find java.exe processes associated with the snmpcollector directory.
Linux: Run ps -ef | grep snmpcollector and kill any remaining PIDs.

Step II: Clear Stale Lock Files

1- Navigate to the probe installation directory: <Nimsoft_Installation>/probes/network/snmpcollector/.
2- Locate any files with the extension .lock.db (e.g., snmpcollector.lock.db).
3- Delete these lock files.

Step III: Recover the Database (If corruption is suspected)

If the probe still fails to start after clearing locks:

1- Deactivate the probe.
2- In the probe directory, move snmpcollector.mv.db and dbbackup.zip to a temporary folder outside of the Nimsoft path.
3- Activate the probe. The probe will automatically generate a fresh database and rebuild monitoring profiles from the discovery_server.

Note: Manual overrides, such as "User defined property" fields, may need to be re-entered if a fresh database is created.

Step IV: Enable Multi-Connection Mode (Preventative)

1- Open snmpcollector in Raw Configure.
2- Navigate to the setup section.
3- Add or modify the following key:

Key: DB_SERVER_MODE
Value: true

4- Apply the changes and restart the probe. This allows the database to handle multiple connection attempts and recover more gracefully from locks.

Additional Information

If steps above fails to correct the issue, it means that the internal database (snmpcollector.mv.db) hasn't just been locked, it has been corrupted by the crash. You will need to move it out of the way so the probe can generate a fresh one:

   -  Deactivate the snmpcollector probe again.

   -  In the snmpcollector probe directory, move the following files to a temporary backup folder on your desktop (do not delete them permanently yet, just in case):

        dbbackup.zip

        All files starting with snmpcollector.mv. (specifically snmpcollector.mv.db and snmpcollector.trace.db).

    - Activate the probe.

Once activated, the probe will generate a brand new database and automatically query the discovery_server to seamlessly rebuild your monitoring profiles.

    Please note that rebuilding the database restores all profiles pulled via discovery_server. However, if you previously made manual override additions directly in the snmpcollector UI (such as custom "User defined property 1" values), those specific manual tweaks will need to be re-entered.