On 17/03/2026 4:26 am, Tim Düsterhus wrote:
Hi
On 3/16/26 06:03, [email protected] 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
