Re: snmpd improvements
On Wed, Dec 21, 2016 at 10:40:48AM +0100, Franco Fichtner wrote: > Hi, > > Switching from net-snmp to OpenBSD's snmpd raised two > issues and I'd like to know if they make sense to address: > > A pid file is missing. Would a patch for this be accepted? Most probably not. We don't see the benefits in having pid files and prefer to use tools like pgrep to verify if a process is running. > The snmpd.conf can contain static values. If these values > are rewritten/changed over time by rewriting the config, > snmpd needs to be restarted. Is there a technical reason > for not supporting e.g. reload using HUP? This would be accepted for sure but will require a fair amount of work because of the privsep nature of the daemon. You need to pass the conifg to the childs and apply it there. Doing this will probably be appreciated. -- :wq Claudio
Re: snmpd improvements
On 16-12-21 9:41 AM, Jan Klemkow wrote: On Wed, Dec 21, 2016 at 10:40:48AM +0100, Franco Fichtner wrote: The snmpd.conf can contain static values. If these values are rewritten/changed over time by rewriting the config, snmpd needs to be restarted. Is there a technical reason for not supporting e.g. reload using HUP? I'm only looking for input, can provide patches with a bit of help. :) The HUP feature isn't that import for the OpenSNMPd because it does not cost that much time to reload the information out of the kernel and the daemon don't keep stat from it's clients. In the case of the OpenOSPF its much more important because it take a while to restart. And during the starting time the router would not be available. As a frequent user of SNMP, and OpenBSD's snmpd in particular, I could see the HUP feature being immensely useful. Restarting the snmpd daemon resets the timeticks value to zero, which appears as a "reboot" to the outsider. However, in lieu of graceful restart to pick up static changes in snmpd.conf, I could see perhaps changing timeticks to reference the host system uptime counter instead as an alternative, then restarting it would be less of an issue on my end. However, I'm sure there are legitimate reasons for things to be the way they are now, such as portability since everyone's uptime will be somewhere different. Something that's been on my list of things to look at, should I ever find my coder hat ever again (it's been missing somewhere for quite some time now). -- http://blog.sarlok.com/ Sometimes all the left hand needs to know is where the right hand is, so it knows where to point the blame.
Re: snmpd improvements
On Wed, Dec 21, 2016 at 10:40:48AM +0100, Franco Fichtner wrote: > Hi, > > Switching from net-snmp to OpenBSD's snmpd raised two > issues and I'd like to know if they make sense to address: > > A pid file is missing. Would a patch for this be accepted? As far as I know, the OpenBSD project avoids pid files for a longer time. Because of race conditions and other reasons. > The snmpd.conf can contain static values. If these values > are rewritten/changed over time by rewriting the config, > snmpd needs to be restarted. Is there a technical reason > for not supporting e.g. reload using HUP? > > I'm only looking for input, can provide patches with a bit > of help. :) The HUP feature isn't that import for the OpenSNMPd because it does not cost that much time to reload the information out of the kernel and the daemon don't keep stat from it's clients. In the case of the OpenOSPF its much more important because it take a while to restart. And during the starting time the router would not be available. Just my two cents. bye, Jan
snmpd improvements
Hi, Switching from net-snmp to OpenBSD's snmpd raised two issues and I'd like to know if they make sense to address: A pid file is missing. Would a patch for this be accepted? The snmpd.conf can contain static values. If these values are rewritten/changed over time by rewriting the config, snmpd needs to be restarted. Is there a technical reason for not supporting e.g. reload using HUP? I'm only looking for input, can provide patches with a bit of help. :) Cheers, Franco
