The command still isn't run automatically. I worked it through with snmpset, and it seems to work, once, then the snmpset commands timeout.
Then this happens: [dave@localhost net-snmp-5.6.2.pre1]$ apps/snmpset -c dismanrw -M mibs -m ALL -v 2c 172.17.4.3:1161 prErrFix.2 = 0 UCD-SNMP-MIB::prErrFix.2 = INTEGER: noError(0) Okay! [dave@localhost net-snmp-5.6.2.pre1]$ apps/snmpset -c dismanrw -M mibs -m ALL -v 2c 172.17.4.3:1161 prErrFix.2 = 1 Timeout: No Response from 172.17.4.3:1161 So, this WORKED - process index #2 started, but I heretofore can not contact the daemon. This probably has something to do with authorization--so far that's been the norm-- I noticed there was a thread on this earlier, but there didn't seem to be any response. Thanks, Dave > > Hi, > > I am having trouble getting process restarts to work. I am > crosscompiling for ARM on i686 Linux and my configures and > makes are clean. > > I have been running the daemon with debugging set on. Here is a sequence > from what appears should be disman triggering a restart of a program. > > 62412 disman:event:trigger:monitor: Running trigger (restart > meter_service) > 62413 UCD-SNMP-MIB::prErrFix.3 = Wrong Type (should be INTEGER): Variable > has bad type > > Here is the config: > > 89 proc meter_service > 90 #setEvent -I prRestart_meter_service prErrFix.3 = 1 > 91 #setEvent -I prRestart_meter_service UCD-SNMP-MIB::prErrFix.3 = 1 > 92 setEvent prRestart_meter_service prErrFix.3 = 1 > 93 notificationEvent not_meter_service prNames.3 prCount.3 prErrMessage.3 > 94 monitor -S -e not_meter_service -u dismanrw -r 10 -o prNames.3 -o > prCount.3 -o prErrMessage.3 "meter_service DOWN" prCount.3 < 1 > 95 monitor -S -e prRestart_meter_service -u dismanrw -r 10 "restart > meter_service" prErrFix.3 1 1 > 96 procfix meter_service /root/meter_service -vector Voltage -port 8000 > -outfile /var/tmp/meterservice_history.out > > I have also tried various versions of EXPRESSION in the monitor command > (e.g., == 1), but hat doesn't make any difference. It appears the problem > is the 'setEvent'. Commented out attempts made no difference. > > Note that the notification sequence works just fine. > > If I just have: > > proc myProc > procfix myProc blah-de-blah > > in the config and no setEvent, I see messages like these that DON'T have a > problem with the the > type of prErrFix, so it seems setting it may be the culprit. > > results: UCD-SNMP-MIB::prErrFix.4 = INTEGER: noError(0) > > I have found a few threads on this topic, but nothing that really seems to > apply. Another theory is that this is just a cover for an access > violation, > i.e., but that doesn't really explain why the type is wrong on the disman > read. > > Thanks, > > Dave > > > > > > > > > Hi, > > Thanks! > > I was able to get it going by minimizing the access configuration > and cleaning up the monitor call, as you "pinged" below. I caught > the "-i" (a Doh! moment) mishap just before leaving for home, wasn't > sure I'd gotten it, though. > > Now I can't get "proc/procfix" to work: may soon see another thread about > that. I have not yet mastered the black art of remote gdb. I'll keep > you posted (I'm sure). > > Thanks again. > > D. > > >> >> So you do see the VACM message (plus memory leak) if you have >> two monitor lines: >> >> monitor -e prRestartMeter_service -u disman -r 1 -i prCount.3 < 1 >> monitor -e notMeter_service -u disman -r 1 -i .... "meter_service >> down" prCount.3 < 1 >> >> but not if you've just got the second line? >> > > The notification >> <ping> >> Of course - the first line (causing the problem) is missing the "NAME" >> field. >> So it's probably taking "prCount.3" as the name of the entry, and "< 1" >> as >> the expression to monitor. >> >> I'm a little surprised that the agent isn't complaining about this >> expression, >> but I suspect that if you add a name field "restart_meter", things >> should >> work OK. >> >> Try it. >> >> Dave >> > > > ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Net-snmp-users mailing list Net-snmp-users@lists.sourceforge.net Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users