Discussion:
snmptrapd traphandle problem please help
s***@weil.com
2004-10-26 14:24:02 UTC
Permalink
Hello,

I am having a problem I just can not figure out with snmptrapd. I simply
wrote traphandler script to echo Hello World out to the screen when a
certain trap is detected. To set this up I configured
/usr/local/share/snmp/snmptrapd.conf with the following lines

/usr/local/share/snmp/snmptrapd.conf

###########################################################################
#
# snmptrapd.conf
#
# - created by the snmpconf configuration program
#
###########################################################################
# SECTION: Trap Handlers
#
# Here we define what programs are run when a trap is
# received by the trap receiver.
# traphandle: When traps are received, a program can be run.
# When traps are received, the list of configured trap
# handles is consulted and any configured program is run.
# If no handler is found, any handler with "default" as the
# traphandle type is run instead. The information contained
# in trap is passed to the program via standard input (see
# the snmptrapd.conf manual page for details).
#
# arguments: oid|"default" program args

traphandle .1.3.6.1.4.1.89.35.1.0.3 /root/traphandle

The problem is when I run snmptrapd and the trap with stated OID is
generated snmptrapd just exits and I do not get any output from my
traphandler even though snmptrapd 1) receives the trap and 2) finds and
knows about the traphandler. I get the same result if I replace the
specific OID with the default directive.
Here is the command Im using:

/usr/local/sbin/snmptrapd -Lo -Dall -On -C -c
/usr/local/share/snmp/snmptrapd.conf

And here is most of the output of this command..

....
parse-mibs: Parsing MIB: 6 SNMPv2-TM
trace: read_module_internal(): parse.c, 3728:
parse-mibs: Module SNMPv2-SMI already loaded
trace: parse_imports(): parse.c, 3549:
parse-mibs: #### adding Module 6 'snmpModules' 4
trace: parse_imports(): parse.c, 3549:
parse-mibs: #### adding Module 6 'snmpDomains' 4
trace: parse_imports(): parse.c, 3549:
parse-mibs: #### adding Module 6 'snmpProxys' 4
trace: do_linkup(): parse.c, 1662:
parse-mibs: Processing IMPORTS for module 6 SNMPv2-TM
trace: do_linkup(): parse.c, 1675:
parse-mibs: Processing import: snmpModules
trace: do_linkup(): parse.c, 1675:
parse-mibs: Processing import: snmpDomains
trace: do_linkup(): parse.c, 1675:
parse-mibs: Processing import: snmpProxys
trace: parse(): parse.c, 4346:
parse-file: End of file (/usr/local/share/snmp/mibs/SNMPv2-TM.txt)
trace: init_mib(): mib.c, 2638:
init_mib: Seen PREFIX: Looking in '.1.3.6.1.2.1' for prefix ...
trace: read_configs(): read_config.c, 771:
read_config: reading normal configuration tokens
trace: read_configs(): read_config.c, 795:
read_config: Reading optional config file:
"/usr/local/share/snmp/snmptrapd.conf"
trace: read_config(): read_config.c, 678:
read_config: Reading configuration /usr/local/share/snmp/snmptrapd.conf
trace: read_config(): read_config.c, 738:
read_config: /usr/local/share/snmp/snmptrapd.conf:26 examining: traphandle
.1.3.6.1.4.1.89.35.1.0.3 /root/traphandle
trace: run_config_handler(): read_config.c, 441:
read_config: Found a parser. Calling it: traphandle /
.1.3.6.1.4.1.89.35.1.0.3 /root/traphandle
trace: snmptrapd_parse_traphandle(): snmptrapd_handlers.c, 82:
read_config:traphandle: registering handler for: .1.3.6.1.4.1.89.35.1.0.3
trace: netsnmp_ds_set_boolean(): default_store.c, 191:
netsnmp_ds_set_boolean: Setting LIB:27 = 1/True
trace: snmp_call_callbacks(): callback.c, 176:
callback: START calling callbacks for maj=0 min=0
trace: snmp_call_callbacks(): callback.c, 184:
callback: calling a callback for maj=0 min=0
trace: snmp_call_callbacks(): callback.c, 184:
callback: calling a callback for maj=0 min=0
trace: sc_hash(): scapi.c, 386:
trace: sc_get_properlength(): scapi.c, 115:
trace: sc_hash(): scapi.c, 386:
trace: sc_get_properlength(): scapi.c, 115:
trace: set_enginetime(): lcd_time.c, 354:
lcd_set_enginetime: engineID 80 00 07 E5 80 50 53 E2 36 4B 77 7E 41 :
boots=1, time=0
trace: snmp_call_callbacks(): callback.c, 184:
callback: calling a callback for maj=0 min=0
trace: set_an_alarm(): snmp_alarm.c, 363:
snmp_alarm: no alarms found to schedule
trace: snmp_call_callbacks(): callback.c, 196:
callback: END calling callbacks for maj=0 min=0 (3 called)

I was using net-snmp 5.1.1 but then prayed and hoped that if I compiled and
installed 5.1.2 the problem would go away, so now I am using net-snmp 5.1.2
and still having this problem. The machine is running SuSE 8.1 linux kernel
2.4.19 with a gcc version of 3.2.

I also tried compiling a C program that outputs Hello World to stdout and
used that instead of a script with the same result.

Any help is appreciated, I am out of ideas here....


Thanks
Steph


< END >


-----------------------------------------
The information contained in this email message is intended only for use of
the individual or entity named above. If the reader of this message is not
the intended recipient, or the employee or agent responsible to deliver it
to the intended recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited. If
you have received this communication in error, please immediately notify us
by email (***@weil.com), and destroy the original message. Thank you
s***@weil.com
2004-10-26 15:41:03 UTC
Permalink
Alex,

I have also tried that but snmptrapd still exits here is the output from
the -f switch....

The command I used:

/usr/local/sbin/snmptrapd -Lo -f -Dall -On -C -c
/usr/local/share/snmp/snmptrapd.conf

The output:

dumpx_recv: 02 01 03
dumpv_recv: Integer: 3 (0x03)
dumpx_recv: 43 04 05 BB 9D 4D
dumpv_recv: UInteger: 96181581 (0x5BB9D4D)
trace: snmp_pdu_parse(): snmp_api.c, 4219:
dumph_recv: VarBindList
trace: snmp_pdu_parse(): snmp_api.c, 4249:
dumph_recv: VarBind
trace: snmp_parse_var_op(): snmp.c, 166:
dumph_recv: Name
dumpx_recv: 06 0A 2B 06 01 04 01 59 02 03 01 00
dumpv_recv: ObjID: .1.3.6.1.4.1.89.2.3.1.0
trace: snmp_pdu_parse(): snmp_api.c, 4258:
dumph_recv: Value
dumpx_recv: 04 40 49 6C 6C 65 67 61 6C 20 4C 6F 61 64 20 52
65 70 6F 72 74 20 72 65 63 65 69 76 65 64 20 66
72 6F 6D 20 75 6E 6B 6E 6F 77 6E 20 73 65 72 76
65 72 20 32 31 33 2E 20 36 32 2E 31 39 34 2E 20
38 30
dumpv_recv: String: Illegal Load Report received from unknown
server 213. 62.194. 80
trace: snmp_pdu_parse(): snmp_api.c, 4249:
dumph_recv: VarBind
trace: snmp_parse_var_op(): snmp.c, 166:
dumph_recv: Name
dumpx_recv: 06 0A 2B 06 01 04 01 59 02 03 02 00
dumpv_recv: ObjID: .1.3.6.1.4.1.89.2.3.2.0
trace: snmp_pdu_parse(): snmp_api.c, 4258:
dumph_recv: Value
dumpx_recv: 02 01 02
dumpv_recv: Integer: 2 (0x02)
trace: snmp_input(): snmptrapd_handlers.c, 910:
snmptrapd: input: a4
trace: snmp_input(): snmptrapd_handlers.c, 968:
snmptrapd: Trap OID: .1.3.6.1.4.1.89.35.1.0.3
trace: print_handler(): snmptrapd_handlers.c, 548:
snmptrapd: print_handler
trace: print_handler(): snmptrapd_handlers.c, 591:
snmptrapd: v1 format
trace: sprint_realloc_by_type(): mib.c, 1971:
output: sprint_by_type, type 4
trace: sprint_realloc_by_type(): mib.c, 1971:
output: sprint_by_type, type 2
2004-10-26 13:34:33 172.24.3.50(via 172.24.3.50) TRAP, SNMP v1, community
public
.1.3.6.1.4.1.89.35.1 Enterprise Specific Trap (3) Uptime: 11 days,
3:10:15.81
.1.3.6.1.4.1.89.2.3.1.0 = STRING: "Illegal Load Report received
from unknown server 213. 62.194. 80" .1.3.6.1.4.1.89.2.3.2.0 = INTEGER:
2
trace: netsnmp_get_traphandler(): snmptrapd_handlers.c, 430:
snmptrapd: get_traphandler matched (807ccd8)
trace: command_handler(): snmptrapd_handlers.c, 774:
snmptrapd: command_handler
trace: command_handler(): snmptrapd_handlers.c, 775:
snmptrapd: token = '/root/traphandle'
trace: netsnmp_ds_set_boolean(): default_store.c, 191:
netsnmp_ds_set_boolean: Setting LIB:13 = 1/True
trace: command_handler(): snmptrapd_handlers.c, 803:
snmptrapd: execute format
trace: sprint_realloc_by_type(): mib.c, 1971:
output: sprint_by_type, type 4
trace: sprint_realloc_by_type(): mib.c, 1971:
output: sprint_by_type, type 2

If I dont specify any traphandler scripts or programs the snmptrapd doesnt
exit it keeps receiving traps but when I specify a traphandler the
snmptrapd will exit as soon as it encounters the trap of which I have a
traphandler specified. I hope this makes more sense. the main problem is I
could never run snmptrapd in the background in this state becaus e once it
receives a trapit bails. The strange part here is I see no errors in the
output. The last line before I get my root prompt back is output:
sprint_by_type, type 2.

-Steph


|---------+------------------------------>
| | Alex Burger |
| | <***@users.sourc|
| | eforge.net> |
| | |
| | 10/26/2004 01:29 PM|
| | |
|---------+------------------------------>
------------------------------------------------------------------------------------------------------------------------|
| |
| To: Stephanos Kotsakis/NY/WGM/***@WGM |
| cc: net-snmp-***@lists.sourceforge.net |
| Subject: Re: snmptrapd traphandle problem please help |
------------------------------------------------------------------------------------------------------------------------|
Hello,
I am having a problem I just can not figure out with snmptrapd. I simply
wrote traphandler script to echo Hello World out to the screen when a
certain trap is detected. To set this up I configured
/usr/local/share/snmp/snmptrapd.conf with the following lines
<snip>
traphandle .1.3.6.1.4.1.89.35.1.0.3 /root/traphandle
The problem is when I run snmptrapd and the trap with stated OID is
generated snmptrapd just exits and I do not get any output from my
traphandler even though snmptrapd 1) receives the trap and 2) finds and
knows about the traphandler. I get the same result if I replace the
specific OID with the default directive.
/usr/local/sbin/snmptrapd -Lo -Dall -On -C -c
/usr/local/share/snmp/snmptrapd.conf
You didn't specify -f, so snmptrapd will fork to the background so you
will never see any output to STDOUT. Try this:

snmptrapd -f -Lo -On -C -c /usr/local/share/snmp/snmptrapd.conf

Alex





< END >


-----------------------------------------
The information contained in this email message is intended only for use of
the individual or entity named above. If the reader of this message is not
the intended recipient, or the employee or agent responsible to deliver it
to the intended recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited. If
you have received this communication in error, please immediately notify us
by email (***@weil.com), and destroy the original message. Thank you
Thomas Anders
2004-10-26 18:58:04 UTC
Permalink
Post by s***@weil.com
I was using net-snmp 5.1.1 but then prayed and hoped that if I compiled and
installed 5.1.2 the problem would go away, so now I am using net-snmp 5.1.2
and still having this problem.
Do you have the chance to check if you also see this problem with
5.2.rc1?

Also, a few other ideas:
- Does
env SNMPCONFPATH=/usr/local/share/snmp \
/usr/local/sbin/snmptrapd -Lo -f -Dall -On
work any better for you?
- Have you double-checked (with ps or pgrep) that snmptrapd
has really exited?
- You may want to run snmptrapd under a debugger to see where/why
it exits


+Thomas
--
Thomas Anders <thomas.anders at blue-cable.de>
s***@weil.com
2004-10-26 19:18:03 UTC
Permalink
HI Thomas,

I have some more information on the problem as I have been working on this
all day today. To anwser some of your questions first:

1) No this displays the same result

2) I have checked with ps and the process is missing after I receive a
trap it dies

3) I have performed an strace and it seems as though it is getting a
SIGPIPE (Broken Pipe) signal

Here is some of the output of the following command:

strace /usr/local/sbin/snmptrapd -n -Lo -f -On -C -c
/usr/local/share/snmp/snmptrapd.conf

close(7) = 0
munmap(0x40179000, 4096) = 0
stat64("/usr/local/share/snmp/snmptrapd.conf", {st_mode=S_IFREG|0644,
st_size=865, ...}) = 0
open("/usr/local/share/snmp/snmptrapd.conf", O_RDONLY) = 7
fstat64(7, {st_mode=S_IFREG|0644, st_size=865, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40179000
read(7, "################################"..., 4096) = 865
read(7, "", 4096) = 0
close(7) = 0
munmap(0x40179000, 4096) = 0
gettimeofday({1098825239, 92336}, NULL) = 0
time(NULL) = 1098825239
gettimeofday({1098825239, 92732}, NULL) = 0
time([1098825239]) = 1098825239
open("/etc/localtime", O_RDONLY) = 7
fstat64(7, {st_mode=S_IFREG|0644, st_size=1267, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40179000
read(7, "TZif\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\4\0\0\0\4\0"..., 4096)
= 1267
brk(0x8081000) = 0x8081000
close(7) = 0
munmap(0x40179000, 4096) = 0
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40179000
write(1, "2004-10-26 17:13:59 NET-SNMP ver"..., 522004-10-26 17:13:59
NET-SNMP version 5.1.2 Started.
) = 52
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 7
setsockopt(7, SOL_SOCKET, SO_BSDCOMPAT, [1], 4) = 0
setsockopt(7, SOL_SOCKET, SO_SNDBUF, [131072], 4) = 0
setsockopt(7, SOL_SOCKET, SO_RCVBUF, [131072], 4) = 0
bind(7, {sin_family=AF_INET, sin_port=htons(162),
sin_addr=inet_addr("0.0.0.0")}}, 16) = 0
rt_sigaction(SIGTERM, {0x804a0e0, [TERM], SA_RESTART|0x4000000}, {SIG_DFL},
8) = 0
rt_sigaction(SIGHUP, {0x804a0f0, [HUP], SA_RESTART|0x4000000}, {SIG_DFL},
8) = 0
rt_sigaction(SIGINT, {0x804a0e0, [INT], SA_RESTART|0x4000000}, {SIG_DFL},
8) = 0
gettimeofday({1098825239, 97728}, NULL) = 0
gettimeofday({1098825239, 97967}, NULL) = 0
select(8, [3 5 7], NULL, NULL, {5, 0}) = 1 (in [7], left {2, 380000})
gettimeofday({1098825241, 718218}, NULL) = 0
brk(0x8092000) = 0x8092000
recvfrom(7, "0\201\214\2\1\0\4\6public\244\177\6\10+\6\1\4\1Y#\1@\4"...,
65536, 0, {sin_family=AF_INET, sin_port=htons(161),
sin_addr=inet_addr("172.24.3.50")}}, [16]) = 143
time([1098825241]) = 1098825241
write(1, "2004-10-26 17:14:01 172.24.3.50("..., 2992004-10-26 17:14:01
172.24.3.50(via 172.24.3.50) TRAP, SNMP v1, community public
.1.3.6.1.4.1.89.35.1 Enterprise Specific Trap (3) Uptime: 11 days,
6:49:43.57
.1.3.6.1.4.1.89.2.3.1.0 = STRING: "Illegal Load Report received
from unknown server 213. 62.194. 80" .1.3.6.1.4.1.89.2.3.2.0 = INTEGER:
2
) = 299
pipe([8, 9]) = 0
pipe([10, 11]) = 0
fork() = 1469
--- SIGCHLD (Child exited) ---
close(8) = 0
close(11) = 0
write(9, "172.24.3.50\n172.24.3.50\n.1.3.6.1"..., 287) = -1 EPIPE (Broken
pipe)
--- SIGPIPE (Broken pipe) ---
+++ killed by SIGPIPE +++

- I have tried running this on Fedora Core 2 with the exact same results :(

Thanks very much for your response!

-Steph



|---------+------------------------------------------>
| | Thomas Anders |
| | <***@blue-cable.de> |
| | Sent by: |
| | net-snmp-users-***@lists.sour|
| | ceforge.net |
| | |
| | |
| | 10/26/2004 04:57 PM |
| | |
|---------+------------------------------------------>
------------------------------------------------------------------------------------------------------------------------|
| |
| To: net-snmp-***@lists.sourceforge.net |
| cc: |
| Subject: Re: snmptrapd traphandle problem please help |
------------------------------------------------------------------------------------------------------------------------|
I was using net-snmp 5.1.1 but then prayed and hoped that if I compiled
and
installed 5.1.2 the problem would go away, so now I am using net-snmp
5.1.2
and still having this problem.
Do you have the chance to check if you also see this problem with
5.2.rc1?

Also, a few other ideas:
- Does
env SNMPCONFPATH=/usr/local/share/snmp \
/usr/local/sbin/snmptrapd -Lo -f -Dall -On
work any better for you?
- Have you double-checked (with ps or pgrep) that snmptrapd
has really exited?
- You may want to run snmptrapd under a debugger to see where/why
it exits


+Thomas

--
Thomas Anders <thomas.anders at blue-cable.de>


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Net-snmp-users mailing list
Net-snmp-***@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users




< END >


-----------------------------------------
The information contained in this email message is intended only for use of
the individual or entity named above. If the reader of this message is not
the intended recipient, or the employee or agent responsible to deliver it
to the intended recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited. If
you have received this communication in error, please immediately notify us
by email (***@weil.com), and destroy the original message. Thank you
Alex Burger
2004-10-26 20:12:02 UTC
Permalink
Hi.

Have all your tests been with the same trap? If so, can you try a
different trap such as a coldStart?

Try configuring snmpd on the machine with:

trapsink 127.0.0.1 public

and then restart snmpd. You should get a coldStart trap.

Another thing to try is to DELETE your snmptrapd.conf file and re-create
it from scratch. Probably unlikely but invisible escape codes have
caused me problems many times (not necessarily with Net-SNMP).

Alex
Post by s***@weil.com
HI Thomas,
I have some more information on the problem as I have been working on this
1) No this displays the same result
2) I have checked with ps and the process is missing after I receive a
trap it dies
3) I have performed an strace and it seems as though it is getting a
SIGPIPE (Broken Pipe) signal
strace /usr/local/sbin/snmptrapd -n -Lo -f -On -C -c
/usr/local/share/snmp/snmptrapd.conf
close(7) = 0
munmap(0x40179000, 4096) = 0
stat64("/usr/local/share/snmp/snmptrapd.conf", {st_mode=S_IFREG|0644,
st_size=865, ...}) = 0
open("/usr/local/share/snmp/snmptrapd.conf", O_RDONLY) = 7
fstat64(7, {st_mode=S_IFREG|0644, st_size=865, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40179000
read(7, "################################"..., 4096) = 865
read(7, "", 4096) = 0
close(7) = 0
munmap(0x40179000, 4096) = 0
gettimeofday({1098825239, 92336}, NULL) = 0
time(NULL) = 1098825239
gettimeofday({1098825239, 92732}, NULL) = 0
time([1098825239]) = 1098825239
open("/etc/localtime", O_RDONLY) = 7
fstat64(7, {st_mode=S_IFREG|0644, st_size=1267, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40179000
read(7, "TZif\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\4\0\0\0\4\0"..., 4096)
= 1267
brk(0x8081000) = 0x8081000
close(7) = 0
munmap(0x40179000, 4096) = 0
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40179000
write(1, "2004-10-26 17:13:59 NET-SNMP ver"..., 522004-10-26 17:13:59
NET-SNMP version 5.1.2 Started.
) = 52
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 7
setsockopt(7, SOL_SOCKET, SO_BSDCOMPAT, [1], 4) = 0
setsockopt(7, SOL_SOCKET, SO_SNDBUF, [131072], 4) = 0
setsockopt(7, SOL_SOCKET, SO_RCVBUF, [131072], 4) = 0
bind(7, {sin_family=AF_INET, sin_port=htons(162),
sin_addr=inet_addr("0.0.0.0")}}, 16) = 0
rt_sigaction(SIGTERM, {0x804a0e0, [TERM], SA_RESTART|0x4000000}, {SIG_DFL},
8) = 0
rt_sigaction(SIGHUP, {0x804a0f0, [HUP], SA_RESTART|0x4000000}, {SIG_DFL},
8) = 0
rt_sigaction(SIGINT, {0x804a0e0, [INT], SA_RESTART|0x4000000}, {SIG_DFL},
8) = 0
gettimeofday({1098825239, 97728}, NULL) = 0
gettimeofday({1098825239, 97967}, NULL) = 0
select(8, [3 5 7], NULL, NULL, {5, 0}) = 1 (in [7], left {2, 380000})
gettimeofday({1098825241, 718218}, NULL) = 0
brk(0x8092000) = 0x8092000
65536, 0, {sin_family=AF_INET, sin_port=htons(161),
sin_addr=inet_addr("172.24.3.50")}}, [16]) = 143
time([1098825241]) = 1098825241
write(1, "2004-10-26 17:14:01 172.24.3.50("..., 2992004-10-26 17:14:01
172.24.3.50(via 172.24.3.50) TRAP, SNMP v1, community public
.1.3.6.1.4.1.89.35.1 Enterprise Specific Trap (3) Uptime: 11 days,
6:49:43.57
.1.3.6.1.4.1.89.2.3.1.0 = STRING: "Illegal Load Report received
2
) = 299
pipe([8, 9]) = 0
pipe([10, 11]) = 0
fork() = 1469
--- SIGCHLD (Child exited) ---
close(8) = 0
close(11) = 0
write(9, "172.24.3.50\n172.24.3.50\n.1.3.6.1"..., 287) = -1 EPIPE (Broken
pipe)
--- SIGPIPE (Broken pipe) ---
+++ killed by SIGPIPE +++
- I have tried running this on Fedora Core 2 with the exact same results :(
Thanks very much for your response!
-Steph
|---------+------------------------------------------>
| | Thomas Anders |
| | Sent by: |
| | ceforge.net |
| | |
| | |
| | 10/26/2004 04:57 PM |
| | |
|---------+------------------------------------------>
------------------------------------------------------------------------------------------------------------------------|
| |
| cc: |
| Subject: Re: snmptrapd traphandle problem please help |
------------------------------------------------------------------------------------------------------------------------|
I was using net-snmp 5.1.1 but then prayed and hoped that if I compiled
and
installed 5.1.2 the problem would go away, so now I am using net-snmp
5.1.2
and still having this problem.
Do you have the chance to check if you also see this problem with
5.2.rc1?
- Does
env SNMPCONFPATH=/usr/local/share/snmp \
/usr/local/sbin/snmptrapd -Lo -f -Dall -On
work any better for you?
- Have you double-checked (with ps or pgrep) that snmptrapd
has really exited?
- You may want to run snmptrapd under a debugger to see where/why
it exits
+Thomas
--
Thomas Anders <thomas.anders at blue-cable.de>
-------------------------------------------------------
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Net-snmp-users mailing list
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
< END >
-----------------------------------------
The information contained in this email message is intended only for use of
the individual or entity named above. If the reader of this message is not
the intended recipient, or the employee or agent responsible to deliver it
to the intended recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited. If
you have received this communication in error, please immediately notify us
-------------------------------------------------------
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Net-snmp-users mailing list
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
Alex Burger
2004-10-26 20:10:19 UTC
Permalink
Post by s***@weil.com
Hello,
I am having a problem I just can not figure out with snmptrapd. I simply
wrote traphandler script to echo Hello World out to the screen when a
certain trap is detected. To set this up I configured
/usr/local/share/snmp/snmptrapd.conf with the following lines
<snip>
Post by s***@weil.com
traphandle .1.3.6.1.4.1.89.35.1.0.3 /root/traphandle
The problem is when I run snmptrapd and the trap with stated OID is
generated snmptrapd just exits and I do not get any output from my
traphandler even though snmptrapd 1) receives the trap and 2) finds and
knows about the traphandler. I get the same result if I replace the
specific OID with the default directive.
/usr/local/sbin/snmptrapd -Lo -Dall -On -C -c
/usr/local/share/snmp/snmptrapd.conf
You didn't specify -f, so snmptrapd will fork to the background so you
will never see any output to STDOUT. Try this:

snmptrapd -f -Lo -On -C -c /usr/local/share/snmp/snmptrapd.conf

Alex
Dave Shield
2004-10-27 06:52:09 UTC
Permalink
Post by s***@weil.com
I am having a problem I just can not figure out with snmptrapd. I simply
wrote traphandler script to echo Hello World out to the screen when a
certain trap is detected.
Is that *all* that the trap handler does?
Does it try to read the list of trap varbinds which 'snmptrapd'
will pass to it?

I have a feeling that the traphandler doesn't cope very well
with a handler script that doesn't read these values in.

It certainly doesn't like it if the trap handler script isn't
there at all (see bug #884868), and I wouldn't be surprised if
a non-reading trap handler was similar.

Dave
s***@weil.com
2004-10-27 11:36:06 UTC
Permalink
Hello Dave,

I think we are making progress here. Thomas had suggested that I replace my
traphandler script with /bin/cat to see if this would change the behavior
of snmptrapd when a trap comes in that is specified in the snmptrapd.conf
file. I'm happy to say that this did work the traps came in uninterrupted
(No Broken Pipe) when I had my snmptrapd.conf look like this:

traphandle .1.3.6.1.4.1.89.35.1.0.3 /bin/cat

I had also before tried something similar using the following
snmptrapd.conf:

traphandle .1.3.6.1.4.1.89.35.1.0.3 /bin/eject

which was also working but I didn't want to explain to the list that I had
rigged a notification method that would eject the cd-rom tray on my server
everytime my trap came in!

My confusion is now on how to utilize the var binds that snmptrapd is
passing to my trpahandler in my script? Do I have to use all of them? is it
enough to just read them in and echo them back out?

Thomas,

I will try to install and test 5.2.rc1 today and let you know my results.

Thank you
-Steph



|---------+------------------------------------------>
| | Dave Shield |
| | <***@csc.liv.ac.uk> |
| | Sent by: |
| | net-snmp-users-***@lists.sour|
| | ceforge.net |
| | |
| | |
| | 10/27/2004 04:51 AM |
| | |
|---------+------------------------------------------>
------------------------------------------------------------------------------------------------------------------------|
| |
| To: Stephanos Kotsakis/NY/WGM/***@WGM |
| cc: net-snmp-***@lists.sourceforge.net |
| Subject: Re: snmptrapd traphandle problem please help |
------------------------------------------------------------------------------------------------------------------------|
I am having a problem I just can not figure out with snmptrapd. I simply
wrote traphandler script to echo Hello World out to the screen when a
certain trap is detected.
Is that *all* that the trap handler does?
Does it try to read the list of trap varbinds which 'snmptrapd'
will pass to it?

I have a feeling that the traphandler doesn't cope very well
with a handler script that doesn't read these values in.

It certainly doesn't like it if the trap handler script isn't
there at all (see bug #884868), and I wouldn't be surprised if
a non-reading trap handler was similar.

Dave



-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Net-snmp-users mailing list
Net-snmp-***@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users




< END >


-----------------------------------------
The information contained in this email message is intended only for use of
the individual or entity named above. If the reader of this message is not
the intended recipient, or the employee or agent responsible to deliver it
to the intended recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited. If
you have received this communication in error, please immediately notify us
by email (***@weil.com), and destroy the original message. Thank you
Dave Shield
2004-10-27 11:39:04 UTC
Permalink
Post by s***@weil.com
My confusion is now on how to utilize the var binds that snmptrapd is
passing to my trpahandler in my script? Do I have to use all of them?
You don't need to actually use any of them.
The trap daemon doesn't care what happens *inside* your handler.
Post by s***@weil.com
is it enough to just read them in and echo them back out?
You don't even need to echo them out.
As long as you read them in, snmptrapd should be happy.
You can discard them immediately - that's fine.

Dave
Dave Shield
2004-10-28 10:58:24 UTC
Permalink
[ First - *please* don't mail me privately, without copying
any responses to the mailing list. I don't have the time
or inclination to offer private, unpaid, SNMP consultancy.
Keep discussions to the list, where others can both learn
and offer advice. Thanks. ]
Here are my results. the simplest way to make the problem stop is to simply
#!/bin/bash
read
is enough to solve the problem of the snmptrapd exiting out when there it
receives a trap specified in snmptrapd.conf.
Yes - that's pretty much what I expected.
This is a clear bug that we need to fix.
(But not until *after* 5.2!)
I implemented this bash script
and had excelent results
#!/bin/bash
read one
read two
read three
echo -e "$one $two $three" >> /root/testfile
here is the contents of /root/testfile
172.24.3.50 172.24.3.50 .1.3.6.1.2.1.1.3.0 12:1:58:03.66
172.24.3.50 172.24.3.50 .1.3.6.1.2.1.1.3.0 12:1:58:05.96
172.24.3.50 172.24.3.50 .1.3.6.1.2.1.1.3.0 12:1:58:13.66
172.24.3.50 172.24.3.50 .1.3.6.1.2.1.1.3.0 12:1:58:15.96
172.24.3.50 172.24.3.50 .1.3.6.1.2.1.1.3.0 12:1:58:23.67
172.24.3.50 172.24.3.50 .1.3.6.1.2.1.1.3.0 12:1:58:25.96
172.24.3.50 172.24.3.50 .1.3.6.1.2.1.1.3.0 12:1:58:33.67
172.24.3.50 172.24.3.50 .1.3.6.1.2.1.1.3.0 12:1:58:35.95
172.24.3.50 172.24.3.50 .1.3.6.1.2.1.1.3.0 12:1:58:43.67
172.24.3.50 172.24.3.50 .1.3.6.1.2.1.1.3.0 12:1:58:45.96
172.24.3.50 172.24.3.50 .1.3.6.1.2.1.1.3.0 12:1:58:53.66
Looks good.
(Well, it looks pretty boring and not very meaningful to be
honest, but you know what I mean!)
My only question now is it seems that I still can't get the traphandler to
output to stdout, I must have the output go to file, any ideas on this?
Ummmm.....
Well, as a general rule, there's nothing to guarantee that there will
*be* a "standard output" channel for things to be displayed to. The
trap daemon is designed to be run as just that - a daemon. So it will
typically be run in the background, not connected to a terminal at all.

I'm not sure how meaningful it is for a trap handler script to
print to stdout, or what the trap daemon should do with output
from such a script.
We'd probably need a discussion about the most appropriate behaviour
before starting to implement anything.

Dave
s***@weil.com
2004-10-28 11:26:04 UTC
Permalink
First off let me apologize to Dave, that last email was my fault I don't
know what I did wrong and it didn't get posted to the list. Secondly I
would like to thank everyone who helped me track this problem down.

thanks to you all!

-Steph



|---------+---------------------------->
| | Dave Shield |
| | <***@csc.l|
| | iv.ac.uk> |
| | |
| | 10/28/2004 08:54 |
| | AM |
| | |
|---------+---------------------------->
------------------------------------------------------------------------------------------------------------------------|
| |
| To: Stephanos Kotsakis/NY/WGM/***@WGM |
| cc: net-snmp-***@lists.sourceforge.net |
| Subject: Re: snmptrapd traphandle problem please help |
------------------------------------------------------------------------------------------------------------------------|
[ First - *please* don't mail me privately, without copying
any responses to the mailing list. I don't have the time
or inclination to offer private, unpaid, SNMP consultancy.
Keep discussions to the list, where others can both learn
and offer advice. Thanks. ]
Here are my results. the simplest way to make the problem stop is to
simply
#!/bin/bash
read
is enough to solve the problem of the snmptrapd exiting out when there it
receives a trap specified in snmptrapd.conf.
Yes - that's pretty much what I expected.
This is a clear bug that we need to fix.
(But not until *after* 5.2!)
I implemented this bash script
and had excelent results
#!/bin/bash
read one
read two
read three
echo -e "$one $two $three" >> /root/testfile
here is the contents of /root/testfile
172.24.3.50 172.24.3.50 .1.3.6.1.2.1.1.3.0 12:1:58:03.66
172.24.3.50 172.24.3.50 .1.3.6.1.2.1.1.3.0 12:1:58:05.96
172.24.3.50 172.24.3.50 .1.3.6.1.2.1.1.3.0 12:1:58:13.66
172.24.3.50 172.24.3.50 .1.3.6.1.2.1.1.3.0 12:1:58:15.96
172.24.3.50 172.24.3.50 .1.3.6.1.2.1.1.3.0 12:1:58:23.67
172.24.3.50 172.24.3.50 .1.3.6.1.2.1.1.3.0 12:1:58:25.96
172.24.3.50 172.24.3.50 .1.3.6.1.2.1.1.3.0 12:1:58:33.67
172.24.3.50 172.24.3.50 .1.3.6.1.2.1.1.3.0 12:1:58:35.95
172.24.3.50 172.24.3.50 .1.3.6.1.2.1.1.3.0 12:1:58:43.67
172.24.3.50 172.24.3.50 .1.3.6.1.2.1.1.3.0 12:1:58:45.96
172.24.3.50 172.24.3.50 .1.3.6.1.2.1.1.3.0 12:1:58:53.66
Looks good.
(Well, it looks pretty boring and not very meaningful to be
honest, but you know what I mean!)
My only question now is it seems that I still can't get the traphandler
to
output to stdout, I must have the output go to file, any ideas on this?
Ummmm.....
Well, as a general rule, there's nothing to guarantee that there will
*be* a "standard output" channel for things to be displayed to. The
trap daemon is designed to be run as just that - a daemon. So it will
typically be run in the background, not connected to a terminal at all.

I'm not sure how meaningful it is for a trap handler script to
print to stdout, or what the trap daemon should do with output
from such a script.
We'd probably need a discussion about the most appropriate behaviour
before starting to implement anything.

Dave
< END >


-----------------------------------------
The information contained in this email message is intended only for use of
the individual or entity named above. If the reader of this message is not
the intended recipient, or the employee or agent responsible to deliver it
to the intended recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited. If
you have received this communication in error, please immediately notify us
by email (***@weil.com), and destroy the original message. Thank you
Loading...