Dev: creating new trap handlers

Hello

I am working on snmptrap handling, and I found the following issue:
If I add the new handled trap in /opt/librenms/config/snmptraps.php, nothing happens. Seems that the file is not at all read. And if I grep on snmptraps.php, it is clearly not called manually (could be some kind of autoloader).

If I manually edit /opt/librenms/bootstrap/cache/config.php, everything works perfectly. So my class definition for trap handling is probably good.
And if I delete /opt/librenms/bootstrap/cache/config.php, the file is not recreated and all is working perfectly good.

Does somebody have a tip on why config/snmptraps.php is not read at all in my env when cache file is there? Maybe @TheGreatDoc ? :slight_smile:
Any tips on how to force refresh the cache file ?

Thanx

Hello!

Did you check https://docs.librenms.org/#Developing/SNMP-Traps/ ?

Yup, and everything works perfectly except that the snmptrap.php is never executed … I had to remove the cache file (/opt/librenms/bootstrap/cache/config.php) to get it to work.

There is nothing about this behaviour in the doc, so that’s why I wonder if it is normal (and then I’ll document it) or if it is a bug (and then I’ll be happy to help solving it).

PipoCanaja

you mean /opt/librenms/snmptrapd.php is never executed?

That script should be exec by the snmptrapd.

Check https://docs.librenms.org/#Extensions/SNMP-Trap-Handler/

Nope, that one works perfectly. The one that does not trigger is /opt/librenms/config/snmptraps.php. The values in /opt/librenms/bootstrap/cache/config.php are used instead. I had to delete /opt/librenms/bootstrap/cache/config.php to get /opt/librenms/config/snmptraps.php to be loaded, and I wonder how this caching mecanism is supposed to work …

Ok. I understand you now.

Maybe php artisan cache:clear will do the work instead of manually deleting the file

Did not delete the file either. And if I delete it manually, the file was not re-created. Only

bootstrap/cache/services.php

was updated with

php artisan cache:clear

If this file can be safely deleted, I’m fine, but I wonder how other setups would behave in the same situation…
(I have the issue on the production server, that is clean, and not on the dev server that is theoretically not as clean …)

Maybe @murrant can say something about this

@PipoCanaja You ran php artisan config:cache on that server. If you do that, changes to the config will not be updated unless you re-run it or remove it with php artisan config:clear.

I’d suggest NOT running php artisan config:cache.

Ok.

So we have now an explanation. I won’t run it again :wink:

Thanx