[Nagiosplug-devel] Plugin check_http segfaulting on OpenBSD 3.4-STABLE
C. Bensend
benny at bennyvision.com
Tue Apr 6 07:36:28 CEST 2004
Hey folks,
I sat down tonight to debug a few issues I've been having with Nagios
2.0a1, and I caught check_http segfaulting when I shut down an Apache
server to force an alert from nagios. The service returns to normal (and
check_http behaves) when I fire Apache up again.
This is with the latest plugins snapshot (from March 29th), on an OpenBSD
3.4-STABLE machine. I captured the following ktrace data (snipped for the
interesting bits - if the entire trace is needed, let me know):
9460 check_http RET socket 3
9460 check_http CALL sigprocmask(0x1,0xffffffff)
9460 check_http RET sigprocmask 0
9460 check_http CALL mprotect(0x3c005000,0x2000,0x3)
9460 check_http RET mprotect 0
9460 check_http CALL mprotect(0x3c005000,0x2000,0x1)
9460 check_http RET mprotect 0
9460 check_http CALL sigprocmask(0x3,0)
9460 check_http RET sigprocmask -65793/0xfffefeff
9460 check_http CALL connect(0x3,0x3c00b060,0x10)
9460 check_http RET connect -1 errno 61 Connection refused
9460 check_http CALL sigprocmask(0x1,0xffffffff)
9460 check_http RET sigprocmask 0
9460 check_http CALL mprotect(0x3c005000,0x2000,0x3)
9460 check_http RET mprotect 0
9460 check_http CALL mprotect(0x3c005000,0x2000,0x1)
9460 check_http RET mprotect 0
9460 check_http CALL sigprocmask(0x3,0)
9460 check_http RET sigprocmask -65793/0xfffefeff
9460 check_http CALL close(0x3)
9460 check_http RET close 0
9460 check_http CALL sigprocmask(0x1,0xffffffff)
9460 check_http RET sigprocmask 0
9460 check_http CALL mprotect(0x3c005000,0x2000,0x3)
9460 check_http RET mprotect 0
9460 check_http CALL mprotect(0x3c005000,0x2000,0x1)
9460 check_http RET mprotect 0
9460 check_http CALL sigprocmask(0x3,0)
9460 check_http RET sigprocmask -65793/0xfffefeff
9460 check_http PSIG SIGSEGV SIG_DFL code 1 addr=0x1c trapno=1
9460 check_http PSIG SIGSEGV SIG_DFL code 0 addr=0x0 trapno=0
9460 check_http NAMI "check_http.core"
And this is where the plugin dies.
Once I fire Apache back up and ktrace again:
24768 check_http RET mprotect 0
24768 check_http CALL sigprocmask(0x3,0)
24768 check_http RET sigprocmask -65793/0xfffefeff
24768 check_http CALL write(0x1,0x3c00f000,0x60)
24768 check_http GIO fd 1 wrote 96 bytes
"HTTP OK HTTP/1.1 200 OK - 2215 bytes in 0.064 seconds
|time=0.063799s;\
;;0.000000 size=2215B;;;0
"
24768 check_http RET write 96/0x60
24768 check_http CALL sigprocmask(0x1,0xffffffff)
24768 check_http RET sigprocmask 0
24768 check_http CALL mprotect(0x3c005000,0x2000,0x3)
24768 check_http RET mprotect 0
24768 check_http CALL mprotect(0x3c005000,0x2000,0x1)
24768 check_http RET mprotect 0
24768 check_http CALL sigprocmask(0x3,0)
24768 check_http RET sigprocmask -65793/0xfffefeff
24768 check_http CALL sigprocmask(0x1,0xffffffff)
24768 check_http RET sigprocmask 0
24768 check_http CALL mprotect(0x286fd000,0x2000,0x3)
24768 check_http RET mprotect 0
24768 check_http CALL mprotect(0x286fd000,0x2000,0x1)
24768 check_http RET mprotect 0
24768 check_http CALL sigprocmask(0x3,0)
24768 check_http RET sigprocmask -65793/0xfffefeff
24768 check_http CALL sigprocmask(0x1,0xffffffff)
24768 check_http RET sigprocmask 0
24768 check_http CALL mprotect(0x286fd000,0x2000,0x3)
24768 check_http RET mprotect 0
24768 check_http CALL mprotect(0x286fd000,0x2000,0x1)
24768 check_http RET mprotect 0
24768 check_http CALL sigprocmask(0x3,0)
24768 check_http RET sigprocmask -65793/0xfffefeff
24768 check_http CALL munmap(0x7c008000,0x1000)
24768 check_http RET munmap 0
24768 check_http CALL sigprocmask(0x1,0xffffffff)
24768 check_http RET sigprocmask 0
24768 check_http CALL mprotect(0x286fd000,0x2000,0x3)
24768 check_http RET mprotect 0
24768 check_http CALL mprotect(0x286fd000,0x2000,0x1)
24768 check_http RET mprotect 0
24768 check_http CALL sigprocmask(0x3,0)
24768 check_http RET sigprocmask -65793/0xfffefeff
24768 check_http CALL exit(0)
I was running plugins from the beginning of March (which behaved the same
way), upgrading to the latest didn't help.
One thought that came to my mind is that this might be some of OpenBSD's
security features kicking in on an iffy piece of code and pre-emptively
killing it. I don't find anything in my system logs, but I'll keep
looking.
Thoughts? Ideas? Cluebats?
Benny
--
"I can't believe it's not carp!" -- MXC
More information about the Devel
mailing list