[2013/04/30 03:19:58] #net-snmp <grummund> Hi all
[2013/04/30 03:20:55] #net-snmp <grummund> Anyone know if it's possible to specify explicitly the engineID value for snmpd ?
[2013/04/30 03:50:31] #net-snmp <grummund> the engineID can be queried by the client using:
[2013/04/30 03:50:39] #net-snmp <grummund> $ snmpget host SNMP-FRAMEWORK-MIB::snmpEngineID.0
[2013/04/30 03:51:03] #net-snmp <grummund> SNMP-FRAMEWORK-MIB::snmpEngineID.0 = Hex-STRING: 80 00 1F 88 80 .. .. .. ..
[2013/04/30 03:51:47] #net-snmp <grummund> but when i specify engineID in /etc/snmp/snmpd.conf the same request yields the response:
[2013/04/30 03:51:56] #net-snmp <grummund> snmpget: Timeout (error parsing contextEngineID from scopedPdu)
[2013/04/30 09:47:51] #net-snmp <rstory-work> grummund: the engineID is set in the persistent conf file.. usually /var/net-snmp/snmpd.conf
[2013/04/30 11:32:02] #net-snmp <fenestro> grummund: when you changed the engine-id, did that invalidate your localized user configuration?
[2013/04/30 12:01:57] #net-snmp <grummund> fenestro: it may have done... i have tried so many things since ;-/
[2013/04/30 12:03:25] #net-snmp <grummund> i did finally have it so that snmpget host SNMP-FRAMEWORK-MIB::snmpEngineID.0 responded with a hex string, but it was not the one i specified in /etc/snmp/snmpd.conf
[2013/04/30 12:04:04] #net-snmp <grummund> i did not try putting engineID directly in /var/net-snmp/snmpd.conf
[2013/04/30 12:17:42] #net-snmp <fenestro> if you use the "engineID" configuration net-snmp will set the first 5 octets itself
[2013/04/30 12:17:56] #net-snmp <fenestro> you can use exactEngineID if you want to set all of the octets yourself
[2013/04/30 13:09:33] #net-snmp <grummund> fenestro: thank you for that. i shall try i tomorrow
[2013/04/30 13:09:36] #net-snmp <grummund> *it
[2013/04/30 19:44:25] #net-snmp <Matt_P> hey guys
[2013/04/30 19:44:52] #net-snmp <Matt_P> how often does std transport get used ?
[2013/04/30 20:00:31] #net-snmp <rstory-work> Matt_P: not often.. (assuming std means the stdin/stdout transport, not the 'standard' upd transport)
[2013/04/30 20:03:47] #net-snmp <Matt_P> ye stdin/out
[2013/04/30 20:03:56] #net-snmp <Matt_P> its the only thing I can see that calls sleep() in 5.5
[2013/04/30 20:04:15] #net-snmp <Matt_P> (currently debugging late sigalrm problems)
[2013/04/30 20:05:08] #net-snmp <rstory-work> hmm.. i don't think it's used internally.. only when explicitly set via config or cli..
[2013/04/30 20:05:30] #net-snmp <Matt_P> the std transport ?
[2013/04/30 20:05:36] #net-snmp <Matt_P> thats what I thought, oh well
[2013/04/30 20:05:38] #net-snmp <rstory-work> right..
[2013/04/30 20:06:04] #net-snmp <Matt_P> maybe wouldnt have made sense anyway as we do get the sigalrm.. just late
[2013/04/30 20:06:08] #net-snmp <rstory-work> most common usage of std would be for the ssh transport, iirc..
[2013/04/30 20:06:17] #net-snmp <Matt_P> thanks for your help
[2013/04/30 20:06:26] #net-snmp <rstory-work> np
[2013/04/30 20:06:43] #net-snmp <Matt_P> any idea why linux would delay signal handling to a process? :D
[2013/04/30 20:08:57] #net-snmp <rstory-work> not of the top of my head.. could the signal be blocked? can't recall if linux queues or drops a signal that's blocked..
[2013/04/30 20:09:14] #net-snmp <rstory-work> how late is it?
[2013/04/30 20:12:02] #net-snmp <Matt_P> 20ms to (1.5 -> 10s)
[2013/04/30 20:12:10] #net-snmp <Matt_P> and blocked signals are queued
[2013/04/30 20:12:11] #net-snmp <Matt_P> we do block
[2013/04/30 20:12:22] #net-snmp <Matt_P> we thought maybe our unblock was failing, but thats not the case
[2013/04/30 20:13:02] #net-snmp <Matt_P> im not sure how to debug this deeper tbh
[2013/04/30 20:13:53] #net-snmp <Matt_P> ive finally found other people having a similiar problem buit without solution: http://www.linuxforums.org/forum/programming-scripting/133921-signal-handlers-random-large-delay.html
[2013/04/30 20:39:00] #net-snmp <Matt_P> thanks :) cya
<-- Matt_P has left #net-snmp