Contributed by jl on from the if-it-is-broke-do-try-to-fix-it dept.
I wish I had mad coding skillz, but I have found that even non-developers have something to contribute in the form of equipment and time. When a call for testing goes out, my desire to tinker pushes me to install a snapshot and play with some of the new software that I'd like to use in the next release. Testing software not only helps me become more familiar with the new features, but can also help flush out bugs or documentation errors. I was excited when I saw that Reyk Floeter (reyk@) had commited a new snmp daemon to the tree, and I knew it was something that I would like to use as soon as possible. Like a mad scientist, I dragged out one of my frankenstein machines and proceeded to experiment on snmpd.
The first test was to query the daemon with the traditional net-snmp tools such as snmpwalk and snmpset. Everything was clearly explained in the man pages and the default /etc/snmpd.conf (5)worked as expected. It is important to change the write community before you set snmpd to listen to the network, and you may even want to use pf(4) to limit your exposure to random hosts. I don't do anything particularly complicated with snmp, and the commercial PRTG software that I use was happy to connect and read interface statistics from the test machine. Now it was time for some unusual tests.
To simulate running over a long period it time, I set up a simple loop with snmpwalk.
while true; do snmwalk -c public 10.1.100.97 system ; doneAfter a while, it became apparent that there was a memory leak. Running the top(1) command showed that the snmp daemon was using over 200MB of RAM and growing. It was time to fetch the latest source from CVS and see if the problem still existed in the latest version. Unfortunately, the leak was still there. From what I have read, this is an easy mistake to make and a difficult one to find. I have a hard enough time writing a "hello world" program in C, so I was in no position to track down an obscure bug in unfamiliar code. It was time to file a bug report with as much information that I had. I was pleasantly surprised when I heard back from the developer in less than a day. He was able to confirm the leak on his system, and suggested some further test that I could run to help narrow down the problem until he had more time to take a serious look at it. Following Reyk's suggestions, I ran loops of snmpwalk, snmpbulkwalk, snmpget, and snmpset against different types of objects in the MIB, such as Integer, String, and Timeticks. Apparently there are different handlers for different types of objects, and if we were lucky, the leak could be narrowed down to a small part of the code if the problem only happened when querying one type of object. Alas, it was not the case, but I hoped that my testing would at least save some valuable time.
By the next day, a fix had been committed, and I received a nice note of thanks from Reyk. This has been my typical experience when interacting with developers, and I'm always amazed at how accessible and responsive they are when I contact them with a useful bug report and a willingness to help resolve the problem. I'm not a programmer, but it is still exciting to participate in the process. I encourage everyone to contribute what they can, whether it be money, time, equipment, or documentation. So when a call for testing goes out, please do. It benefits the developers, the community, and eventually you.
(Comments are closed)