Under URL part device/{device_id}/capture it is possible to run a discovery or polling on the fly and have the result be output to the browser.
Problem: When the corresponding PHP script includes/html/output/capture.inc.php sets a timeout for the symfony process, it uses snmp.exec_timeout (defaults to the reasonable 1200 seconds). Therefore essentially hundreds of SNMP commands need to run within this time. If you set 20 seconds instead, the run is basically doomed unless the device is really “fast” (or small). We have a slow Cisco switch which takes several minutes – not even 200s are enough.
My simple suggestion: Just use a dedicated timeout like capture.timeout, still defaulting to 1200 seconds.
Just run the debug on the cli if the default timeout is too short. You should not be using the debug very often…
There is a rediscover button in the UI if that is what people are trying to do.
CLI is only a solution if the user has access … I could do this in this case, but it is not really a general solution.
More important: I basically was “forced” to make a FR out of this, but in my opinion this is at least bad design. I believe that usually, exec_timeout is used for a single snmp command, but here it is “warped” for the whole plethora of snmp commands. At least I did not except this and my colleague was catched offguard as well. If you don’t want a specific timeout, then least exec_timeout should not work that way. It is unintuitive and might cost other users time as well.
You missed the point of my comment. It was that there should be no reason to use the UI based debug regularly or maybe at all.
If you think the timeout should be increased, submit a pull request.