Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130379
Content-Type: multipart/alternative;
 boundary="------------yGSIK1CwwdKdEx0hka75PUAm"
Message-ID: <d9858b1f-db86-4281-ad11-84246ca599ff@fluentit.au>
Date: Tue, 17 Mar 2026 08:14:13 +0800
Precedence: list
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC] SNMP MIB reset function
To: internals@lists.php.net
References: <5a2-69b78f00-11-50bc7700@253019388>
 <1c9534ff-d8c6-4939-a6f2-85a4c547ac0b@bastelstu.be>
Content-Language: en-US
In-Reply-To: <1c9534ff-d8c6-4939-a6f2-85a4c547ac0b@bastelstu.be>
From: swilton@fluentit.au (Steven Wilton)

This is a multi-part message in MIME format.
--------------yGSIK1CwwdKdEx0hka75PUAm
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


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 
--------------yGSIK1CwwdKdEx0hka75PUAm
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 17/03/2026 4:26 am, Tim Düsterhus
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:1c9534ff-d8c6-4939-a6f2-85a4c547ac0b@bastelstu.be">Hi
      <br>
      <br>
      On 3/16/26 06:03, <a class="moz-txt-link-abbreviated" href="mailto:swilton@fluentit.au">swilton@fluentit.au</a> wrote:
      <br>
      <blockquote type="cite">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?
        <br>
        The PR is here:
        <a class="moz-txt-link-freetext" href="https://github.com/php/php-src/pull/21452/changes">https://github.com/php/php-src/pull/21452/changes</a>
        <br>
      </blockquote>
      <br>
      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. <br>
    </blockquote>
    <p>I'm very happy to avoid the RFC process, and happy to
      explain/discuss the changes :)</p>
    <blockquote type="cite"
      cite="mid:1c9534ff-d8c6-4939-a6f2-85a4c547ac0b@bastelstu.be"><br>
      ----------
      <br>
      <br>
      That said, I did some research, finding this man page:
      <a class="moz-txt-link-freetext" href="https://linux.die.net/man/3/shutdown_mib">https://linux.die.net/man/3/shutdown_mib</a>.
      <br>
      <br>
      I'm seeing that the manpage states for init_mib():
      <br>
      <blockquote type="cite">It should be called before any other
        routine that manipulates or accesses the MIB tree. </blockquote>
      <br>
      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()?
      <br>
      <br>
      For shutdown_mib() I'm seeing:
      <br>
      <br>
      <blockquote type="cite">It is strongly recommended that one does
        not invoke shutdown_mib while there are SNMP sessions being
        actively managed.
        <br>
      </blockquote>
      <br>
      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()`? <br>
      <br>
    </blockquote>
    <p>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.  </p>
    <p>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.  </p>
    <blockquote type="cite"
      cite="mid:1c9534ff-d8c6-4939-a6f2-85a4c547ac0b@bastelstu.be">----------
      <br>
      <br>
      In your email you mention:
      <br>
      <br>
      <blockquote type="cite">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.
        <br>
      </blockquote>
      <br>
      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? <br>
      <br>
    </blockquote>
    <p>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:</p>
    <ul>
      <li>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</li>
      <li>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</li>
      <li>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</li>
    </ul>
    <blockquote type="cite"
      cite="mid:1c9534ff-d8c6-4939-a6f2-85a4c547ac0b@bastelstu.be">Best
      regards
      <br>
      Tim Düsterhus </blockquote>
  </body>
</html>

--------------yGSIK1CwwdKdEx0hka75PUAm--