Re: [RFC] SNMP MIB reset function

On 17/03/2026 4:26 am, Tim Düsterhus wrote:

Hi On 3/16/26 06:03, swilton@fluentit.au wrote:

I believe that the process is to send a message to the list, and gauge whether there is positive feedback before creating the RFC for voting.  Please let me know if I should create the RFC first? The PR is here: https://github.com/php/php-src/pull/21452/changes

I suspect that SNMP is such a specialized and rarely used extension that folks will be unable to meaningfully discuss an RFC for this feature - at least not without you doing quite a bit of explaining. This might be case where it's best to just find an informal agreement with you providing a well-tested and well-explained patch rather than doing a full RFC.

I'm very happy to avoid the RFC process, and happy to explain/discuss the changes :)

---------- That said, I did some research, finding this man page: https://linux.die.net/man/3/shutdown_mib. I'm seeing that the manpage states for init_mib():

It should be called before any other routine that manipulates or accesses the MIB tree.

I'm seing that init_mib() is not currently called at all in ext/snmp. Is the initialization implicitly happening as part of init_snmp()? For shutdown_mib() I'm seeing:

It is strongly recommended that one does not invoke shutdown_mib while there are SNMP sessions being actively managed.

Will calling your proposed snmp_init_mib() function cause issues when an existing SNMP object is being used after the call to snmp_init_mib()? I have interpreted the "actively managed" sessions as ones with requests in process (i.e. requests have been sent and we are using some form of select() to wait for the reply).  The other possibility is that calling mib_shutdown() would cause issues if a request is sent before iinit_mib() is called.

I have written a test program that keeps a session across a mib_shutdown()/mib_init() with a query running on both sides, and it worked as expected with no memory access issues.

---------- In your email you mention:

Another consideration is that the MIB tree persists across FPM requests because the MIB tree is kept as a global structure within SNMP library memory.

Would calling shutdown_mib() in RSHUTDOWN (i.e. the end-of-request handler) solve the problem of the MIB persisting across requests or is it sometimes desirable that the MIB is persisted? This is precisely why I mentioned the persistence of the MIB tree.  There is no reason to keep the tree between requests, so doing a shutdown_mib() followed by an init_mib() between requests would be a good idea, with the following caveats:

* init_mib() depends on some environment variables.  I assume the environment is reset between requests, and if so init_mib() would need to be called between requests * init_mib() does read a bunch of files to parse the MIB tree, so it would be inefficient to call it between requests if no changes have been made to the MIB tree * I have just had a PR accepted in net-snmp to address a memory leak in the library when init_mib() is called multiple times, so it would cause a memory leak between requests until systems have been updated with this new patch

Best regards Tim Düsterhus