Kaseya Community

KaseyaSNMPTrapHandler - MIB search path

  • Hi All,

    I activated the " SNMP Traps alert " on some managed servers ( 1 per customer ).

    Everytime the "KaseyaSNMPTrapHandler" service starts on these machine , in the application event log appear these errors :

    - MIB search path: c:/usr/share/snmp/mibs  <-- This folder doesn't exists.

    And many of the following :

    - Cannot find module (Mibmodulename): At line 0 in (none)

    In the server there is the folder " C:\usr\snmp\persist\mib_indexes" that contains the file "0" that refers to ax existent path ( C:\kaseya\usr\share\snmp\mibs ) that contains all SNMP modules.

    Is it normal ? Is it possible to modify the "MIB search path" ?

    Thank you in advance for any suggestion !




  • Marco,

    Hopefully you have already solved this problem, but since I don't see any followup I will tell you what I did as a workaround.

    I looked in my Agent Temp directory (which would normally be c:\kworking if we hadn't customized it) and found a \usr directory there, with all the "missing" files and subdirectories from c:\usr that were causing all of the event log errors.  So yeah, I just copied my (equivalent to) c:\kworking\usr tree to c:\usr and restarted the KaseyaSNMPTrapHandler service, which then started up without errors.

    I did find an snmp.conf and an snmpd.conf within that directory structure, which both showed the "kaseya temp directory" version of the path, but for whatever reason, in the Application Event Log, when the service starts up and there isn't a c:\usr copy of those files, it fails and shows an Error, ID 100, text is "MIB search path: c:/usr/share/snmp/mibs", same as you are seeing.

    So I just took the files it was looking for, and put them where it was looking, since it seems like the .conf files that point to the "correct" location aren't getting used.

    I haven't tried yet adding a command-line switch to the service itself to see if I can force it to use a different directory, or force it to use a specific .conf file, but I suspect that would be the next thing to try if I run across this again.