[2002/09/16 01:22:46] #net-snmp <df> morning peoples
--> wes has joined #net-snmp
--> wdebruij_ has joined #net-snmp
--> wdebruij_ has joined #net-snmp
[2002/09/16 06:40:30] #net-snmp <wdebruij_> hello
[2002/09/16 06:41:51] #net-snmp <wes> hi
[2002/09/16 06:42:18] #net-snmp <wdebruij_> I was wondering if my connection was cut off, it's so quiet here
[2002/09/16 06:42:35] #net-snmp <wes> sometimes it is. Sometimes it's more noisy. It all depends.
[2002/09/16 06:42:57] #net-snmp <df> oooh activity
[2002/09/16 06:43:09] #net-snmp <wdebruij_> wes, you helped me out with a callback session last thursda
[2002/09/16 06:43:54] #net-snmp <wes> yep. (and thanks for the context... My memory is filled with things like how to dereference a reference to an array containing a hash of ...)
[2002/09/16 06:44:45] #net-snmp <wdebruij_> I can understand that. When looking through the bugtracker this morning I occasionall found you're name, so you're probably heavily involved ;-)
[2002/09/16 06:45:06] #net-snmp <wes> heh.
[2002/09/16 06:45:08] #net-snmp <wes> some
[2002/09/16 06:46:35] #net-snmp <wdebruij_> well, the reason I am here is probably obvious.. I am having unexpected problems with the callback session - that do not exist when using a similar udp session -
[2002/09/16 06:47:11] #net-snmp <wdebruij_> the parser receives a packet of length 1 byte using callbackdomain
[2002/09/16 06:47:23] #net-snmp <wdebruij_> is this normal? I guess it should still receive a complete packet
[2002/09/16 06:47:23] #net-snmp <wes> yep.
[2002/09/16 06:47:25] #net-snmp <wes> (it's a bogus byte)
[2002/09/16 06:47:35] #net-snmp <wdebruij_> oh, so that can't be wrong then
[2002/09/16 06:47:42] #net-snmp <wes> It passes stuff via pointer, but sends a byte to wake up the select statement.
[2002/09/16 06:47:49] #net-snmp <wdebruij_> ah, right
[2002/09/16 06:48:35] #net-snmp <wdebruij_> the problem comes from 'pdu init failed', which should be done using a function referencing callbackdomain's create_pdu.
[2002/09/16 06:49:16] #net-snmp <wes> where are you seeing the error?
[2002/09/16 06:50:01] #net-snmp <wdebruij_> just below the debug statement: [sess_process_packet: session 0x80c80b0 fd 4 pkt 0x814de50 length 1]
[2002/09/16 06:50:32] #net-snmp <wdebruij_> I checked it out and it happens the following line (I'm looking it up) in snmp_api.c
[2002/09/16 06:51:17] #net-snmp <wdebruij_> line 4828: [pdu = isp->hook_create_pdu(transport, opaque, olength);]
[2002/09/16 06:52:39] #net-snmp <wdebruij_> by the way, I'm talking about version 5.0.3, as far as I know this file hasn't been changed in the 5.04pre releases
[2002/09/16 06:52:47] #net-snmp <wes> no, it's probably the same.
[2002/09/16 06:52:58] #net-snmp <wes> can you show me the exact error message you're seeing?
[2002/09/16 06:53:40] #net-snmp <wdebruij_> here it is: pdu failed to be created (written at snmp_api.c line 4831)
[2002/09/16 06:54:32] #net-snmp <wdebruij_> all this happens right after calling snmp_callback_receive, which contains some commentary about having to allocate memory, but does not actually allocates memory
[2002/09/16 06:54:42] #net-snmp <wdebruij_> so I think it might have something to do with that
[2002/09/16 06:55:23] #net-snmp <wdebruij_> the commentary can be found at snmp_callback_receive line 189, to be precise
[2002/09/16 06:55:32] #net-snmp <wes> well, the only thing I can see is that the queue didn't receive the pointer properly.
[2002/09/16 06:56:01] #net-snmp <wes> what type of machine is this on, by the way?
[2002/09/16 06:56:28] #net-snmp <wdebruij_> it is a pc (athlon xp) running linux kernel 2.4.19
[2002/09/16 06:56:35] #net-snmp <wes> ok.
[2002/09/16 06:56:41] #net-snmp <wes> (just making sure itwasn't windows)
[2002/09/16 06:56:54] #net-snmp <wes> I'm not sure based on what I can tell.
[2002/09/16 06:57:04] #net-snmp <wes> My guess is that somewhere initialization isn't being done right.
[2002/09/16 06:57:42] #net-snmp <wes> I forget: is this for a module for our agent, or are you writing your own?
[2002/09/16 06:57:42] #net-snmp <wdebruij_> from the examples (mtuTriggerTable.c) nearly no initialization should be done
[2002/09/16 06:57:56] #net-snmp <wes> (using ours as a base)
[2002/09/16 06:58:06] #net-snmp <wdebruij_> it is for code running inside the snmpd
[2002/09/16 06:58:27] #net-snmp <wdebruij_> but - and that might be the problem - it runs in a separate thread from the rest of the code
[2002/09/16 06:58:44] #net-snmp <wes> You probably need to step into a debugger and see what's going wrong in the callback's create function.
[2002/09/16 06:58:53] #net-snmp <wes> (which will go into the pop_queue function)
[2002/09/16 06:58:59] #net-snmp <wes> OHHHHHHHHHHHHHHHHH
[2002/09/16 06:59:08] #net-snmp <wes> yeah.
[2002/09/16 06:59:26] #net-snmp <wes> as I think I said, it's not likely to work when threaded.
[2002/09/16 06:59:26] #net-snmp <wdebruij_> but the threads share the same memorh addressing space, right?
[2002/09/16 06:59:29] #net-snmp <jbpn> boom
[2002/09/16 07:00:54] #net-snmp <wdebruij_> doesn't the network listeners (udp_*) also run in threads separate from the parser, then?
[2002/09/16 07:02:14] #net-snmp <jbpn> no
[2002/09/16 07:02:30] #net-snmp <wes> everything in our applications are in a single thread.
[2002/09/16 07:02:31] #net-snmp <wdebruij_> oh
[2002/09/16 07:03:27] #net-snmp <wdebruij_> then I'll have to replace the single threaded snmp listener with my own listener
[2002/09/16 07:03:46] #net-snmp <wdebruij_> sorry for waisting your time
[2002/09/16 07:05:02] #net-snmp <wes> sorry for not having a multi-threaded agent for ya
[2002/09/16 07:05:21] #net-snmp <wes> (though you're welocem to fix it and send us a patch ;-)
[2002/09/16 07:06:23] #net-snmp <wdebruij_> I'll see what I can do..... but I'll probably try to mix my listener with the others first
[2002/09/16 07:06:33] #net-snmp <wdebruij_> it sounds like a lot of work!
[2002/09/16 07:06:37] #net-snmp <wdebruij_> :)
--> miike has joined #net-snmp
[2002/09/16 07:17:08] #net-snmp <wdebruij_> the interpreter I am adding to the packet is called snap, so I'll probably try to create a snmpSNAPDomain implementation. It seems that that is the preferred way of integrating listeners
[2002/09/16 07:17:49] #net-snmp <jbpn> what does this interpreter do?
[2002/09/16 07:18:42] #net-snmp <wdebruij_> snap is an abbreviation for `safe, active and nimble packets', a network interpreter that allows IP headers to include bytecode programs
[2002/09/16 07:19:08] #net-snmp <jbpn> oh yeah, active network, I remember you mentioned that
[2002/09/16 07:19:14] #net-snmp <wdebruij_> this way each packet can run a program on each node it visits
[2002/09/16 07:19:38] #net-snmp <jbpn> yeah -- an snmpSNAPDomain would be the way to go
[2002/09/16 07:19:49] #net-snmp <wdebruij_> for the developer I am testing whether active networks can be put to use in network management environments
[2002/09/16 07:20:37] #net-snmp <wdebruij_> for instance by calculating aggregates of variables on each machine it visits
[2002/09/16 07:22:37] #net-snmp <wdebruij_> originally I wanted to minimize the code alterations to the snmp deamon, to allow for accurate performance tests between the two. Therefore I chose a new thread that called the interpreter from inside a shared library
[2002/09/16 07:22:54] #net-snmp <wdebruij_> but now I know that that isn't the way to go. Thanks
[2002/09/16 07:26:29] #net-snmp <wes> You shouldn't need to modify the agent much at all, so I don't see it as a big problem... (FYI)
[2002/09/16 07:28:06] #net-snmp <wdebruij_> well, the snap interpreter is now made part of the snmp processing flow, while I preferred it to work more or less separately, since it should also handle non snmp requests
[2002/09/16 07:28:48] #net-snmp <wdebruij_> but inter process communication is not permitted
[2002/09/16 07:29:10] #net-snmp <wdebruij_> so it can't be started in a separate process completely
[2002/09/16 07:30:27] #net-snmp <jbpn> yeah but presumably you have to do the snap processing of the packet payload before doing the snmp processing of its contents?
[2002/09/16 07:31:01] #net-snmp <jbpn> so there is no advantage in putting it in another thread anyway -- you'd just wind up having some synchronisation primitives to tell you when to continue, no?
[2002/09/16 07:32:47] #net-snmp <wdebruij_> I won't put snmp contents in the packet, but will translate snap instructions into snmp requests. This worked when using the - relatively slow - udp lookback connection. For a snap get instruction I created a new pdu on the fly and passed this to the parser
[2002/09/16 07:33:13] #net-snmp <wdebruij_> this is unfortunately not possible using the callback session
[2002/09/16 07:33:35] #net-snmp <wdebruij_> since the multithreading now becomes apparent
[2002/09/16 07:34:15] #net-snmp <wdebruij_> otherwise it would be a perfect solution to my problem
[2002/09/16 07:34:33] #net-snmp <wdebruij_> giving me processing speed and interpreter independence
[2002/09/16 07:34:43] #net-snmp <jbpn> well, kind of
[2002/09/16 07:35:09] #net-snmp <wes> you might see if putting MT locking on the callback domain's queue...
[2002/09/16 07:35:30] #net-snmp <wes> (if it worked for udp, but I suspect you were just lucky and it won't always work)
[2002/09/16 07:36:45] #net-snmp <wdebruij_> I did add some locking in the callback, so that the flow of control worked ok, but this didn't solve anything. the system also locked for a few seconds (!)
[2002/09/16 07:36:55] #net-snmp <wdebruij_> so that was not a very fine solution
[2002/09/16 07:39:13] #net-snmp <wdebruij_> but doesn't there exist a simple function that retrieves a value when given an OID? I kind of expected this before I started looking through the code. It would be ideal, but the callback handling of MIB modules obscures the flow of control too much for me to understand it anymore
[2002/09/16 07:40:04] #net-snmp <wdebruij_> I don't actually need to produce and read complete PDU's
[2002/09/16 07:40:20] #net-snmp <wdebruij_> just OID->value for scalars to begin with
[2002/09/16 07:41:23] #net-snmp <wes> well, handle_pdu does almost what you want but it's wrapped heavily into the agent's calling structure.
[2002/09/16 07:41:31] #net-snmp <wes> It's not designed for you to just call it.
[2002/09/16 07:42:50] #net-snmp <wes> well, I don't feel like doing real work so I think I'll go boot into windows instead.
[2002/09/16 07:43:03] #net-snmp <wes> I'll be back in a while, assuming I'm not eaten alive.
[2002/09/16 07:43:18] #net-snmp <jbpn> ACTION winces
[2002/09/16 07:43:42] #net-snmp <wdebruij_> ok, thanks again. enjoy whatever you do in windows ;)
[2002/09/16 07:47:36] #net-snmp <wdebruij_> hmmm. it is time for me to start helping students with their databases course. yippeekayee. thanks for the tips and perhaps until soon
--> wes has joined #net-snmp
[2002/09/16 09:07:26] #net-snmp <wes> should have done real work.
--> jbpn has joined #net-snmp
[2002/09/16 09:14:13] #net-snmp <df> but you survived
--> TrogL has joined #net-snmp
[2002/09/16 09:21:47] #net-snmp <TrogL> if a server was low on swap, why wouldn't it report the 101 and 102 entries in hosts, hrstorageindex? theyw eren't there at all
[2002/09/16 09:22:53] #net-snmp <TrogL> I'll look the source to answer see if it's a specific "hosts" thing, but I'm wordring more from an overall perspective
[2002/09/16 09:23:00] #net-snmp <TrogL> would being low on swap prevent values being reported?
[2002/09/16 09:23:23] #net-snmp <jbpn> sounds like a bug
[2002/09/16 09:24:14] #net-snmp <TrogL> I'll look at it while I'm rewriting the hrstorage code
--> slam has joined #net-snmp
--> benr has joined #net-snmp
--> jbpn has joined #net-snmp
--> wes has joined #net-snmp
--> miike has joined #net-snmp
--> mali[x] has joined #net-snmp
[2002/09/16 13:42:57] #net-snmp <mali[x]> hi
[2002/09/16 13:43:04] #net-snmp <wes> howdy
[2002/09/16 13:43:28] #net-snmp <mali[x]> fine
[2002/09/16 13:43:52] #net-snmp <mali[x]> wes: just some problem but it ok
[2002/09/16 13:44:00] #net-snmp <wes> ?
[2002/09/16 13:44:08] #net-snmp <TrogL> that's informative
[2002/09/16 13:44:10] #net-snmp <mali[x]> wes: do you know AMS
[2002/09/16 13:44:21] #net-snmp <wes> what's it stand for?
[2002/09/16 13:45:25] #net-snmp <mali[x]> American Mathematical Society
[2002/09/16 13:45:30] #net-snmp <wes> nope
[2002/09/16 13:46:09] #net-snmp <mali[x]> we have teacher here (algeria) who was teacher in AMS
[2002/09/16 13:47:19] #net-snmp <mali[x]> wes: rstory his name is rock story ?
[2002/09/16 13:47:39] #net-snmp <wes> no
[2002/09/16 13:48:00] #net-snmp <mali[x]> what his name
[2002/09/16 13:49:15] #net-snmp <wes> rstory's? you culd probably ask him.
[2002/09/16 13:49:18] #net-snmp <wes> rstory: you awake?
[2002/09/16 13:49:46] #net-snmp <rstory> Hello, my name is Robert, and I'm a NET-SNMP-aholic.
[2002/09/16 13:50:00] #net-snmp <wes> heh.
[2002/09/16 13:50:10] #net-snmp <wes> Sorry Robert, didn't want to give your name away without permission.
[2002/09/16 13:50:12] #net-snmp <mali[x]> rstory: hi
[2002/09/16 13:50:22] #net-snmp <mali[x]> wes: no problem
[2002/09/16 13:50:29] #net-snmp <rstory> yes, i was watching with bemusement to see how you'd respond... ;-)
[2002/09/16 13:51:24] #net-snmp <mali[x]> good nite all
[2002/09/16 13:51:33] #net-snmp <mali[x]> thanks for net-snmp
[2002/09/16 13:52:27] #net-snmp <rstory> don't forget to send your postcard!
[2002/09/16 13:53:01] #net-snmp <mali[x]> i do it by mail ;)
--> miike has joined #net-snmp
--> wes has joined #net-snmp
--> miike has joined #net-snmp
--> benr has joined #net-snmp
--> df has joined #net-snmp
--> df has joined #net-snmp
--> benr has joined #net-snmp
--> wes has joined #net-snmp
--> HailHail has joined #net-snmp
[2002/09/16 20:59:34] #net-snmp <HailHail> what's up... anyone awake around here?
[2002/09/16 20:59:52] #net-snmp <rstory> yep
[2002/09/16 21:00:59] #net-snmp <HailHail> hey... if i fork a process in my pass-through script (i.e. & - run in bg), will net-snmp wait for that background process to complete as well before returning data?
[2002/09/16 21:02:17] #net-snmp <HailHail> i have a "sleep 7" in a script i run in the bg from my pass-through... snmpset times out (w/out explicitly setting it) if i don't remove that... but it seems like what i do in bg shouldn't matter
[2002/09/16 21:03:16] #net-snmp <wes> you need a longer timeout sent with snmpset. Run it with -t 10
[2002/09/16 21:03:48] #net-snmp <wes> However, I'm not sure what you're doing will work in the first place unless the stdout of the child is the same as the parent (which is likely unless you've done something to it)
[2002/09/16 21:04:16] #net-snmp <HailHail> it's a write
[2002/09/16 21:04:24] #net-snmp <HailHail> i don't really return any data
[2002/09/16 21:05:00] #net-snmp <wes> you return an error code, right?
[2002/09/16 21:05:12] #net-snmp <HailHail> yeah exit 0 in the parent process
[2002/09/16 21:05:31] #net-snmp <HailHail> but even after that as long as the bg process is going net-snmp doesn't reply to the snmpset
[2002/09/16 21:07:37] #net-snmp <HailHail> would seeing my script help?
[2002/09/16 21:08:23] #net-snmp <wes> Hmm...
[2002/09/16 21:08:46] #net-snmp <wes> It's likely you need to detach properly I guess. I'm not sure what has to be done...
[2002/09/16 21:08:52] #net-snmp <wes> I'd look at your script but I don't have time at the moment.
[2002/09/16 21:08:53] #net-snmp <wes> sorry.
[2002/09/16 21:08:58] #net-snmp <HailHail> np
[2002/09/16 21:12:19] #net-snmp <HailHail> anyone else have any ideas
[2002/09/16 21:13:05] #net-snmp <rstory> make the sleep longer, do the set, and "ps -ef | grep script-name" to see if the script is hanging around waiting on the bg process
[2002/09/16 21:20:53] #net-snmp <HailHail> hmm it's not but i do see a "defunct" bash process
[2002/09/16 21:21:27] #net-snmp <HailHail> and the set doesn't return until after the sleep & what follows
[2002/09/16 21:21:42] #net-snmp <rstory> yep, that would be it.... if you can get that to go away, then it will work like you expect
[2002/09/16 21:22:07] #net-snmp <HailHail> any idea on how? is there a command to detach a child process?
[2002/09/16 21:23:00] #net-snmp <rstory> well, I know our snmpd does 2 forks to escape the shell... you should try having your bg process fork again...
[2002/09/16 21:23:11] #net-snmp <rstory> but I'm not a bash expert, so I'm just guessing
[2002/09/16 21:23:33] #net-snmp <HailHail> cool, thanks for your help
--> jbpn has joined #net-snmp

Powered by: