kill SIGHUP causes duplicate trapsinks

Logged In: YES
user_id=133274

A little more follow-up:

This appears to be caused by informsink instead of trapsink.
The following lines appear in my snmpd.conf:

authtrapenable 1
informsink 10.1.1.14

Putting some trace information into the code I see the
function: notifyTable_register_notifications() being called
each time a kill -HUP signal is sent.

This is causing duplicate notification entries to be added
to the notification tables.

Logged In: NO

ted_rule@flextech.co.uk:
The problem doesn't seem to be simply with informsink. With
an snmpd.conf'iguration with 2 trapsinks and no informsinks,
I get 2 additional ephemeral sockets opened on every SIGHUP.

This implies that the SIGHUP code is failing to close all
previously opened ephemeral trapsink sockets before opening
new ones corresponding to the new configuration?

Sample netstat listings before and after SIGHUP below.

This with ucd-4.2.2 on Linux RH6.2

[root@fttvgpstest1 /root]# grep trap /etc/snmp/snmpd.conf
authtrapenable 1
trapcommunity public
trapsink 192.168.66.1 public
trapsink 172.17.12.6 public
[root@fttvgpstest1 /root]#

[root@fttvgpstest1 /root]# netstat -an --udp -p | grep snmp
(Not all processes could be identified, non-owned process
info
will not be shown, you would have to be root to see it
all.)
udp 0 0 192.168.50.17:161
0.0.0.0:*
15555/snmpd
udp 0 0 127.0.0.1:161
0.0.0.0:*
15555/snmpd
udp 0 0 0.0.0.0:2787
0.0.0.0:*
15555/snmpd
udp 0 0 0.0.0.0:2786
0.0.0.0:*
15555/snmpd
udp 0 0 127.0.0.1:25375
0.0.0.0:*
15555/snmpd
[root@fttvgpstest1 /root]# /etc/rc.d/init.d/snmpd reconfig
SIGHUPping snmpd:
[ OK ]
[root@fttvgpstest1 /root]# netstat -an --udp -p | grep snmp
(Not all processes could be identified, non-owned process
info
will not be shown, you would have to be root to see it
all.)
udp 0 0 0.0.0.0:2801
0.0.0.0:*
15555/snmpd
udp 0 0 0.0.0.0:2800
0.0.0.0:*
15555/snmpd
udp 0 0 192.168.50.17:161
0.0.0.0:*
15555/snmpd
udp 0 0 127.0.0.1:161
0.0.0.0:*
15555/snmpd
udp 0 0 0.0.0.0:2787
0.0.0.0:*
15555/snmpd
udp 0 0 0.0.0.0:2786
0.0.0.0:*
15555/snmpd
udp 0 0 127.0.0.1:25375
0.0.0.0:*
15555/snmpd
[root@fttvgpstest1 /root]# [root@fttvgpstest1 /root]
# /etc/rc.d/init.d/snmpd reconfig
SIGHUPping snmpd:
[ OK ]
[root@fttvgpstest1 /root]# netstat -an --udp -p | grep snmp
(Not all processes could be identified, non-owned process
info
will not be shown, you would have to be root to see it
all.)
udp 0 0 0.0.0.0:2803
0.0.0.0:*
15555/snmpd
udp 0 0 0.0.0.0:2802
0.0.0.0:*
15555/snmpd
udp 0 0 0.0.0.0:2801
0.0.0.0:*
15555/snmpd
udp 0 0 0.0.0.0:2800
0.0.0.0:*
15555/snmpd
udp 0 0 192.168.50.17:161
0.0.0.0:*
15555/snmpd
udp 0 0 127.0.0.1:161
0.0.0.0:*
15555/snmpd
udp 0 0 0.0.0.0:2787
0.0.0.0:*
15555/snmpd
udp 0 0 0.0.0.0:2786
0.0.0.0:*
15555/snmpd
udp 0 0 127.0.0.1:25375
0.0.0.0:*
15555/snmpd
[root@fttvgpstest1 /root]#

Logged In: YES
user_id=93926

I believe Wes has committed a fix for this to the
V4-2-patches branch. You could check it out and try it
(which would be much appreciated) or wait for 4.2.3 which
should be out in a couple of days.

John

Logged In: NO

I've just run up a copy of ucd-snmp-4.2.3 from the src.rpm,
and the problem still exists with multiple phantom
UDP sockets left open for every SIGHUP - one for each
trapsink line in snmpd.conf.

It would seem, therefore, that Wes' fix doesn't completely
solve the problem.

Maybe snmpd's internal structures are correctly updated to
remove references to the old trapsinks, but the socket
itself becomes 'orphaned' but open in the process of doing
this?

Logged In: YES
user_id=76242

yeah, I didn't run snmp_close on the resulting sessions
hence the duplicate sockets.

I'll have to fix that.

Logged In: YES
user_id=133274

Can anyone give me a patch to this? These dangling sockets
are causing me all sorts of problems.

Logged In: NO

This problem is similar to 530334.

You can find a solution by looking the 530334 bug report.

Logged In: YES
user_id=8475

Bug #530334 has more detail, so this report has been closed.
Please direct any followups to
http://sf.net/tracker/?func=detail&aid=530334&group_id=12694&atid=112694