I am writing a plugin module for SNMP that will enable a particular hardware/software subsystem to be monitored and controlled via SNMP.

Now, SNMP is single-threaded, which is causing me a bit of heartburn. My plugin module has to communicate with another process (named SCAN) which is monitoring and controlling a piece of hardware in real time.

For testing purposes at the present time, I have set up a named pipe using mkfifo and I am communicating between the two with this. This is working fine. But...

Obviously, I have to design for error conditions, and one error condition is that the SCAN process goes down for some reason. Since fifos will block if both ends aren't being controlled, this could easily result in a deadlock of snmp, which I simply cannot have.

Now, in tests, it appears that the snmp daemon will retry the plugin module after some period of time if the module doesn't reply with the requested information. I don't know how many retries snmp does before it gives up and I have not yet pinned down the timing of the retries, but it does seem to never continue unless it gets a response from the plugin module.

So, I need a means to unblock the fifo in the plugin module should it become blocked, or I need to use some other IPC mechanism.

I have considered having my plugin module set a global flag (IAMCHECKINGFORDATA), then spawning a new thread, then checking the FIFO, then clearing the global flag. The new thread that is spawned sleeps for some fraction of a second, then checks the global flag. If the global flag is still set, then this thread says that the SCAN process is not responding, so this thread connects with the fifo and cleans it out, then this thread terminates. If the flag is already clear, then this thread says that the info has been collected and terminates.

Maybe this would be easier to manage if I used a local socket. Any opinions or comments?

I haven't written an SNMP module, someone else did it for me

It is an option to have functions called thru SNMP. But as you figured out, if this function hangs, SNMP might block.

My programmer solved this by creating a database (first in MySQL) and the tables is filled with values by one or more background processes. The snmpd ONLY reads the database, no hanging deamon can prevent that.

Later, the performance of MySQL proved to be too low (on a VIA C7 platform) so he designed his own database engine which allows much faster access. But the principle remained the same.

An added feature of using this two-layer approach is that you can add a field to each record which allow you to block any write access. That means that in a real-time process you can control any measurement or command values going to and from the hardware. All processes continue to run, no additional debug flags and you can test your software without the hardware connected. (The latter was my idea though and not implemented in the SNMP agent but in my own project)

I also added a field last_update_ts where each writing process has to update the time stamp. No time stamp update means the updating process crashed.

jlinkels

I hunted a bit for someone to do this for me and didn't find anyone.

Oh well. I've learned a lot.

SCAN has two types of data for SNMP; one set of data will only be provided when SNMP asks for it, and the other set will be provided a couple dozen times a second using a trap message. The data to be provided upon request is what I am working on right now, and writing it to a database, or a flat file, is a worthy idea. Putting a timestamp on it and updating at sufficient intervals would address pretty much all the problems; SNMP couldn't lock up and if the SCAN module should crash the impact would be contained.

Yes, I think I like that. Thanks for the idea.