While not being anything noticeable by itself, the problem was that all monitored snmp values were normal but cpu showed 100% on the Open server with 8 CPUs , it did remind me that you should always record the current state before doing the changes. As I said it was an open server that client monitors with snmp and suddenly it alerted on CPU 100% and as this server has 8 CPUs it was clear that snmp daemon feels bad. Also the solution was obvious – restart the snmp daemon on the Checkpoint server. So I found all the instances of snmp running :
ps ax | grep snmp
1061 ? S 0:08 /usr/sbin/snmpd -Lsd -Lf /dev/null -p /var/run/snmpd -a -c /etc/snmp/snmpd.users.conf 161 1066 ? S 0:00 /usr/sbin/cpsnmpagentx 5808 ? S 0:00 /opt/CPshrd-R65/bin/cpsnmpd -p 260 18973 ttyp1 S 0:00 grep snmp
Then sent kill signal to each one of them , all went ok. But then my ssh session got abruptly disconnected for unrelated reason, so I didn’t have the list of commands and their options seen above and therefore couldn’t restart them. I do have the privilege of access to the heap of other Checkpoint machines so I just enterd one of them and copied snmp daemon commands from there, but if had no such alternative the time consuming search on the Google/cpug.org would have been granted.
Conclusion – before altering some state take note of the current one and record it somewhere (Notepad++ rules here).