No, it's not a bug of eZP, it's just a weird usage of the eZP db API done by the extension.
The idea is that the ezsnmpagent php script might be used as a daemon, ie. a process that runs forever, not just as a "start, echo requested value then die" process.
The net-snmp package can accommodate both ways of working: either invoke the ez script once and keep using the process as long as it is running, or invoke it on each snmp request, assuming it will die immediately.
The 2nd way of working is of course better for performances, but has some serious drawbacks: if the script is eg. started now, and it is requested the value of an ini file, it will keep that value in its own ram, not shared with any other process. If a day later the ini value has changed on disk, and the ini cache has been cleared, but the php process is still running, it has to be told explicitly to refresh its ini cache or it will never be able to 'see' the change.
The same applies for the db state - I do not want to keep one extra db connection open all of the time just for the snmp agent, plus when asked for db status, I have to make sure the test is done every time and an old result is not returned.
That's the reason of the weird usage of the db api, with the connection getting closed.
Since now the recommended way of using the extension together with the snmp agent is in non-persistent mode, I think I will change the code to not use a separate db connection by default...
↧