From td3201 at gmail.com Tue Sep 1 16:21:43 2009 From: td3201 at gmail.com (Terry) Date: Tue, 1 Sep 2009 09:21:43 -0500 Subject: [Nagiosplug-devel] check_ntp_peer - buffer overflow Message-ID: <8ee061010909010721w3feefceeua0d0678a90afdfd7@mail.gmail.com> I can run check_ntp_peer -h and get a help page returned. Please see details below. It does the same thing both for a linux ntp server and a windows domain controller. Let me know what else is needed. [root at omajelut01 objects]# strace /usr/lib64/nagios/plugins/check_ntp_peer -H omarootdc01.jel.lc -w 0.5 -c 1 execve("/usr/lib64/nagios/plugins/check_ntp_peer", ["/usr/lib64/nagios/plugins/check_"..., "-H", "omarootdc01.jel.lc", "-w", "0.5", "-c", "1"], [/* 22 vars */]) = 0 brk(0) = 0x1771000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b9711cd4000 uname({sys="Linux", node="omajelut01.jelecos.ms", ...}) = 0 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=26948, ...}) = 0 mmap(NULL, 26948, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2b9711cd5000 close(3) = 0 open("/lib64/libnsl.so.1", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240@\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=111480, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b9711cdc000 mmap(NULL, 2194096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x2b9711ed5000 mprotect(0x2b9711eea000, 2093056, PROT_NONE) = 0 mmap(0x2b97120e9000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x14000) = 0x2b97120e9000 mmap(0x2b97120eb000, 6832, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2b97120eb000 close(3) = 0 open("/lib64/libresolv.so.2", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\2402\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=89800, ...}) = 0 mmap(NULL, 2181864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x2b97120ed000 mprotect(0x2b97120fe000, 2097152, PROT_NONE) = 0 mmap(0x2b97122fe000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x11000) = 0x2b97122fe000 mmap(0x2b9712300000, 6888, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2b9712300000 close(3) = 0 open("/lib64/libm.so.6", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`>\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=611880, ...}) = 0 mmap(NULL, 2629848, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x2b9712302000 mprotect(0x2b9712384000, 2093056, PROT_NONE) = 0 mmap(0x2b9712583000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x81000) = 0x2b9712583000 close(3) = 0 open("/lib64/libdl.so.2", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\16\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=20424, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b9712585000 mmap(NULL, 2109696, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x2b9712586000 mprotect(0x2b9712588000, 2097152, PROT_NONE) = 0 mmap(0x2b9712788000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x2b9712788000 close(3) = 0 open("/lib64/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0p\332\1\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=1707512, ...}) = 0 mmap(NULL, 3494168, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x2b971278a000 mprotect(0x2b97128d6000, 2097152, PROT_NONE) = 0 mmap(0x2b9712ad6000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x14c000) = 0x2b9712ad6000 mmap(0x2b9712adb000, 16664, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2b9712adb000 close(3) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b9712ae0000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b9712ae1000 arch_prctl(ARCH_SET_FS, 0x2b9712ae0af0) = 0 mprotect(0x2b9712ad6000, 16384, PROT_READ) = 0 mprotect(0x2b9712788000, 4096, PROT_READ) = 0 mprotect(0x2b9712583000, 4096, PROT_READ) = 0 mprotect(0x2b97122fe000, 4096, PROT_READ) = 0 mprotect(0x2b97120e9000, 4096, PROT_READ) = 0 mprotect(0x2b9711ed3000, 4096, PROT_READ) = 0 munmap(0x2b9711cd5000, 26948) = 0 brk(0) = 0x1771000 brk(0x1792000) = 0x1792000 open("/usr/lib/locale/locale-archive", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=56458944, ...}) = 0 mmap(NULL, 56458944, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2b9712ae2000 close(3) = 0 socket(PF_FILE, SOCK_STREAM, 0) = 3 fcntl(3, F_GETFL) = 0x2 (flags O_RDWR) fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0 connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory) close(3) = 0 socket(PF_FILE, SOCK_STREAM, 0) = 3 fcntl(3, F_GETFL) = 0x2 (flags O_RDWR) fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0 connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory) close(3) = 0 open("/etc/nsswitch.conf", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=1710, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b97160ba000 read(3, "#\n# /etc/nsswitch.conf\n#\n# An ex"..., 4096) = 1710 read(3, "", 4096) = 0 close(3) = 0 munmap(0x2b97160ba000, 4096) = 0 getpid() = 16386 open("/etc/resolv.conf", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=82, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b97160ba000 read(3, "nameserver 10.98.1.244\nnameserve"..., 4096) = 82 read(3, "", 4096) = 0 close(3) = 0 munmap(0x2b97160ba000, 4096) = 0 open("/etc/ld.so.cache", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=26948, ...}) = 0 mmap(NULL, 26948, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2b97160ba000 close(3) = 0 open("/lib64/libnss_files.so.2", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\37\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=53880, ...}) = 0 mmap(NULL, 2139432, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x2b97160c1000 mprotect(0x2b97160cb000, 2093056, PROT_NONE) = 0 mmap(0x2b97162ca000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x9000) = 0x2b97162ca000 close(3) = 0 mprotect(0x2b97162ca000, 4096, PROT_READ) = 0 munmap(0x2b97160ba000, 26948) = 0 open("/etc/hosts", O_RDONLY) = 3 fcntl(3, F_GETFD) = 0 fcntl(3, F_SETFD, FD_CLOEXEC) = 0 fstat(3, {st_mode=S_IFREG|0644, st_size=135, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b97160ba000 read(3, "::1\t\tlocalhost6.localdomain6 loc"..., 4096) = 135 read(3, "", 4096) = 0 close(3) = 0 munmap(0x2b97160ba000, 4096) = 0 open("/etc/hosts", O_RDONLY) = 3 fcntl(3, F_GETFD) = 0 fcntl(3, F_SETFD, FD_CLOEXEC) = 0 fstat(3, {st_mode=S_IFREG|0644, st_size=135, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b97160ba000 read(3, "::1\t\tlocalhost6.localdomain6 loc"..., 4096) = 135 read(3, "", 4096) = 0 close(3) = 0 munmap(0x2b97160ba000, 4096) = 0 open("/etc/ld.so.cache", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=26948, ...}) = 0 mmap(NULL, 26948, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2b97160ba000 close(3) = 0 open("/lib64/libnss_dns.so.2", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\17\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=23736, ...}) = 0 mmap(NULL, 2113792, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x2b97162cc000 mprotect(0x2b97162d0000, 2093056, PROT_NONE) = 0 mmap(0x2b97164cf000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x2b97164cf000 close(3) = 0 mprotect(0x2b97164cf000, 4096, PROT_READ) = 0 munmap(0x2b97160ba000, 26948) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3 connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.98.1.244")}, 28) = 0 fcntl(3, F_GETFL) = 0x2 (flags O_RDWR) fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}]) sendto(3, "\375\213\1\0\0\1\0\0\0\0\0\0\vomarootdc01\3jel\2lc\0"..., 36, MSG_NOSIGNAL, NULL, 0) = 36 poll([{fd=3, events=POLLIN}], 1, 5000) = 1 ([{fd=3, revents=POLLIN}]) ioctl(3, FIONREAD, [83]) = 0 recvfrom(3, "\375\213\201\200\0\1\0\0\0\1\0\0\vomarootdc01\3jel\2lc\0"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.98.1.244")}, [16]) = 83 close(3) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3 connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.98.1.244")}, 28) = 0 fcntl(3, F_GETFL) = 0x2 (flags O_RDWR) fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}]) sendto(3, "\36<\1\0\0\1\0\0\0\0\0\0\vomarootdc01\3jel\2lc\3"..., 43, MSG_NOSIGNAL, NULL, 0) = 43 poll([{fd=3, events=POLLIN}], 1, 5000) = 1 ([{fd=3, revents=POLLIN}]) ioctl(3, FIONREAD, [102]) = 0 recvfrom(3, "\36<\201\203\0\1\0\0\0\1\0\0\vomarootdc01\3jel\2lc\3"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.98.1.244")}, [16]) = 102 close(3) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3 connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.98.1.244")}, 28) = 0 fcntl(3, F_GETFL) = 0x2 (flags O_RDWR) fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}]) sendto(3, "\3367\1\0\0\1\0\0\0\0\0\0\vomarootdc01\3jel\2lc\3"..., 47, MSG_NOSIGNAL, NULL, 0) = 47 poll([{fd=3, events=POLLIN}], 1, 5000) = 1 ([{fd=3, revents=POLLIN}]) ioctl(3, FIONREAD, [115]) = 0 recvfrom(3, "\3367\205\203\0\1\0\0\0\1\0\0\vomarootdc01\3jel\2lc\3"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.98.1.244")}, [16]) = 115 close(3) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3 connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.98.1.244")}, 28) = 0 fcntl(3, F_GETFL) = 0x2 (flags O_RDWR) fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}]) sendto(3, "f\\\1\0\0\1\0\0\0\0\0\0\vomarootdc01\3jel\2lc\7"..., 47, MSG_NOSIGNAL, NULL, 0) = 47 poll([{fd=3, events=POLLIN}], 1, 5000) = 1 ([{fd=3, revents=POLLIN}]) ioctl(3, FIONREAD, [125]) = 0 recvfrom(3, "f\\\201\203\0\1\0\0\0\1\0\0\vomarootdc01\3jel\2lc\7"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.98.1.244")}, [16]) = 125 close(3) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3 connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.98.1.244")}, 28) = 0 fcntl(3, F_GETFL) = 0x2 (flags O_RDWR) fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}]) sendto(3, "!T\1\0\0\1\0\0\0\0\0\0\vomarootdc01\3jel\2lc\0"..., 36, MSG_NOSIGNAL, NULL, 0) = 36 poll([{fd=3, events=POLLIN}], 1, 5000) = 1 ([{fd=3, revents=POLLIN}]) ioctl(3, FIONREAD, [52]) = 0 recvfrom(3, "!T\205\200\0\1\0\1\0\0\0\0\vomarootdc01\3jel\2lc\0"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.98.1.244")}, [16]) = 52 close(3) = 0 rt_sigaction(SIGALRM, {0x403580, [ALRM], SA_RESTORER|SA_RESTART, 0x2b97127ba280}, {SIG_DFL, [], 0}, 8) = 0 alarm(10) = 0 open("/etc/hosts", O_RDONLY) = 3 fcntl(3, F_GETFD) = 0 fcntl(3, F_SETFD, FD_CLOEXEC) = 0 fstat(3, {st_mode=S_IFREG|0644, st_size=135, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b97160ba000 read(3, "::1\t\tlocalhost6.localdomain6 loc"..., 4096) = 135 read(3, "", 4096) = 0 close(3) = 0 munmap(0x2b97160ba000, 4096) = 0 open("/etc/hosts", O_RDONLY) = 3 fcntl(3, F_GETFD) = 0 fcntl(3, F_SETFD, FD_CLOEXEC) = 0 fstat(3, {st_mode=S_IFREG|0644, st_size=135, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b97160ba000 read(3, "::1\t\tlocalhost6.localdomain6 loc"..., 4096) = 135 read(3, "", 4096) = 0 close(3) = 0 munmap(0x2b97160ba000, 4096) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3 connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.98.1.244")}, 28) = 0 fcntl(3, F_GETFL) = 0x2 (flags O_RDWR) fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}]) sendto(3, "\3117\1\0\0\1\0\0\0\0\0\0\vomarootdc01\3jel\2lc\0"..., 36, MSG_NOSIGNAL, NULL, 0) = 36 poll([{fd=3, events=POLLIN}], 1, 5000) = 1 ([{fd=3, revents=POLLIN}]) ioctl(3, FIONREAD, [83]) = 0 recvfrom(3, "\3117\201\200\0\1\0\0\0\1\0\0\vomarootdc01\3jel\2lc\0"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.98.1.244")}, [16]) = 83 close(3) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3 connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.98.1.244")}, 28) = 0 fcntl(3, F_GETFL) = 0x2 (flags O_RDWR) fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}]) sendto(3, "\274Q\1\0\0\1\0\0\0\0\0\0\vomarootdc01\3jel\2lc\3"..., 43, MSG_NOSIGNAL, NULL, 0) = 43 poll([{fd=3, events=POLLIN}], 1, 5000) = 1 ([{fd=3, revents=POLLIN}]) ioctl(3, FIONREAD, [102]) = 0 recvfrom(3, "\274Q\201\203\0\1\0\0\0\1\0\0\vomarootdc01\3jel\2lc\3"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.98.1.244")}, [16]) = 102 close(3) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3 connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.98.1.244")}, 28) = 0 fcntl(3, F_GETFL) = 0x2 (flags O_RDWR) fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}]) sendto(3, "\36\216\1\0\0\1\0\0\0\0\0\0\vomarootdc01\3jel\2lc\3"..., 47, MSG_NOSIGNAL, NULL, 0) = 47 poll([{fd=3, events=POLLIN}], 1, 5000) = 1 ([{fd=3, revents=POLLIN}]) ioctl(3, FIONREAD, [115]) = 0 recvfrom(3, "\36\216\205\203\0\1\0\0\0\1\0\0\vomarootdc01\3jel\2lc\3"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.98.1.244")}, [16]) = 115 close(3) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3 connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.98.1.244")}, 28) = 0 fcntl(3, F_GETFL) = 0x2 (flags O_RDWR) fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}]) sendto(3, "\2574\1\0\0\1\0\0\0\0\0\0\vomarootdc01\3jel\2lc\7"..., 47, MSG_NOSIGNAL, NULL, 0) = 47 poll([{fd=3, events=POLLIN}], 1, 5000) = 1 ([{fd=3, revents=POLLIN}]) ioctl(3, FIONREAD, [125]) = 0 recvfrom(3, "\2574\201\203\0\1\0\0\0\1\0\0\vomarootdc01\3jel\2lc\7"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.98.1.244")}, [16]) = 125 close(3) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3 connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.98.1.244")}, 28) = 0 fcntl(3, F_GETFL) = 0x2 (flags O_RDWR) fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}]) sendto(3, "\252\227\1\0\0\1\0\0\0\0\0\0\vomarootdc01\3jel\2lc\0"..., 36, MSG_NOSIGNAL, NULL, 0) = 36 poll([{fd=3, events=POLLIN}], 1, 5000) = 1 ([{fd=3, revents=POLLIN}]) ioctl(3, FIONREAD, [52]) = 0 recvfrom(3, "\252\227\201\200\0\1\0\1\0\0\0\0\vomarootdc01\3jel\2lc\0"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.98.1.244")}, [16]) = 52 close(3) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 3 connect(3, {sa_family=AF_INET, sin_port=htons(123), sin_addr=inet_addr("10.98.1.242")}, 16) = 0 write(3, "\26\1\0\1\0\0\0\0\0\0\0\0", 12) = 12 open("/dev/tty", O_RDWR|O_NOCTTY|O_NONBLOCK) = 4 writev(4, [{"*** buffer overflow detected ***"..., 34}, {"/usr/lib64/nagios/plugins/check_"..., 40}, {" terminated\n", 12}], 3*** buffer overflow detected ***: /usr/lib64/nagios/plugins/check_ntp_peer terminated ) = 86 open("/etc/ld.so.cache", O_RDONLY) = 5 fstat(5, {st_mode=S_IFREG|0644, st_size=26948, ...}) = 0 mmap(NULL, 26948, PROT_READ, MAP_PRIVATE, 5, 0) = 0x2b97160ba000 close(5) = 0 open("/lib64/libgcc_s.so.1", O_RDONLY) = 5 read(5, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\36\0\0\0\0\0\0"..., 832) = 832 fstat(5, {st_mode=S_IFREG|0755, st_size=56072, ...}) = 0 mmap(NULL, 2151784, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 5, 0) = 0x2b97164d1000 mprotect(0x2b97164de000, 2097152, PROT_NONE) = 0 mmap(0x2b97166de000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0xd000) = 0x2b97166de000 close(5) = 0 munmap(0x2b97160ba000, 26948) = 0 write(4, "======= Backtrace: =========\n", 29======= Backtrace: ========= ) = 29 writev(4, [{"/lib64/libc.so.6", 16}, {"(", 1}, {"__chk_fail", 10}, {"+0x", 3}, {"2f", 2}, {")", 1}, {"[0x", 3}, {"2b9712870c1f", 12}, {"]\n", 2}], 9/lib64/libc.so.6(__chk_fail+0x2f)[0x2b9712870c1f] ) = 50 writev(4, [{"/lib64/libc.so.6", 16}, {"(", 1}, {"__read_chk", 10}, {"+0x", 3}, {"28", 2}, {")", 1}, {"[0x", 3}, {"2b97128710e8", 12}, {"]\n", 2}], 9/lib64/libc.so.6(__read_chk+0x28)[0x2b97128710e8] ) = 50 writev(4, [{"/usr/lib64/nagios/plugins/check_"..., 40}, {"[0x", 3}, {"4021df", 6}, {"]\n", 2}], 4/usr/lib64/nagios/plugins/check_ntp_peer[0x4021df] ) = 51 writev(4, [{"/usr/lib64/nagios/plugins/check_"..., 40}, {"[0x", 3}, {"402b78", 6}, {"]\n", 2}], 4/usr/lib64/nagios/plugins/check_ntp_peer[0x402b78] ) = 51 writev(4, [{"/lib64/libc.so.6", 16}, {"(", 1}, {"__libc_start_main", 17}, {"+0x", 3}, {"f4", 2}, {")", 1}, {"[0x", 3}, {"2b97127a7974", 12}, {"]\n", 2}], 9/lib64/libc.so.6(__libc_start_main+0xf4)[0x2b97127a7974] ) = 57 writev(4, [{"/usr/lib64/nagios/plugins/check_"..., 40}, {"[0x", 3}, {"401339", 6}, {"]\n", 2}], 4/usr/lib64/nagios/plugins/check_ntp_peer[0x401339] ) = 51 write(4, "======= Memory map: ========\n", 29======= Memory map: ======== ) = 29 open("/proc/self/maps", O_RDONLY) = 5 read(5, "00400000-00407000 r-xp 00000000 "..., 1024) = 1024 write(4, "00400000-00407000 r-xp 00000000 "..., 102400400000-00407000 r-xp 00000000 fd:00 4063308 /usr/lib64/nagios/plugins/check_ntp_peer 00607000-00608000 rw-p 00007000 fd:00 4063308 /usr/lib64/nagios/plugins/check_ntp_peer 01771000-01792000 rw-p 01771000 00:00 0 [heap] 2b9711cb8000-2b9711cd4000 r-xp 00000000 fd:00 11141389 /lib64/ld-2.5.so 2b9711cd4000-2b9711cd5000 rw-p 2b9711cd4000 00:00 0 2b9711cdc000-2b9711cdd000 rw-p 2b9711cdc000 00:00 0 2b9711ed3000-2b9711ed4000 r--p 0001b000 fd:00 11141389 /lib64/ld-2.5.so 2b9711ed4000-2b9711ed5000 rw-p 0001c000 fd:00 11141389 /lib64/ld-2.5.so 2b9711ed5000-2b9711eea000 r-xp 00000000 fd:00 11141140 /lib64/libnsl-2.5.so 2b9711eea000-2b97120e9000 ---p 00015000 fd:00 11141140 /lib64/libnsl-2.5.so 2b97120e9000-2b97120ea000 r--p 00014000 fd:00 11141140 /lib64/libnsl-2.5.so 2b97120ea000-2b97120eb000 rw-p 00015000 fd:00 11141140 ) = 1024 read(5, " /lib64/libnsl-2.5"..., 1024) = 1024 write(4, " /lib64/libnsl-2.5"..., 1024 /lib64/libnsl-2.5.so 2b97120eb000-2b97120ed000 rw-p 2b97120eb000 00:00 0 2b97120ed000-2b97120fe000 r-xp 00000000 fd:00 11141156 /lib64/libresolv-2.5.so 2b97120fe000-2b97122fe000 ---p 00011000 fd:00 11141156 /lib64/libresolv-2.5.so 2b97122fe000-2b97122ff000 r--p 00011000 fd:00 11141156 /lib64/libresolv-2.5.so 2b97122ff000-2b9712300000 rw-p 00012000 fd:00 11141156 /lib64/libresolv-2.5.so 2b9712300000-2b9712302000 rw-p 2b9712300000 00:00 0 2b9712302000-2b9712384000 r-xp 00000000 fd:00 11141138 /lib64/libm-2.5.so 2b9712384000-2b9712583000 ---p 00082000 fd:00 11141138 /lib64/libm-2.5.so 2b9712583000-2b9712584000 r--p 00081000 fd:00 11141138 /lib64/libm-2.5.so 2b9712584000-2b9712585000 rw-p 00082000 fd:00 11141138 /lib64/libm-2.5.so 2b9712585000-2b9712586000 rw-p 2b9712585000 00:00 0 2b9712586000-2b9712588000 r-xp 00000000 fd:00 11141136 ) = 1024 read(5, "/lib64/libdl-2.5.so\n2b9712588000"..., 1024) = 1024 write(4, "/lib64/libdl-2.5.so\n2b9712588000"..., 1024/lib64/libdl-2.5.so 2b9712588000-2b9712788000 ---p 00002000 fd:00 11141136 /lib64/libdl-2.5.so 2b9712788000-2b9712789000 r--p 00002000 fd:00 11141136 /lib64/libdl-2.5.so 2b9712789000-2b971278a000 rw-p 00003000 fd:00 11141136 /lib64/libdl-2.5.so 2b971278a000-2b97128d6000 r-xp 00000000 fd:00 11141130 /lib64/libc-2.5.so 2b97128d6000-2b9712ad6000 ---p 0014c000 fd:00 11141130 /lib64/libc-2.5.so 2b9712ad6000-2b9712ada000 r--p 0014c000 fd:00 11141130 /lib64/libc-2.5.so 2b9712ada000-2b9712adb000 rw-p 00150000 fd:00 11141130 /lib64/libc-2.5.so 2b9712adb000-2b9712ae2000 rw-p 2b9712adb000 00:00 0 2b9712ae2000-2b97160ba000 r--p 00000000 fd:00 3612183 /usr/lib/locale/locale-archive 2b97160c1000-2b97160cb000 r-xp 00000000 fd:00 11141146 /lib64/libnss_files-2.5.so 2b97160cb000-2b97162ca000 ---p 0000a000 fd:00 11141146 /lib64/libnss_files-2.5.so ) = 1024 read(5, "2b97162ca000-2b97162cb000 r--p 0"..., 1024) = 1024 write(4, "2b97162ca000-2b97162cb000 r--p 0"..., 10242b97162ca000-2b97162cb000 r--p 00009000 fd:00 11141146 /lib64/libnss_files-2.5.so 2b97162cb000-2b97162cc000 rw-p 0000a000 fd:00 11141146 /lib64/libnss_files-2.5.so 2b97162cc000-2b97162d0000 r-xp 00000000 fd:00 11141144 /lib64/libnss_dns-2.5.so 2b97162d0000-2b97164cf000 ---p 00004000 fd:00 11141144 /lib64/libnss_dns-2.5.so 2b97164cf000-2b97164d0000 r--p 00003000 fd:00 11141144 /lib64/libnss_dns-2.5.so 2b97164d0000-2b97164d1000 rw-p 00004000 fd:00 11141144 /lib64/libnss_dns-2.5.so 2b97164d1000-2b97164de000 r-xp 00000000 fd:00 11141122 /lib64/libgcc_s-4.1.2-20080825.so.1 2b97164de000-2b97166de000 ---p 0000d000 fd:00 11141122 /lib64/libgcc_s-4.1.2-20080825.so.1 2b97166de000-2b97166df000 rw-p 0000d000 fd:00 11141122 /lib64/libgcc_s-4.1.2-20080825.so.1 7fff24b4c000-7fff24b61000 rw-p 7ffffffea000 00:00 0 [stack] ffffffffff600000-fffffff) = 1024 read(5, "fffe00000 ---p 00000000 00:00 0 "..., 1024) = 56 write(4, "fffe00000 ---p 00000000 00:00 0 "..., 56fffe00000 ---p 00000000 00:00 0 [vdso] ) = 56 read(5, "", 1024) = 0 close(5) = 0 rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0 tgkill(16386, 16386, SIGABRT) = 0 --- SIGABRT (Aborted) @ 0 (0) --- +++ killed by SIGABRT +++ [root at omajelut01 objects]# From dermoth at aei.ca Tue Sep 1 17:22:38 2009 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Tue, 01 Sep 2009 11:22:38 -0400 Subject: [Nagiosplug-devel] Please can I have GIT access In-Reply-To: <20090829161807.GF69749771@Waran.CIS.FU-Berlin.DE> References: <20090829111204.GT21433@phcomp.co.uk> <20090829161807.GF69749771@Waran.CIS.FU-Berlin.DE> Message-ID: <4A9D3C3E.9040506@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Holger Wei? wrote: > * Alain Williams [2009-08-29 12:12]: >> Please give me a GIT account. > > I'd be more than happy to see new team members who have the motiviation, > time, and skills to look into other people's bug reports and to review > and test their patches. But asking for Git access in order to be able > to push your own stuff before a consensus was reached is quite a > different pair of shoes. While I do have Git access, I would not > (ab)use it to push any patch of mine without seriously addressing such > concerns from Thomas and Matthias. Moreover you're free to create a fork on repo.or.cz and push your patches there. We will merge your tree if patches are acceptable and this will save us time. Having Git access on the main repo wouldn't help any more getting patches in because we'd revert unacceptable patches anyway. Back to the data retention debate, I agree if we go that way functions could be used for state retention. Another thing we could consider (although I believe you don't like it much) is shared memory... Finally I believe there's another method that should be considered, and although people are usually not very used to it it's pretty elegant IMHO. Just open two file descriptors for the plugin to use, one for reading in state and one for saving it. This could be done by Nagios and, for older Nagios versions or passive checks, a simple wrapper could be used to save the data to a file. Here's a Quick'nDirty(tm) example: $ cat test.pl #!/usr/bin/perl use strict; use warnings; use Storable qw(store_fd retrieve_fd); my %state; read_state(); $state{'counter'} += 1; print "Current counter: $state{'counter'}\n"; write_state(); sub read_state { open(STATE_RFD,"<&=3") || die "couldn't open read fd: $!"; eval { %state = %{retrieve_fd(\*STATE_RFD)}; }; close(STATE_RFD); } sub write_state { open(STATE_WFD,">&=4") || die "couldn't open write fd: $!"; store_fd(\%state,*STATE_WFD); close(STATE_WFD); } $ $ touch state; ./test.pl 3state.new; mv state.new state Current counter: 1 $ touch state; ./test.pl 3state.new; mv state.new state Current counter: 2 $ touch state; ./test.pl 3state.new; mv state.new state Current counter: 3 $ touch state; ./test.pl 3state.new; mv state.new state Current counter: 4 This is very flexible because if gives the caller the choice of where to write data to while using a simple and standard interface for using it. - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqdPD4ACgkQ6dZ+Kt5BchaEBACfaIXTJlX5MAGVIDuJ6OIH8+uv BJUAoM3odMZtYSuVFXz88ZnobSZBScvI =a6T+ -----END PGP SIGNATURE----- From perldork at webwizarddesign.com Tue Sep 1 18:21:28 2009 From: perldork at webwizarddesign.com (Max) Date: Tue, 1 Sep 2009 12:21:28 -0400 Subject: [Nagiosplug-devel] Please can I have GIT access In-Reply-To: <4A9D3C3E.9040506@aei.ca> References: <20090829111204.GT21433@phcomp.co.uk> <20090829161807.GF69749771@Waran.CIS.FU-Berlin.DE> <4A9D3C3E.9040506@aei.ca> Message-ID: On Tue, Sep 1, 2009 at 11:22 AM, Thomas Guyot-Sionnest wrote: > Back to the data retention debate, I agree if we go that way functions > could be used for state retention. Another thing we could consider > (although I believe you don't like it much) is shared memory... Files in RAM or memcache is a lot easier to manage than shared memory. > Finally I believe there's another method that should be considered, and > although people are usually not very used to it it's pretty elegant > IMHO. Just open two file descriptors for the plugin to use, one for > reading in state and one for saving it. This could be done by Nagios > and, for older Nagios versions or passive checks, a simple wrapper could > be used to save the data to a file. Here's a Quick'nDirty(tm) example: So FD 3 and 4 would be provided by Nagios to every plugin regardless of language? As I mentioned earlier, we have been using Memcache for this and getting very good performance from it from our poller even with 1000 or so plugin calls on a machine saving/getting state from it every few minutes .. it also has the advantage of being located off server if need be ... Or are you still speaking here of an extension to do state for NRPE-hosted plugins? - Max From kyleodonnell at gmail.com Tue Sep 1 18:34:05 2009 From: kyleodonnell at gmail.com (Kyle O'Donnell) Date: Tue, 1 Sep 2009 12:34:05 -0400 Subject: [Nagiosplug-devel] aix 6.1 compile? Message-ID: <2274b9c30909010934r50da83cdn26a031c22d0e2712@mail.gmail.com> Hi, Has anyone compiled the plugins (1.4.13) for AIX 6.1? I am attempting to, but running into some errors: Tpo" ".deps/getloadavg.Po"; else rm -f ".deps/getloadavg.Tpo"; exit 1; fi In file included from /usr/include/sys/corral.h:25, from /usr/include/libperfstat.h:28, from getloadavg.c:410: /usr/include/netinet/in6_var.h:65: error: array type has incomplete element type make: The error code from the last command is 1. Thanks, Kyle From addw at phcomp.co.uk Tue Sep 1 20:36:09 2009 From: addw at phcomp.co.uk (Alain Williams) Date: Tue, 1 Sep 2009 19:36:09 +0100 Subject: [Nagiosplug-devel] Please can I have GIT access In-Reply-To: References: <20090829111204.GT21433@phcomp.co.uk> <20090829161807.GF69749771@Waran.CIS.FU-Berlin.DE> <4A9D3C3E.9040506@aei.ca> Message-ID: <20090901183609.GW5441@phcomp.co.uk> On Tue, Sep 01, 2009 at 12:21:28PM -0400, Max wrote: > On Tue, Sep 1, 2009 at 11:22 AM, Thomas Guyot-Sionnest wrote: > > Back to the data retention debate, I agree if we go that way functions > > could be used for state retention. Another thing we could consider > > (although I believe you don't like it much) is shared memory... > > Files in RAM or memcache is a lot easier to manage than shared memory. Files: * easy to set up, flexible * don't use up RAM - some sites RAM is precious * those who do want the speed of RAM, simply create a RAM disk or tmpfs and put the files there * if it is a 'disk' directory and the system is not hard pressed on RAM, the files end up in RAM anyway (buffer cache) What needs to be agreed is a ''standard'' directory where these things can be stored, or perhaps a $STATE_SAVE_DIR$ that we can use. Maybe there ought to be some plugin state save/restore code, but I suspect that that may take some time to get agreed. > > Finally I believe there's another method that should be considered, and > > although people are usually not very used to it it's pretty elegant > > IMHO. Just open two file descriptors for the plugin to use, one for > > reading in state and one for saving it. This could be done by Nagios > > and, for older Nagios versions or passive checks, a simple wrapper could > > be used to save the data to a file. Here's a Quick'nDirty(tm) example: > > So FD 3 and 4 would be provided by Nagios to every plugin regardless > of language? > > As I mentioned earlier, we have been using Memcache for this and > getting very good performance from it from our poller even with 1000 > or so plugin calls on a machine saving/getting state from it every few > minutes .. it also has the advantage of being located off server if > need be ... Do the math: 1,000 plugins every 5 minutes. Let us say that all of them save state (highly unlikely). Assume that the size of a state file is 1KB. That is 3 state read/save per second, some 3KB read/written per second. Now look at how a typical plugin works. Take one written in C (nice & efficient). I looked at check_pop using strace. It opens 34 files. It does 32 read system calls. It does 59 mmap system calls. Much of this is in the startup code, mapping in libraries, etc. (On a CentOS 5 machine) Maybe it is untypical, how about check_ping It opens 19 files. It does 22 read system calls. It does 28 mmap system calls. Now check_procs which is what this fuss is about, the numbers include those of child processes: It opens 648 files. It does 647 read system calls. It does 29 mmap system calls. So: if on top of this is does one or two extra opens & a read/write - will it really make that much of a difference ? > Or are you still speaking here of an extension to do state for > NRPE-hosted plugins? Regards -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Past chairman of UKUUG: http://www.ukuug.org/ #include From dermoth at aei.ca Tue Sep 1 20:59:32 2009 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Tue, 01 Sep 2009 14:59:32 -0400 Subject: [Nagiosplug-devel] Please can I have GIT access In-Reply-To: References: <20090829111204.GT21433@phcomp.co.uk> <20090829161807.GF69749771@Waran.CIS.FU-Berlin.DE> <4A9D3C3E.9040506@aei.ca> Message-ID: <4A9D6F14.5000908@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Max wrote: > On Tue, Sep 1, 2009 at 11:22 AM, Thomas Guyot-Sionnest wrote: >> Back to the data retention debate, I agree if we go that way functions >> could be used for state retention. Another thing we could consider >> (although I believe you don't like it much) is shared memory... > > Files in RAM or memcache is a lot easier to manage than shared memory. Files in RAM means that you have to mount a tmpfs, so it's like plain files. Regarding memcache, I don't really see the plugins requiring it... It could be an option, but why not abstracting it in that case so at least you don't have to link the plugins against a memcache library? Anyway, see below why I don't like either of these method anyway... >> Finally I believe there's another method that should be considered, and >> although people are usually not very used to it it's pretty elegant >> IMHO. Just open two file descriptors for the plugin to use, one for >> reading in state and one for saving it. This could be done by Nagios >> and, for older Nagios versions or passive checks, a simple wrapper could >> be used to save the data to a file. Here's a Quick'nDirty(tm) example: > > So FD 3 and 4 would be provided by Nagios to every plugin regardless > of language? Yes... Could be driven by a configuration directive too, because otherwise nagios would have to provide the FDs either by creating the files or mmap()ing some memory for them. A simple c wrapper could do it as well with any desired storage (files, mmaped memory, shared memory, memcached...). This also have the advantage that the caller always determine the storage location, which could avoid unexpected issues if more that one Nagios instance runs the same checks or when a plugin is copied from another server. You have the same advantage when using performance data for state retention BTW, but obviously the storage is much more limited. > Or are you still speaking here of an extension to do state for > NRPE-hosted plugins? That would work everywhere, either directly with proper support of the underlying applications (Nagios, NRPE) or using a wrapper which as you could see isn't very hard to do. Even a bash onliner can do it: (touch file; /path/to/plugin 3file.new; ret=$?; mv file.new file; exit $ret) - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqdbxQACgkQ6dZ+Kt5BchZiTgCgl5pcOfdycD+ujw2v9gjRRs9h /LsAmgOaOpGGHTXxw5Dq7c1goEvQTRWN =tmDr -----END PGP SIGNATURE----- From dermoth at aei.ca Tue Sep 1 21:15:19 2009 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Tue, 01 Sep 2009 15:15:19 -0400 Subject: [Nagiosplug-devel] Please can I have GIT access In-Reply-To: <20090901183609.GW5441@phcomp.co.uk> References: <20090829111204.GT21433@phcomp.co.uk> <20090829161807.GF69749771@Waran.CIS.FU-Berlin.DE> <4A9D3C3E.9040506@aei.ca> <20090901183609.GW5441@phcomp.co.uk> Message-ID: <4A9D72C7.10806@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alain Williams wrote: > On Tue, Sep 01, 2009 at 12:21:28PM -0400, Max wrote: >> On Tue, Sep 1, 2009 at 11:22 AM, Thomas Guyot-Sionnest wrote: >>> Back to the data retention debate, I agree if we go that way functions >>> could be used for state retention. Another thing we could consider >>> (although I believe you don't like it much) is shared memory... >> Files in RAM or memcache is a lot easier to manage than shared memory. > > Files: > > * easy to set up, flexible > * don't use up RAM - some sites RAM is precious > * those who do want the speed of RAM, simply create a RAM disk or tmpfs and put the > files there > * if it is a 'disk' directory and the system is not hard pressed on RAM, the files > end up in RAM anyway (buffer cache) Just for completeness the FD method uses files primarily, but it actually gives that control to the caller. This means: * Plugin only cares about FD numbers to use, caller decides where data will go. No extra work, library or complex code required in the plugins. * If desired, caller can send FDs pointing to mmaped memory, and then decide where to store it afterward (private RAM, SHM, memcached, SQL...) * Any custom wrapper can be used, for any desired retention method. * Nagios and NRPE could provide basic methods for simple setups and to avoid an extra fork. Furthermore Nagios modules could be used to extend Nagios functionality in an efficient manner on large sites. I believe this method is much closer to the Unix philosophy of having multiple components doing simple tasks. - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqdcscACgkQ6dZ+Kt5BchabQACg9gM8qCcpFfI4UEWNlGum8+Md EQQAn3TEqvTVF8zpqZSouVpZyLFEoPRX =pYTp -----END PGP SIGNATURE----- From dermoth at aei.ca Wed Sep 2 04:21:01 2009 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Tue, 01 Sep 2009 22:21:01 -0400 Subject: [Nagiosplug-devel] aix 6.1 compile? In-Reply-To: <2274b9c30909010934r50da83cdn26a031c22d0e2712@mail.gmail.com> References: <2274b9c30909010934r50da83cdn26a031c22d0e2712@mail.gmail.com> Message-ID: <4A9DD68D.1080307@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/09/09 12:34 PM, Kyle O'Donnell wrote: > Hi, Hi Kyle, > Has anyone compiled the plugins (1.4.13) for AIX 6.1? I am attempting > to, but running into some errors: While we do our best to support as many architectures as possible and had success reports from many of them, supported platforms usually boils down to whichever platforms we have access to for testing and running tinderboxes. Since it's pretty hard to get our hands on commercial Unixes like AIX support for these is unfortunately limited. > Tpo" ".deps/getloadavg.Po"; else rm -f ".deps/getloadavg.Tpo"; exit 1; fi > In file included from /usr/include/sys/corral.h:25, > from /usr/include/libperfstat.h:28, > from getloadavg.c:410: > /usr/include/netinet/in6_var.h:65: error: array type has incomplete element type > make: The error code from the last command is 1. This seems to be a problem with Gnulib which is a separate library incorporated into Nagiosplugins. Since we updated Gnulib in the current development branch and it contains a fix for AIX 6.1 please try the latest snapshot. If you'd prefer an old stable you could try v1.4.12... According to the changelog of getloadavg.c use of libperfstat in AIX have been added on Feb 3 2008; with v1.4.12 you will get an older version of getloadavc.c wich may (or may not) work for you. Thanks P.s. If you'd be willing to use one of your servers as a tinderbox that will help us detect any regression as soon as possible and thus help keeping your platform supported. All you need is to run one or two builds daily using a script that send results back to our central server. Please contact Ton Voon directly (and cc me) if your want help setting one up. - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKndaN6dZ+Kt5BchYRAuxOAJ4ycS95TZ60Nh4z+/6/MtQcsOQm2gCfRrwb iHlfa+HLONW1uFjTFzBgssU= =kBly -----END PGP SIGNATURE----- From kyleodonnell at gmail.com Wed Sep 2 04:34:09 2009 From: kyleodonnell at gmail.com (Kyle O'Donnell) Date: Tue, 1 Sep 2009 22:34:09 -0400 Subject: [Nagiosplug-devel] aix 6.1 compile? In-Reply-To: <4A9DD68D.1080307@aei.ca> References: <2274b9c30909010934r50da83cdn26a031c22d0e2712@mail.gmail.com> <4A9DD68D.1080307@aei.ca> Message-ID: <2274b9c30909011934n504a1171wc5f7affd3cca6123@mail.gmail.com> I'll try both the latest and .12 Thanks! If it were up to me I'd setup tinderbox, but unfortunately my employer would not allow it. I plan on posting the binaries to the nagios exchange (as I have for hpux and solaris). --kyleo On Tue, Sep 1, 2009 at 10:21 PM, Thomas Guyot-Sionnest wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 01/09/09 12:34 PM, Kyle O'Donnell wrote: > > Hi, > > Hi Kyle, > > > Has anyone compiled the plugins (1.4.13) for AIX 6.1? I am attempting > > to, but running into some errors: > > While we do our best to support as many architectures as possible and > had success reports from many of them, supported platforms usually boils > down to whichever platforms we have access to for testing and running > tinderboxes. Since it's pretty hard to get our hands on commercial > Unixes like AIX support for these is unfortunately limited. > > > Tpo" ".deps/getloadavg.Po"; else rm -f ".deps/getloadavg.Tpo"; exit 1; fi > > In file included from /usr/include/sys/corral.h:25, > > from /usr/include/libperfstat.h:28, > > from getloadavg.c:410: > > /usr/include/netinet/in6_var.h:65: error: array type has incomplete > element type > > make: The error code from the last command is 1. > > This seems to be a problem with Gnulib which is a separate library > incorporated into Nagiosplugins. Since we updated Gnulib in the current > development branch and it contains a fix for AIX 6.1 please try the > latest snapshot. > > If you'd prefer an old stable you could try v1.4.12... According to the > changelog of getloadavg.c use of libperfstat in AIX have been added on > Feb 3 2008; with v1.4.12 you will get an older version of getloadavc.c > wich may (or may not) work for you. > > Thanks > > P.s. If you'd be willing to use one of your servers as a tinderbox that > will help us detect any regression as soon as possible and thus help > keeping your platform supported. All you need is to run one or two > builds daily using a script that send results back to our central > server. Please contact Ton Voon directly (and cc me) if your want help > setting one up. > > - -- > Thomas > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFKndaN6dZ+Kt5BchYRAuxOAJ4ycS95TZ60Nh4z+/6/MtQcsOQm2gCfRrwb > iHlfa+HLONW1uFjTFzBgssU= > =kBly > -----END PGP SIGNATURE----- > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________________ > Nagios Plugin Development Mailing List > Nagiosplug-devel at lists.sourceforge.net > Unsubscribe at > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyleodonnell at gmail.com Wed Sep 2 14:48:42 2009 From: kyleodonnell at gmail.com (Kyle O'Donnell) Date: Wed, 2 Sep 2009 08:48:42 -0400 Subject: [Nagiosplug-devel] aix 6.1 compile? In-Reply-To: <2274b9c30909011934n504a1171wc5f7affd3cca6123@mail.gmail.com> References: <2274b9c30909010934r50da83cdn26a031c22d0e2712@mail.gmail.com> <4A9DD68D.1080307@aei.ca> <2274b9c30909011934n504a1171wc5f7affd3cca6123@mail.gmail.com> Message-ID: <2274b9c30909020548t6feee90dre83b5a34e3fbcc14@mail.gmail.com> http://nagiosplug.sourceforge.net/snapshot/nagios-plugins-trunk-200909021200.tar.gz worked like a charm, but the RSS still doesnt work for check_procs, here is the ps command I use which works for aix 5.3 as well: On 9/1/09, Kyle O'Donnell wrote: > I'll try both the latest and .12 Thanks! > If it were up to me I'd setup tinderbox, but unfortunately my employer > would > not allow it. > > I plan on posting the binaries to the nagios exchange (as I have for hpux > and solaris). > > --kyleo > > On Tue, Sep 1, 2009 at 10:21 PM, Thomas Guyot-Sionnest > wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 01/09/09 12:34 PM, Kyle O'Donnell wrote: >> > Hi, >> >> Hi Kyle, >> >> > Has anyone compiled the plugins (1.4.13) for AIX 6.1? I am attempting >> > to, but running into some errors: >> >> While we do our best to support as many architectures as possible and >> had success reports from many of them, supported platforms usually boils >> down to whichever platforms we have access to for testing and running >> tinderboxes. Since it's pretty hard to get our hands on commercial >> Unixes like AIX support for these is unfortunately limited. >> >> > Tpo" ".deps/getloadavg.Po"; else rm -f ".deps/getloadavg.Tpo"; exit 1; >> > fi >> > In file included from /usr/include/sys/corral.h:25, >> > from /usr/include/libperfstat.h:28, >> > from getloadavg.c:410: >> > /usr/include/netinet/in6_var.h:65: error: array type has incomplete >> element type >> > make: The error code from the last command is 1. >> >> This seems to be a problem with Gnulib which is a separate library >> incorporated into Nagiosplugins. Since we updated Gnulib in the current >> development branch and it contains a fix for AIX 6.1 please try the >> latest snapshot. >> >> If you'd prefer an old stable you could try v1.4.12... According to the >> changelog of getloadavg.c use of libperfstat in AIX have been added on >> Feb 3 2008; with v1.4.12 you will get an older version of getloadavc.c >> wich may (or may not) work for you. >> >> Thanks >> >> P.s. If you'd be willing to use one of your servers as a tinderbox that >> will help us detect any regression as soon as possible and thus help >> keeping your platform supported. All you need is to run one or two >> builds daily using a script that send results back to our central >> server. Please contact Ton Voon directly (and cc me) if your want help >> setting one up. >> >> - -- >> Thomas >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.6 (GNU/Linux) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >> >> iD8DBQFKndaN6dZ+Kt5BchYRAuxOAJ4ycS95TZ60Nh4z+/6/MtQcsOQm2gCfRrwb >> iHlfa+HLONW1uFjTFzBgssU= >> =kBly >> -----END PGP SIGNATURE----- >> >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >> 30-Day >> trial. Simplify your report design, integration and deployment - and >> focus >> on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________________ >> Nagios Plugin Development Mailing List >> Nagiosplug-devel at lists.sourceforge.net >> Unsubscribe at >> https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel >> ::: Please include plugins version (-v) and OS when reporting any issue. >> ::: Messages without supporting info will risk being sent to /dev/null >> > From kyleodonnell at gmail.com Wed Sep 2 14:58:16 2009 From: kyleodonnell at gmail.com (Kyle O'Donnell) Date: Wed, 2 Sep 2009 08:58:16 -0400 Subject: [Nagiosplug-devel] aix 6.1 compile? In-Reply-To: <2274b9c30909020548t6feee90dre83b5a34e3fbcc14@mail.gmail.com> References: <2274b9c30909010934r50da83cdn26a031c22d0e2712@mail.gmail.com> <4A9DD68D.1080307@aei.ca> <2274b9c30909011934n504a1171wc5f7affd3cca6123@mail.gmail.com> <2274b9c30909020548t6feee90dre83b5a34e3fbcc14@mail.gmail.com> Message-ID: <2274b9c30909020558n71bca9cfof0a221ea22725d62@mail.gmail.com> --with-ps-command=/usr/sysv/bin/ps -eo 's uid pid ppid vsz rss pcpu etime comm args' --with-ps-format=%s %d %d %d %d %d %f %s %s %n --with-ps-cols=10 --with-ps-varlist=procstat,&procuid,&procpid,&procppid,&procvsz,&procrss,&procpcpu,procetime,procprog,&pos On 9/2/09, Kyle O'Donnell wrote: > http://nagiosplug.sourceforge.net/snapshot/nagios-plugins-trunk-200909021200.tar.gz > > worked like a charm, but the RSS still doesnt work for check_procs, > here is the ps command I use which works for aix 5.3 as well: > > > > On 9/1/09, Kyle O'Donnell wrote: >> I'll try both the latest and .12 Thanks! >> If it were up to me I'd setup tinderbox, but unfortunately my employer >> would >> not allow it. >> >> I plan on posting the binaries to the nagios exchange (as I have for hpux >> and solaris). >> >> --kyleo >> >> On Tue, Sep 1, 2009 at 10:21 PM, Thomas Guyot-Sionnest >> wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> On 01/09/09 12:34 PM, Kyle O'Donnell wrote: >>> > Hi, >>> >>> Hi Kyle, >>> >>> > Has anyone compiled the plugins (1.4.13) for AIX 6.1? I am attempting >>> > to, but running into some errors: >>> >>> While we do our best to support as many architectures as possible and >>> had success reports from many of them, supported platforms usually boils >>> down to whichever platforms we have access to for testing and running >>> tinderboxes. Since it's pretty hard to get our hands on commercial >>> Unixes like AIX support for these is unfortunately limited. >>> >>> > Tpo" ".deps/getloadavg.Po"; else rm -f ".deps/getloadavg.Tpo"; exit 1; >>> > fi >>> > In file included from /usr/include/sys/corral.h:25, >>> > from /usr/include/libperfstat.h:28, >>> > from getloadavg.c:410: >>> > /usr/include/netinet/in6_var.h:65: error: array type has incomplete >>> element type >>> > make: The error code from the last command is 1. >>> >>> This seems to be a problem with Gnulib which is a separate library >>> incorporated into Nagiosplugins. Since we updated Gnulib in the current >>> development branch and it contains a fix for AIX 6.1 please try the >>> latest snapshot. >>> >>> If you'd prefer an old stable you could try v1.4.12... According to the >>> changelog of getloadavg.c use of libperfstat in AIX have been added on >>> Feb 3 2008; with v1.4.12 you will get an older version of getloadavc.c >>> wich may (or may not) work for you. >>> >>> Thanks >>> >>> P.s. If you'd be willing to use one of your servers as a tinderbox that >>> will help us detect any regression as soon as possible and thus help >>> keeping your platform supported. All you need is to run one or two >>> builds daily using a script that send results back to our central >>> server. Please contact Ton Voon directly (and cc me) if your want help >>> setting one up. >>> >>> - -- >>> Thomas >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v1.4.6 (GNU/Linux) >>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >>> >>> iD8DBQFKndaN6dZ+Kt5BchYRAuxOAJ4ycS95TZ60Nh4z+/6/MtQcsOQm2gCfRrwb >>> iHlfa+HLONW1uFjTFzBgssU= >>> =kBly >>> -----END PGP SIGNATURE----- >>> >>> >>> ------------------------------------------------------------------------------ >>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >>> 30-Day >>> trial. Simplify your report design, integration and deployment - and >>> focus >>> on >>> what you do best, core application coding. Discover what's new with >>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>> _______________________________________________________ >>> Nagios Plugin Development Mailing List >>> Nagiosplug-devel at lists.sourceforge.net >>> Unsubscribe at >>> https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel >>> ::: Please include plugins version (-v) and OS when reporting any issue. >>> ::: Messages without supporting info will risk being sent to /dev/null >>> >> > From hir3npatel at gmail.com Wed Sep 2 21:32:48 2009 From: hir3npatel at gmail.com (Hiren Patel) Date: Wed, 02 Sep 2009 21:32:48 +0200 Subject: [Nagiosplug-devel] NRPE Protocol In-Reply-To: <4A422DDD.6080504@wyraz.de> References: <4A422DDD.6080504@wyraz.de> Message-ID: <4A9EC860.6020006@gmail.com> Michael Wyraz wrote: > Hi, > > because I wanted to integrate some of our own monitoring tasks to > nagios, I spent some time with the NRPE protocol. Since it's almost > impossible to find some documentation, I gathered my informations from > the source. > > Here's what I found out about it: > - any numbers are stored in big-endian notation (highest bytes first) > - a packet consists of exactly 1036 Bytes > - 2 byte integer: version of the protocol (currently 1,2,3) > - 2 byte integer: type of the packet (1=request, 2=response) > - 4 byte long integer: crc32 checksum of the message > - 2 byte integer: return code of the remote command (in requests it's > filled with a random number) > - 1024 byte data: the command or response text, filled with zero-bytes > - 2 byte of garbage: this is because the c structure is sent "as it > is" over the wire. When creating messages, it's fine to set it to zero. > - the crc32 checksum is calculated from the whole message (including the > 2 bytes of garbage). the 4 bytes reserved for the crc are set to zero > for calculation the crc. The default crc32 algorithm is used. > out of interest, where do you determine that there is 2 bytes of garbage? I've had a peak at nrpe, I don't clearly see why this is the case. regarding your suggestion on http://hessian.caucho.com/, is this not more of a web orientated protocol. what made you pick this, curious. I like your ideas around a variable length plugin output, moving the checksum to the end and HMAC. From kyleodonnell at gmail.com Thu Sep 3 16:55:18 2009 From: kyleodonnell at gmail.com (Kyle O'Donnell) Date: Thu, 3 Sep 2009 10:55:18 -0400 Subject: [Nagiosplug-devel] aix 6.1 compile? In-Reply-To: <2274b9c30909020558n71bca9cfof0a221ea22725d62@mail.gmail.com> References: <2274b9c30909010934r50da83cdn26a031c22d0e2712@mail.gmail.com> <4A9DD68D.1080307@aei.ca> <2274b9c30909011934n504a1171wc5f7affd3cca6123@mail.gmail.com> <2274b9c30909020548t6feee90dre83b5a34e3fbcc14@mail.gmail.com> <2274b9c30909020558n71bca9cfof0a221ea22725d62@mail.gmail.com> Message-ID: <2274b9c30909030755u68da45bo6f3bd9b6768337b7@mail.gmail.com> added to the exchange! http://www.monitoringexchange.org/cgi-bin/page.cgi?g=Detailed%2F3192.html;d=1 On 9/2/09, Kyle O'Donnell wrote: > --with-ps-command=/usr/sysv/bin/ps -eo 's uid pid ppid vsz rss pcpu > etime comm args' --with-ps-format=%s %d %d %d %d %d %f > %s %s %n --with-ps-cols=10 > --with-ps-varlist=procstat,&procuid,&procpid,&procppid,&procvsz,&procrss,&procpcpu,procetime,procprog,&pos > > > > On 9/2/09, Kyle O'Donnell wrote: >> http://nagiosplug.sourceforge.net/snapshot/nagios-plugins-trunk-200909021200.tar.gz >> >> worked like a charm, but the RSS still doesnt work for check_procs, >> here is the ps command I use which works for aix 5.3 as well: >> >> >> >> On 9/1/09, Kyle O'Donnell wrote: >>> I'll try both the latest and .12 Thanks! >>> If it were up to me I'd setup tinderbox, but unfortunately my employer >>> would >>> not allow it. >>> >>> I plan on posting the binaries to the nagios exchange (as I have for >>> hpux >>> and solaris). >>> >>> --kyleo >>> >>> On Tue, Sep 1, 2009 at 10:21 PM, Thomas Guyot-Sionnest >>> wrote: >>> >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> On 01/09/09 12:34 PM, Kyle O'Donnell wrote: >>>> > Hi, >>>> >>>> Hi Kyle, >>>> >>>> > Has anyone compiled the plugins (1.4.13) for AIX 6.1? I am >>>> > attempting >>>> > to, but running into some errors: >>>> >>>> While we do our best to support as many architectures as possible and >>>> had success reports from many of them, supported platforms usually >>>> boils >>>> down to whichever platforms we have access to for testing and running >>>> tinderboxes. Since it's pretty hard to get our hands on commercial >>>> Unixes like AIX support for these is unfortunately limited. >>>> >>>> > Tpo" ".deps/getloadavg.Po"; else rm -f ".deps/getloadavg.Tpo"; exit >>>> > 1; >>>> > fi >>>> > In file included from /usr/include/sys/corral.h:25, >>>> > from /usr/include/libperfstat.h:28, >>>> > from getloadavg.c:410: >>>> > /usr/include/netinet/in6_var.h:65: error: array type has incomplete >>>> element type >>>> > make: The error code from the last command is 1. >>>> >>>> This seems to be a problem with Gnulib which is a separate library >>>> incorporated into Nagiosplugins. Since we updated Gnulib in the current >>>> development branch and it contains a fix for AIX 6.1 please try the >>>> latest snapshot. >>>> >>>> If you'd prefer an old stable you could try v1.4.12... According to the >>>> changelog of getloadavg.c use of libperfstat in AIX have been added on >>>> Feb 3 2008; with v1.4.12 you will get an older version of getloadavc.c >>>> wich may (or may not) work for you. >>>> >>>> Thanks >>>> >>>> P.s. If you'd be willing to use one of your servers as a tinderbox that >>>> will help us detect any regression as soon as possible and thus help >>>> keeping your platform supported. All you need is to run one or two >>>> builds daily using a script that send results back to our central >>>> server. Please contact Ton Voon directly (and cc me) if your want help >>>> setting one up. >>>> >>>> - -- >>>> Thomas >>>> -----BEGIN PGP SIGNATURE----- >>>> Version: GnuPG v1.4.6 (GNU/Linux) >>>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >>>> >>>> iD8DBQFKndaN6dZ+Kt5BchYRAuxOAJ4ycS95TZ60Nh4z+/6/MtQcsOQm2gCfRrwb >>>> iHlfa+HLONW1uFjTFzBgssU= >>>> =kBly >>>> -----END PGP SIGNATURE----- >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >>>> 30-Day >>>> trial. Simplify your report design, integration and deployment - and >>>> focus >>>> on >>>> what you do best, core application coding. Discover what's new with >>>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>>> _______________________________________________________ >>>> Nagios Plugin Development Mailing List >>>> Nagiosplug-devel at lists.sourceforge.net >>>> Unsubscribe at >>>> https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel >>>> ::: Please include plugins version (-v) and OS when reporting any >>>> issue. >>>> ::: Messages without supporting info will risk being sent to /dev/null >>>> >>> >> > From holger at CIS.FU-Berlin.DE Fri Sep 4 13:38:12 2009 From: holger at CIS.FU-Berlin.DE (Holger =?iso-8859-1?Q?Wei=DF?=) Date: Fri, 4 Sep 2009 13:38:12 +0200 Subject: [Nagiosplug-devel] Please can I have GIT access In-Reply-To: <4A9D72C7.10806@aei.ca> References: <20090829111204.GT21433@phcomp.co.uk> <20090829161807.GF69749771@Waran.CIS.FU-Berlin.DE> <4A9D3C3E.9040506@aei.ca> <20090901183609.GW5441@phcomp.co.uk> <4A9D72C7.10806@aei.ca> Message-ID: <20090904113812.GC70048301@Waran.CIS.FU-Berlin.DE> * Thomas Guyot-Sionnest [2009-09-01 15:15]: > Alain Williams wrote: > > On Tue, Sep 01, 2009 at 12:21:28PM -0400, Max wrote: > >> Files in RAM or memcache is a lot easier to manage than shared memory. > > > > Files: > > > > * easy to set up, flexible > > * don't use up RAM - some sites RAM is precious > > * those who do want the speed of RAM, simply create a RAM disk or tmpfs and put the > > files there > > * if it is a 'disk' directory and the system is not hard pressed on RAM, the files > > end up in RAM anyway (buffer cache) Agreed. > Just for completeness the FD method uses files primarily, but it > actually gives that control to the caller. This means: > > * Plugin only cares about FD numbers to use, caller decides where data > will go. No extra work, library or complex code required in the plugins. > * If desired, caller can send FDs pointing to mmaped memory, and then > decide where to store it afterward (private RAM, SHM, memcached, SQL...) > * Any custom wrapper can be used, for any desired retention method. > * Nagios and NRPE could provide basic methods for simple setups and to > avoid an extra fork. Furthermore Nagios modules could be used to extend > Nagios functionality in an efficient manner on large sites. > > I believe this method is much closer to the Unix philosophy of having > multiple components doing simple tasks. I'd associate passing file descriptors around between every process and his dog with DJB's philosophy rather than with the Unix philosophy :-P Personally, I'd prefer not to bother the caller with this stuff. Of course, I'm fine with providing options, but I'd rather not _force_ the caller to setup storage for state retention and to play file descriptor games just to get this functionality. It's simply not his job to hold state information for the executed plugin, and I guess it would cause quite a bit of confusion (e.g., when users test plugins they use in Nagios on the command line). In general, I'd like to keep the plugin interface as simple possible. Holger From ton.voon at opsera.com Fri Sep 4 14:47:49 2009 From: ton.voon at opsera.com (Ton Voon) Date: Fri, 4 Sep 2009 13:47:49 +0100 Subject: [Nagiosplug-devel] Please can I have GIT access In-Reply-To: <20090904113812.GC70048301@Waran.CIS.FU-Berlin.DE> References: <20090829111204.GT21433@phcomp.co.uk> <20090829161807.GF69749771@Waran.CIS.FU-Berlin.DE> <4A9D3C3E.9040506@aei.ca> <20090901183609.GW5441@phcomp.co.uk> <4A9D72C7.10806@aei.ca> <20090904113812.GC70048301@Waran.CIS.FU-Berlin.DE> Message-ID: Sorry, didn't read this thread earlier. I also prefer the files option. My approach is to abstract the plugin's interface to the actual implementation, and then get the implementation working in the simplest way possible first. If it turns out to be a bottleneck, we can enhance the implementation without changes to the plugin. So I think we should have a nagios plugins library called np_write_state_data() and np_read_state_data(). What's the interface? Please help flesh this out. I'm guessing on a write you would pass: * plugin name * optional index name for the state data (eg, hostname) * time of invocation * serialized data On a read, you pass: * plugin name * optional index name You get returned (null for error): * last time * serialized data We can implement this first as writing to files. If this is a problem, we can always switch to memcache or sqllite or some other technique later. If we can agree a design, I'll be looking for someone to volunteer to write this with appropriate tests to go into core plugins code. Then we can switch any particular plugins to use this if state info is required. Ton From addw at phcomp.co.uk Fri Sep 4 15:03:42 2009 From: addw at phcomp.co.uk (Alain Williams) Date: Fri, 4 Sep 2009 14:03:42 +0100 Subject: [Nagiosplug-devel] Please can I have GIT access In-Reply-To: References: <20090829111204.GT21433@phcomp.co.uk> <20090829161807.GF69749771@Waran.CIS.FU-Berlin.DE> <4A9D3C3E.9040506@aei.ca> <20090901183609.GW5441@phcomp.co.uk> <4A9D72C7.10806@aei.ca> <20090904113812.GC70048301@Waran.CIS.FU-Berlin.DE> Message-ID: <20090904130342.GN5175@phcomp.co.uk> On Fri, Sep 04, 2009 at 01:47:49PM +0100, Ton Voon wrote: > Sorry, didn't read this thread earlier. > > I also prefer the files option. My approach is to abstract the > plugin's interface to the actual implementation, and then get the > implementation working in the simplest way possible first. If it turns > out to be a bottleneck, we can enhance the implementation without > changes to the plugin. > > So I think we should have a nagios plugins library called > np_write_state_data() and np_read_state_data(). Since I started all of this I'll do the first cut of these. I will only start of this is agreed to be the correct approach, it the work will be accepted (assuming suitable quality). > What's the interface? Please help flesh this out. I'm guessing on a > write you would pass: > * plugin name > * optional index name for the state data (eg, hostname) > * time of invocation > * serialized data > > On a read, you pass: > * plugin name > * optional index name > > You get returned (null for error): > * last time > * serialized data > > We can implement this first as writing to files. If this is a problem, > we can always switch to memcache or sqllite or some other technique > later. > > If we can agree a design, I'll be looking for someone to volunteer to > write this with appropriate tests to go into core plugins code. Then > we can switch any particular plugins to use this if state info is > required. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Past chairman of UKUUG: http://www.ukuug.org/ #include From perldork at webwizarddesign.com Fri Sep 4 15:15:05 2009 From: perldork at webwizarddesign.com (Max) Date: Fri, 4 Sep 2009 09:15:05 -0400 Subject: [Nagiosplug-devel] Please can I have GIT access In-Reply-To: References: <20090829111204.GT21433@phcomp.co.uk> <20090829161807.GF69749771@Waran.CIS.FU-Berlin.DE> <4A9D3C3E.9040506@aei.ca> <20090901183609.GW5441@phcomp.co.uk> <4A9D72C7.10806@aei.ca> <20090904113812.GC70048301@Waran.CIS.FU-Berlin.DE> Message-ID: On Fri, Sep 4, 2009 at 8:47 AM, Ton Voon wrote: > So I think we should have a nagios plugins library called > np_write_state_data() and np_read_state_data(). that sounds good. > What's the interface? Please help flesh this out. I'm guessing on a > write you would pass: > ? * plugin name > ? * optional index name for the state data (eg, hostname) > ? * time of invocation > ? * serialized data Should we pass in time or should the write_state do that for the user so plugin developers do not have to repeat passing in time every time this is called? > On a read, you pass: > ? * plugin name > ? * optional index name > > You get returned (null for error): > ? * last time > ? * serialized data Would you return the last time or the number of seconds since the last write call? Do I as a developer care about the real time or do I care about the interval between calls to write and read? My personal preference and experience with plugins is that it is the interval between calls that matters, not the absolute timestamps. > We can implement this first as writing to files. If this is a problem, > we can always switch to memcache or sqllite or some other technique > later. Would be nice to have the framework set up a well-defined interface so that multiple backends can be used ... I could see a file based default backend, but should be an easy way to add new backends for other persistent storage options. > If we can agree a design, I'll be looking for someone to volunteer to > write this with appropriate tests to go into core plugins code. Then > we can switch any particular plugins to use this if state info is > required. Nice. This sounds like a very reasonable and useful approach and very cool to see it going into the core plugin framework. - Max From dermoth at aei.ca Fri Sep 4 16:05:01 2009 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Fri, 04 Sep 2009 10:05:01 -0400 Subject: [Nagiosplug-devel] Please can I have GIT access In-Reply-To: <20090904113812.GC70048301@Waran.CIS.FU-Berlin.DE> References: <20090829111204.GT21433@phcomp.co.uk> <20090829161807.GF69749771@Waran.CIS.FU-Berlin.DE> <4A9D3C3E.9040506@aei.ca> <20090901183609.GW5441@phcomp.co.uk> <4A9D72C7.10806@aei.ca> <20090904113812.GC70048301@Waran.CIS.FU-Berlin.DE> Message-ID: <4AA11E8D.6000709@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Holger Wei? wrote: > * Thomas Guyot-Sionnest [2009-09-01 15:15]: >> Just for completeness the FD method uses files primarily, but it >> actually gives that control to the caller. This means: >> >> * Plugin only cares about FD numbers to use, caller decides where data >> will go. No extra work, library or complex code required in the plugins. >> * If desired, caller can send FDs pointing to mmaped memory, and then >> decide where to store it afterward (private RAM, SHM, memcached, SQL...) >> * Any custom wrapper can be used, for any desired retention method. >> * Nagios and NRPE could provide basic methods for simple setups and to >> avoid an extra fork. Furthermore Nagios modules could be used to extend >> Nagios functionality in an efficient manner on large sites. >> >> I believe this method is much closer to the Unix philosophy of having >> multiple components doing simple tasks. > > I'd associate passing file descriptors around between every process and > his dog with DJB's philosophy rather than with the Unix philosophy :-P Awww. I've been unmasked! ;) Well, DJB's way it pretty much the same philosophy as UNIX. > Personally, I'd prefer not to bother the caller with this stuff. Of > course, I'm fine with providing options, but I'd rather not _force_ the > caller to setup storage for state retention and to play file descriptor > games just to get this functionality. It's simply not his job to hold I don't see it as forcing the caller... It wouldn't be required unless if the plugin have to store data. Moreover it can be done with a wrapper program (or even directly trough the shell) so there's not absolute need for supporting it in the caller. > state information for the executed plugin, and I guess it would cause > quite a bit of confusion (e.g., when users test plugins they use in > Nagios on the command line). In general, I'd like to keep the plugin > interface as simple possible. The plugin can easily detect if the FH isn't open and throw an helpful error. Moreover, I believe nagios should be told explicitly to store data for a command. My though regarding this is the FH method gives a lot of flexibility (the same flexibility as using the performance data method without its downfalls), and considering that people have many different ways they may want to store data (FILE, RAM, Memcached...) that flexibility would be welcome. - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqhHo0ACgkQ6dZ+Kt5BchYyfACgu4OSjeJavlQW5/WJZjRQVr33 CV8An3/ObGscsoA7f4ow9aWPWJzPq2qs =UBvD -----END PGP SIGNATURE----- From addw at phcomp.co.uk Fri Sep 4 16:25:39 2009 From: addw at phcomp.co.uk (Alain Williams) Date: Fri, 4 Sep 2009 15:25:39 +0100 Subject: [Nagiosplug-devel] Please can I have GIT access In-Reply-To: <4AA11E8D.6000709@aei.ca> References: <20090829111204.GT21433@phcomp.co.uk> <20090829161807.GF69749771@Waran.CIS.FU-Berlin.DE> <4A9D3C3E.9040506@aei.ca> <20090901183609.GW5441@phcomp.co.uk> <4A9D72C7.10806@aei.ca> <20090904113812.GC70048301@Waran.CIS.FU-Berlin.DE> <4AA11E8D.6000709@aei.ca> Message-ID: <20090904142539.GS5175@phcomp.co.uk> On Fri, Sep 04, 2009 at 10:05:01AM -0400, Thomas Guyot-Sionnest wrote: > The plugin can easily detect if the FH isn't open and throw an helpful > error. Moreover, I believe nagios should be told explicitly to store > data for a command. Nooooo! This is an invitation to errors. What you are suggesting is that the plugin is to expect FD 3 to be open and use it to read/write data from (or was it FD 3 to read, FD 4 to write?). The problem is that the plugin can't really tell what the FD is connected to. So: when[**] the plugin is invoked and FD 3 is open on something else that got inherited (some bug in the shell, login, sudo, ... left it open on /etc/passwd) and it just uses it .... you have a disaster. Also: I don't about you, but when playing with a new plugin I run it a few times by hand from the shell. It is much more difficult to have the FDs open as opposed to a --statefile=/xxxx option. [**] - when, not if. It might be a long time, but it will happen at some point. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Past chairman of UKUUG: http://www.ukuug.org/ #include From addw at phcomp.co.uk Fri Sep 4 15:34:50 2009 From: addw at phcomp.co.uk (Alain Williams) Date: Fri, 4 Sep 2009 14:34:50 +0100 Subject: [Nagiosplug-devel] Please can I have GIT access In-Reply-To: References: <20090829111204.GT21433@phcomp.co.uk> <20090829161807.GF69749771@Waran.CIS.FU-Berlin.DE> <4A9D3C3E.9040506@aei.ca> <20090901183609.GW5441@phcomp.co.uk> <4A9D72C7.10806@aei.ca> <20090904113812.GC70048301@Waran.CIS.FU-Berlin.DE> Message-ID: <20090904133450.GP5175@phcomp.co.uk> On Fri, Sep 04, 2009 at 09:15:05AM -0400, Max wrote: > On Fri, Sep 4, 2009 at 8:47 AM, Ton Voon wrote: > > So I think we should have a nagios plugins library called > > np_write_state_data() and np_read_state_data(). > > that sounds good. > > > What's the interface? Please help flesh this out. I'm guessing on a > > write you would pass: > > ? * plugin name > > ? * optional index name for the state data (eg, hostname) > > ? * time of invocation > > ? * serialized data We need a plugin_version number, since after upgrading a plugin the serialised data might have changed. Perhaps this should be serialised_data_format_version. Hmmm, I thought that I understood what that meant until I wondered how to use it. You might need to consider that a plugin might be run several times on the same machine - so what does 'index name' mean ? check_procs can want to store about a process: pid ppid name MS secs where M is is the Metric (eg CPU%, virtual memory size, ...) S is the state (Critical or Warning) It might have a Critical AND a Warning record for any particular process. What I would like is to store/retrieve a blob (serialised string) that I can then unserialise to my taste. It might be nice to provide serialisation routines, this might be hard to generalise. > Should we pass in time or should the write_state do that for the user > so plugin developers do not have to repeat passing in time every time > this is called? > > > On a read, you pass: > > ? * plugin name > > ? * optional index name > > > > You get returned (null for error): > > ? * last time > > ? * serialized data > > Would you return the last time or the number of seconds since the last > write call? Do I as a developer care about the real time or do I care > about the interval between calls to write and read? My personal > preference and experience with plugins is that it is the interval > between calls that matters, not the absolute timestamps. In the case of my patch to check_procs what I am interested is the absolute timestamp -- I want to know how long a process has been in a particular state. I suspect that what this shows is that different plugins will want different things. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Past chairman of UKUUG: http://www.ukuug.org/ #include From dermoth at aei.ca Fri Sep 4 16:32:48 2009 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Fri, 04 Sep 2009 10:32:48 -0400 Subject: [Nagiosplug-devel] Please can I have GIT access In-Reply-To: References: <20090829111204.GT21433@phcomp.co.uk> <20090829161807.GF69749771@Waran.CIS.FU-Berlin.DE> <4A9D3C3E.9040506@aei.ca> <20090901183609.GW5441@phcomp.co.uk> <4A9D72C7.10806@aei.ca> <20090904113812.GC70048301@Waran.CIS.FU-Berlin.DE> Message-ID: <4AA12510.7060408@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ton Voon wrote: > Sorry, didn't read this thread earlier. > > I also prefer the files option. My approach is to abstract the > plugin's interface to the actual implementation, and then get the > implementation working in the simplest way possible first. If it turns > out to be a bottleneck, we can enhance the implementation without > changes to the plugin. > > So I think we should have a nagios plugins library called > np_write_state_data() and np_read_state_data(). > > What's the interface? Please help flesh this out. I'm guessing on a > write you would pass: > * plugin name > * optional index name for the state data (eg, hostname) > * time of invocation > * serialized data > > On a read, you pass: > * plugin name > * optional index name > > You get returned (null for error): > * last time > * serialized data That sounds pretty good, and so far you did not specify any storage methos so it's totally abstracted from the plugin. > We can implement this first as writing to files. If this is a problem, > we can always switch to memcache or sqllite or some other technique > later. And that's where my view differs. If we implement the actual storage method in the plugins library then any new storage method will require modifying the code. It will also require to be coded in each of the languages plugins are written in (perl, c...). OTOH the functions above could read/write filehandles and a wrapper would take care of the rest. We'd provide at least one of them (e.g. files) and anyone could contribute other kind of wrappers. Nagios and NRPE could also eventually provide directly the storage for simplicity. Furthermore Nagios could allow modules to override plugin storage so efficient methods could be plugged in directly. My approach also allow writing wrappers in any language, even a few lines of shell code can do the trick. If someone needs Yet Another Storage Method(tm) he doesn't have to actually know C and perl, nor do he has to modify any of the plugin code. He just has to place his own wrapper in between and he's done. > If we can agree a design, I'll be looking for someone to volunteer to > write this with appropriate tests to go into core plugins code. Then > we can switch any particular plugins to use this if state info is > required. Let's not forget I also wrote the code for parsing performance data strings... This method is valid and already working in my snmp_counters_new branch. With Nagios v3 extended output could also be used to extend performance data length beyond usual limits. - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqhJRAACgkQ6dZ+Kt5BchYFBACgjBDhYxmVq+7tR8wCixjJHRr2 YLsAmgKDRM0X2v1Aw5w+hmPbiTm5CdO/ =+G3p -----END PGP SIGNATURE----- From ton.voon at opsera.com Fri Sep 4 16:38:22 2009 From: ton.voon at opsera.com (Ton Voon) Date: Fri, 4 Sep 2009 15:38:22 +0100 Subject: [Nagiosplug-devel] Please can I have GIT access In-Reply-To: <20090904133450.GP5175@phcomp.co.uk> References: <20090829111204.GT21433@phcomp.co.uk> <20090829161807.GF69749771@Waran.CIS.FU-Berlin.DE> <4A9D3C3E.9040506@aei.ca> <20090901183609.GW5441@phcomp.co.uk> <4A9D72C7.10806@aei.ca> <20090904113812.GC70048301@Waran.CIS.FU-Berlin.DE> <20090904133450.GP5175@phcomp.co.uk> Message-ID: <8866A548-559E-4E9F-9161-C4DDC4E336D0@opsera.com> On 4 Sep 2009, at 14:34, Alain Williams wrote: > On Fri, Sep 04, 2009 at 09:15:05AM -0400, Max wrote: >> On Fri, Sep 4, 2009 at 8:47 AM, Ton Voon wrote: >>> So I think we should have a nagios plugins library called >>> np_write_state_data() and np_read_state_data(). >> >> that sounds good. >> >>> What's the interface? Please help flesh this out. I'm guessing on a >>> write you would pass: >>> * plugin name >>> * optional index name for the state data (eg, hostname) >>> * time of invocation >>> * serialized data > > We need a plugin_version number, since after upgrading a plugin the > serialised > data might have changed. Perhaps this should be > serialised_data_format_version. I can see that. I've written something that caches data and that uses a version number. We found structural changes incurred a version difference, which means the old cache is considered unreliable. So I agree with adding version in. > > Hmmm, I thought that I understood what that meant until I wondered > how to use it. > You might need to consider that a plugin might be run several times > on the same > machine - so what does 'index name' mean ? The index allows configuration to be stored "alongside" other cache data. Consider this: you are running on a Nagios server and you want to save the last in/out bits for an interface. The cache data is not separated by plugin name (same plugin for different hosts), and these could be invoked simultaneously. So the index name is a separator where the data should not clash. > check_procs can want to store about a process: > pid ppid name MS secs > where M is is the Metric (eg CPU%, virtual memory size, ...) > S is the state (Critical or Warning) > It might have a Critical AND a Warning record for any particular > process. > > What I would like is to store/retrieve a blob (serialised string) > that I can > then unserialise to my taste. It might be nice to provide > serialisation routines, > this might be hard to generalise. I can picture how this works in perl, but I don't really know about C. (Can I get any arbitrary data structure back?) > >> Should we pass in time or should the write_state do that for the user >> so plugin developers do not have to repeat passing in time every time >> this is called? That's a fair point. There might be a difference between "plugin invoke time" and "write to cache file time", but if you are saying that is not necessary, then we'll remove that requirement. >> >>> On a read, you pass: >>> * plugin name >>> * optional index name >>> >>> You get returned (null for error): >>> * last time >>> * serialized data >> >> Would you return the last time or the number of seconds since the >> last >> write call? Do I as a developer care about the real time or do I >> care >> about the interval between calls to write and read? My personal >> preference and experience with plugins is that it is the interval >> between calls that matters, not the absolute timestamps. > > In the case of my patch to check_procs what I am interested is the > absolute > timestamp -- I want to know how long a process has been in a > particular state. > I suspect that what this shows is that different plugins will want > different > things. I think we should have absolute timestamp, because you can then calculate the difference. Ton -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlmartinez-lists-nagplug-devel at capside.com Fri Sep 4 16:41:44 2009 From: jlmartinez-lists-nagplug-devel at capside.com (Jose Luis Martinez) Date: Fri, 04 Sep 2009 16:41:44 +0200 Subject: [Nagiosplug-devel] Please can I have GIT access In-Reply-To: References: <20090829111204.GT21433@phcomp.co.uk> <20090829161807.GF69749771@Waran.CIS.FU-Berlin.DE> <4A9D3C3E.9040506@aei.ca> <20090901183609.GW5441@phcomp.co.uk> <4A9D72C7.10806@aei.ca> <20090904113812.GC70048301@Waran.CIS.FU-Berlin.DE> Message-ID: <4AA12728.50107@capside.com> Hi, I wrote a mini-module for doing the same in Perl plugins. Haven't CPANned it yet, so take this as a call for community revision. It's called Nagios::Plugin::Differences, and I'll discuss the design so that maybe you can lift some ideas for the C API, or that my module gets benefitted from the discussion in place. - Each plugin is responsable for it's storage. I don't like FD passing either. - The serializer is the Perl Storable class. Well-proven, and core module. I use the lock_store method to serialize data to the files (so appropiate locks get placed). There are not methods in place to change storage type, but it can be done via subclassing (overriding persist and load_last). - The temporary file is defaulted to '/tmp/_nagios_plugin_%s.tmp', where %s is the filename name of the plugin when the object gets constructed. - It's plugins responsibility to choose a different temp file if it's anticipated there will be temporary file collisions. For example: "check_disk_io --dev sda" and "check_disk_io --dev sdb", being executed on the same machine will pick up one anothers temp file. They would have to construct the Nagios::Plugin::Differences object requesting a tempfile like /tmp/_nagios_plugin_check_disk_io_sda.tmp and /tmp/_nagios_plugin_check_disk_io_sdb.tmp. - The method for persisting data automatically adds the timestamp to the reading, you can override it if you want. - There are helper methods for doing the "dirty" work of calculating differences and rates between now and the last reading. - Plugins with incompatible datastructures in different versions can be detected with the plugin just storing 'struct_version' as one of the values to be persisted and taking appropiate action (up to the plugin). I attach the pm file so you can inspect it (also, if you wan't I can attach test files too). I'm open to feedback, corrections and discussion. Please don't use or publish a plugin that uses this module until it's CPANned, as the API is open to change. Just my 2 cents, Jose Luis Martinez jlmartinez at capside.com -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Differences.pm URL: From dermoth at aei.ca Fri Sep 4 16:43:10 2009 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Fri, 04 Sep 2009 10:43:10 -0400 Subject: [Nagiosplug-devel] Please can I have GIT access In-Reply-To: <20090904142539.GS5175@phcomp.co.uk> References: <20090829111204.GT21433@phcomp.co.uk> <20090829161807.GF69749771@Waran.CIS.FU-Berlin.DE> <4A9D3C3E.9040506@aei.ca> <20090901183609.GW5441@phcomp.co.uk> <4A9D72C7.10806@aei.ca> <20090904113812.GC70048301@Waran.CIS.FU-Berlin.DE> <4AA11E8D.6000709@aei.ca> <20090904142539.GS5175@phcomp.co.uk> Message-ID: <4AA1277E.1020304@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alain Williams wrote: > On Fri, Sep 04, 2009 at 10:05:01AM -0400, Thomas Guyot-Sionnest wrote: > >> The plugin can easily detect if the FH isn't open and throw an helpful >> error. Moreover, I believe nagios should be told explicitly to store >> data for a command. > > Nooooo! This is an invitation to errors. > What you are suggesting is that the plugin is to expect FD 3 to be open > and use it to read/write data from (or was it FD 3 to read, FD 4 to write?). > > The problem is that the plugin can't really tell what the FD is connected to. > So: when[**] the plugin is invoked and FD 3 is open on something else that > got inherited (some bug in the shell, login, sudo, ... left it open on /etc/passwd) > and it just uses it .... you have a disaster. Still that is a bug. And if a simple plugin end up clobbering /etc/passwd (or anything similar), you have a way bigger issue because: 1. The FH should have been opened read-only unless for writing (in the latter case is should have been closed promptly too). 2. The plugin shouldn't be running as root > Also: I don't about you, but when playing with a new plugin I run it a few > times by hand from the shell. It is much more difficult to have the > FDs open as opposed to a --statefile=/xxxx option. Have you seen my first example? touch file; ./check_stuff 3file.new; mv file.new file And as I keep saying a wrapper program would be provided too. - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqhJ34ACgkQ6dZ+Kt5BchatYgCcDShmQ1hwPGqbUko24fBiehn3 In8AoLYGjL/1AV+Szx/5YvIAfeBl8PhO =hsWb -----END PGP SIGNATURE----- From joop3 at gmx.net Fri Sep 4 16:46:41 2009 From: joop3 at gmx.net (Roy Hogervorst) Date: Fri, 4 Sep 2009 16:46:41 +0200 Subject: [Nagiosplug-devel] unsubscribe In-Reply-To: <4AA12728.50107@capside.com> References: <20090829111204.GT21433@phcomp.co.uk> <20090829161807.GF69749771@Waran.CIS.FU-Berlin.DE> <4A9D3C3E.9040506@aei.ca> <20090901183609.GW5441@phcomp.co.uk> <4A9D72C7.10806@aei.ca> <20090904113812.GC70048301@Waran.CIS.FU-Berlin.DE> <4AA12728.50107@capside.com> Message-ID: <6C7C2AB1-BA83-40AB-A08A-8DAB96669667@gmx.net> On 4 sep 2009, at 16:41, Jose Luis Martinez wrote: > Hi, > > I wrote a mini-module for doing the same in Perl plugins. Haven't > CPANned it yet, so take this as a call for community revision. > > It's called Nagios::Plugin::Differences, and I'll discuss the design > so that maybe you can lift some ideas for the C API, or that my module > gets benefitted from the discussion in place. > > - Each plugin is responsable for it's storage. I don't like FD > passing > either. > > - The serializer is the Perl Storable class. Well-proven, and core > module. I use the lock_store method to serialize data to the files (so > appropiate locks get placed). There are not methods in place to change > storage type, but it can be done via subclassing (overriding persist > and > load_last). > > - The temporary file is defaulted to '/tmp/_nagios_plugin_%s.tmp', > where %s is the filename name of the plugin when the object gets > constructed. > > - It's plugins responsibility to choose a different temp file if it's > anticipated there will be temporary file collisions. For example: > > "check_disk_io --dev sda" and "check_disk_io --dev sdb", being > executed > on the same machine will pick up one anothers temp file. They would > have > to construct the Nagios::Plugin::Differences object requesting a > tempfile like /tmp/_nagios_plugin_check_disk_io_sda.tmp and > /tmp/_nagios_plugin_check_disk_io_sdb.tmp. > > - The method for persisting data automatically adds the timestamp to > the reading, you can override it if you want. > > - There are helper methods for doing the "dirty" work of calculating > differences and rates between now and the last reading. > > - Plugins with incompatible datastructures in different versions can > be detected with the plugin just storing 'struct_version' as one of > the > values to be persisted and taking appropiate action (up to the > plugin). > > I attach the pm file so you can inspect it (also, if you wan't I can > attach test files too). I'm open to feedback, corrections and > discussion. Please don't use or publish a plugin that uses this module > until it's CPANned, as the API is open to change. > > Just my 2 cents, > > Jose Luis Martinez > jlmartinez at capside.com > > package Nagios::Plugin::Differences; > > use strict; > no warnings; > > use Carp; > use File::Basename qw//; > use Storable qw//; > > =head1 NAME > > Nagios::Plugin::Differences - Module to streamline Nagios plugins > that need to store temporary data and calculate the differences > between the readings. > > =head1 VERSION > > Version 0.01 > > =cut > > our $VERSION = '0.01'; > > =head1 SYNOPSIS > > This module is useful for when there is need to store a set of values > that need to be reread at the next invocation of the plugin. It > provides > a set of functions to calculate the differences between the readings. > > use Nagios::Plugin::Differences; > > my $npd = Nagios::Plugin::Differences->new(); > $npd->load_last; > # suppose last reading was > # { 'bytes' => 200, 'packets' => 3 } > # at time 1234567890 > $npd->new_reading({ > 'bytes' => 500 > 'packets' => 6 > }); > # new reading is at time 123456900 > $npd->persist; > my $rate = $npd->rate('difference'); > # rate returns the bytes/s and the packets/s that had to be > # attained to get from the last reading to the new reading > # in the time passed between readings > # { 'bytes' => 30, > # 'packets' => 0.3 } > > =head1 FUNCTIONS > > =head2 new(%options) > > Constructor for the Nagios::Plugin::Differences object. You > can pass 'file' => '/tmp/xxx' to override the default file > ('/tmp/_nagios_plugin_$0.tmp'). > > =cut > > sub new { > my ($class, %options) = @_; > > my $self = { 'file' => sprintf("/tmp/_nagios_plugin_%s.tmp", > File::Basename::basename($0)), > %options }; > bless $self, $class; > } > > =head2 new_reading($data, [$ts]) > > Report a new reading. The reading has to be a hashref. You can > optionally > pass the timestamp for the reading. If you don't pass $ts, the > timestamp > of the invocation of the method will be used. > > =cut > > sub new_reading { > my ($self, $data, $ts) = @_; > croak "cannot store non-hashref data" if (ref($data) ne 'HASH'); > $ts = time() if (not defined $ts); > > $self->{'last'} = $self->{'current'} if (defined $self- > >{'current'}); > $self->{'current'} = { 'ts' => $ts, 'data' => $data }; > } > > =head2 persist([$file]) > > Write the stored data to the temporary file > > =cut > > sub persist { > my ($self, $file) = @_; > $file ||= $self->{'file'}; > Storable::lock_store($self->{'current'}, $file); > } > > =head2 load_last([$file]) > > Load the last reading from the temporary file. > > =cut > > sub load_last { > my ($self, $file) = @_; > $file ||= $self->{'file'}; > $self->{'last'} = $self->{'current'} if (defined $self- > >{'current'}); > $self->{'current'} = Storable::retrieve($file); > } > > > #head2 difference_from_zero > # > #Calculate the difference between current and zero. > # > #cut > # > #sub difference_from_zero { > # my ($self) = @_; > # return ($self->{'current'}->{'data'}); > #} > > =head1 CALCULATING DIFFERENCES > > =head2 difference > > Calculates the difference between current reading and last reading. > > =cut > > sub difference { > my ($self) = @_; > > die 'no new_reading' if (not defined $self->{'current'}); > die 'no last' if (not defined $self->{'last'}); > > my $current_data = $self->{'current'}->{'data'}; > my $last_data = $self->{'last'}->{'data'}; > my $delta = {}; > > foreach my $item (keys %$last_data){ > # if we don't have item, $data_last->{ xxx } will be undef. > The correct reading would be zero > $delta->{ $item } = $current_data->{ $item } - ($last_data- > >{ $item } || 0); > } > return ($delta); > } > > =head2 forward_difference($wrap_at) > > =cut > > sub forward_difference { > my ($self, $wrap_at) = @_; > > die 'no new_reading' if (not defined $self->{'current'}); > die 'no last' if (not defined $self->{'last'}); > > my $current_data = $self->{'current'}->{'data'}; > my $last_data = $self->{'last'}->{'data'}; > my $delta = {}; > > foreach my $item (keys %$last_data){ > if ($current_data->{ $item } >= $last_data->{ $item }){ > $delta->{ $item } = $current_data->{ $item } - > ($last_data->{ $item } || 0); > } else { > # If the current reading is smaller than the last time we > saw it, then we have to > # take into account the wrap value. > # time |=======|------------|===========| > # 0 current last wrap > $delta->{ $item } = ($wrap_at - $last_data->{ $item }) + > $current_data->{ $item }; > } > } > return ($delta); > } > > =head2 forward_difference_unknown_wrap > > If the value of a key from the current reading is less than the last > reading, the > difference will be taken from zero. This is handy when you are > storing counters > that increment, but can be reset to zero. > > =cut > > sub forward_difference_unknown_wrap { > my ($self) = @_; > > die 'no new_reading' if (not defined $self->{'current'}); > die 'no last' if (not defined $self->{'last'}); > > my $current_data = $self->{'current'}->{'data'}; > my $last_data = $self->{'last'}->{'data'}; > my $delta = {}; > > foreach my $item (keys %$last_data){ > if ($current_data->{ $item } >= $last_data->{ $item }){ > $delta->{ $item } = $current_data->{ $item } - > ($last_data->{ $item } || 0); > } else { > # If the current reading is smaller than the last time we > saw it, then we have to > # discard the last reading. The counter has been reset, > and we cannot know what > # happened between the last reading and the current one. > # time |=======|------------|???????.... > # current last > $delta->{ $item } = $current_data->{ $item }; > } > } > return ($delta); > } > > =head2 rate($method, [params_to_method]) > > Calculate the rate of change (derive) between the current reading > and the last reading. > To calculate rate of change, you need to calculate the change. The > change gets calculated > with any of the "difference" methods > > $npd->rate('difference'); > > $npd->rate('forward_difference', 1000); > > $npd->rate('forward_difference_unknown_wrap'); > > =cut > > sub rate { > my ($self, $method, @params_to_method) = @_; > > my $delta = $self->$method(@params_to_method); > my $time = $self->{'current'}->{'ts'} - $self->{'last'}->{'ts'}; > > my $rates = {}; > foreach my $item (keys %$delta){ > $rates->{$item} = $delta->{$item} / $time; > } > > return $rates; > } > > =head2 proportion( > > Calculate the proportions of the values of one key respect to the > total sum of all the values. > > proportion({ 'red' => 5, 'green' => 15 }); > # returns: { 'red' => 0.25, 'green' => 0.75 } > > =cut > > sub proportion { > my ($self, $hashref) = @_; > > my $total = 0; > map { $total += $_ } values %$hashref; > > my $proportion = {}; > foreach my $item (keys %$hashref){ > $proportion->{$item} = $hashref->{$item} / $total; > } > return($proportion); > } > > 1; > > > =head1 AUTHOR > > JLMARTIN, C<< >> > > =head1 BUGS > > Please report any bugs or feature requests to C differences at rt.cpan.org>, or through > the web interface at L >. I will be notified, and then you'll automatically be notified of > progress on your bug as I make changes. > > =head1 SUPPORT > > You can find documentation for this module with the perldoc command. > > perldoc Nagios::Plugin::Differences > > You can also look for information at: > > =over 4 > > =item * RT: CPAN's request tracker > > L > > =item * AnnoCPAN: Annotated CPAN documentation > > L > > =item * CPAN Ratings > > L > > =item * Search CPAN > > L > > =back > > =head1 ACKNOWLEDGEMENTS > > =head1 COPYRIGHT & LICENSE > > Copyright 2009 Jose Luis Martinez Torres, all rights reserved. > > This program is free software; you can redistribute it and/or modify > it > under the same terms as Perl itself. > > > =cut > > 1; # End of Nagios::Plugin::Differences > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > trial. Simplify your report design, integration and deployment - and > focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july_______________________________________________________ > Nagios Plugin Development Mailing List Nagiosplug-devel at lists.sourceforge.net > Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any > issue. > ::: Messages without supporting info will risk being sent to /dev/null From addw at phcomp.co.uk Fri Sep 4 16:54:05 2009 From: addw at phcomp.co.uk (Alain Williams) Date: Fri, 4 Sep 2009 15:54:05 +0100 Subject: [Nagiosplug-devel] Please can I have GIT access In-Reply-To: <8866A548-559E-4E9F-9161-C4DDC4E336D0@opsera.com> References: <20090829161807.GF69749771@Waran.CIS.FU-Berlin.DE> <4A9D3C3E.9040506@aei.ca> <20090901183609.GW5441@phcomp.co.uk> <4A9D72C7.10806@aei.ca> <20090904113812.GC70048301@Waran.CIS.FU-Berlin.DE> <20090904133450.GP5175@phcomp.co.uk> <8866A548-559E-4E9F-9161-C4DDC4E336D0@opsera.com> Message-ID: <20090904145405.GV5175@phcomp.co.uk> On Fri, Sep 04, 2009 at 03:38:22PM +0100, Ton Voon wrote: > >What I would like is to store/retrieve a blob (serialised string) > >that I can > >then unserialise to my taste. It might be nice to provide > >serialisation routines, > >this might be hard to generalise. > > I can picture how this works in perl, but I don't really know about C. > (Can I get any arbitrary data structure back?) Not unless you are told something about it -- ie you can't (as you can in Perl) ask to see what the struct members are. All that you would prob have is it's address, not even its size. If you had a generic routine you would need to (for instance) give it an array to describe each member of the struct. The array itself would be an array of [a different] struct that contained, for each member: its offset, its type and perhaps a name. In fact it isn't hard to do. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Past chairman of UKUUG: http://www.ukuug.org/ #include From ton.voon at opsera.com Fri Sep 4 16:59:44 2009 From: ton.voon at opsera.com (Ton Voon) Date: Fri, 4 Sep 2009 15:59:44 +0100 Subject: [Nagiosplug-devel] Please can I have GIT access In-Reply-To: <4AA12510.7060408@aei.ca> References: <20090829111204.GT21433@phcomp.co.uk> <20090829161807.GF69749771@Waran.CIS.FU-Berlin.DE> <4A9D3C3E.9040506@aei.ca> <20090901183609.GW5441@phcomp.co.uk> <4A9D72C7.10806@aei.ca> <20090904113812.GC70048301@Waran.CIS.FU-Berlin.DE> <4AA12510.7060408@aei.ca> Message-ID: <8C7B8BBE-29B8-43B4-A72F-711381E28A16@opsera.com> On 4 Sep 2009, at 15:32, Thomas Guyot-Sionnest wrote: > >> If we can agree a design, I'll be looking for someone to volunteer to >> write this with appropriate tests to go into core plugins code. Then >> we can switch any particular plugins to use this if state info is >> required. > > Let's not forget I also wrote the code for parsing performance data > strings... This method is valid and already working in my > snmp_counters_new branch. With Nagios v3 extended output could also be > used to extend performance data length beyond usual limits. I think I was the one pushing you for this, but you can't pass the Nagios envvars through NRPE (nor check_by_ssh). So I think local storage is the best answer. Ton From perldork at webwizarddesign.com Fri Sep 4 17:03:02 2009 From: perldork at webwizarddesign.com (Max) Date: Fri, 4 Sep 2009 11:03:02 -0400 Subject: [Nagiosplug-devel] Please can I have GIT access In-Reply-To: <20090904145405.GV5175@phcomp.co.uk> References: <20090829161807.GF69749771@Waran.CIS.FU-Berlin.DE> <20090901183609.GW5441@phcomp.co.uk> <4A9D72C7.10806@aei.ca> <20090904113812.GC70048301@Waran.CIS.FU-Berlin.DE> <20090904133450.GP5175@phcomp.co.uk> <8866A548-559E-4E9F-9161-C4DDC4E336D0@opsera.com> <20090904145405.GV5175@phcomp.co.uk> Message-ID: On Fri, Sep 4, 2009 at 10:54 AM, Alain Williams wrote: > Not unless you are told something about it -- ie you can't (as you can in Perl) > ask to see what the struct members are. All that you would prob have is it's > address, not even its size. If you had a generic routine you would need to > (for instance) give it an array to describe each member of the struct. > The array itself would be an array of [a different] struct that contained, for > each member: its offset, its type and perhaps a name. In fact it isn't hard to do. If we want cross language serialization, we could use a portable compact format like JSON for serialization .. if a standard matters for this part of the state. A next step with storing state would be to be able to have a plugin request N calls be stored in order to be able to do rising and falling alarms :). That is a feature I see users of our Nagios instances request as we have developed a more stable infrastructure. Like the Nagios::Plugin::Differences module had code for that was posted, rate alarms are useful as well and the state mechanism could also be used (maybe a v2 of the interface) as a LIFO fixed sized buffer for doing this .. so a plugin author could request that the last 4 samples are stored so that rate-based alarming can be done. From addw at phcomp.co.uk Fri Sep 4 17:18:11 2009 From: addw at phcomp.co.uk (Alain Williams) Date: Fri, 4 Sep 2009 16:18:11 +0100 Subject: [Nagiosplug-devel] Please can I have GIT access In-Reply-To: References: <20090901183609.GW5441@phcomp.co.uk> <4A9D72C7.10806@aei.ca> <20090904113812.GC70048301@Waran.CIS.FU-Berlin.DE> <20090904133450.GP5175@phcomp.co.uk> <8866A548-559E-4E9F-9161-C4DDC4E336D0@opsera.com> <20090904145405.GV5175@phcomp.co.uk> Message-ID: <20090904151811.GZ5175@phcomp.co.uk> On Fri, Sep 04, 2009 at 11:03:02AM -0400, Max wrote: > On Fri, Sep 4, 2009 at 10:54 AM, Alain Williams wrote: > > > Not unless you are told something about it -- ie you can't (as you can in Perl) > > ask to see what the struct members are. All that you would prob have is it's > > address, not even its size. If you had a generic routine you would need to > > (for instance) give it an array to describe each member of the struct. > > The array itself would be an array of [a different] struct that contained, for > > each member: its offset, its type and perhaps a name. In fact it isn't hard to do. > > If we want cross language serialization, we could use a portable > compact format like JSON for serialization .. if a standard matters > for this part of the state. I don't think that you do need cross language serialisation. The state data from plugin X is only going to be read by plugin X. Every language will need serialisation, but you don't need to be able to read something written in another language. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Past chairman of UKUUG: http://www.ukuug.org/ #include From jlmartinez-lists-nagplug-devel at capside.com Fri Sep 4 17:35:48 2009 From: jlmartinez-lists-nagplug-devel at capside.com (Jose Luis Martinez) Date: Fri, 04 Sep 2009 17:35:48 +0200 Subject: [Nagiosplug-devel] Please can I have GIT access In-Reply-To: <20090904151811.GZ5175@phcomp.co.uk> References: <20090901183609.GW5441@phcomp.co.uk> <4A9D72C7.10806@aei.ca> <20090904113812.GC70048301@Waran.CIS.FU-Berlin.DE> <20090904133450.GP5175@phcomp.co.uk> <8866A548-559E-4E9F-9161-C4DDC4E336D0@opsera.com> <20090904145405.GV5175@phcomp.co.uk> <20090904151811.GZ5175@phcomp.co.uk> Message-ID: <4AA133D4.6020206@capside.com> Alain Williams escribi?: > I don't think that you do need cross language serialisation. The state > data from plugin X is only going to be read by plugin X. > Every language will need serialisation, but you don't need to be able to > read something written in another language. > -1 for cross-language serialization. I don't think it's needed either :) Jose Luis Martinez jlmartinez at capside.com From perldork at webwizarddesign.com Fri Sep 4 17:45:08 2009 From: perldork at webwizarddesign.com (Max) Date: Fri, 4 Sep 2009 11:45:08 -0400 Subject: [Nagiosplug-devel] unsubscribe In-Reply-To: <6C7C2AB1-BA83-40AB-A08A-8DAB96669667@gmx.net> References: <20090829111204.GT21433@phcomp.co.uk> <4A9D3C3E.9040506@aei.ca> <20090901183609.GW5441@phcomp.co.uk> <4A9D72C7.10806@aei.ca> <20090904113812.GC70048301@Waran.CIS.FU-Berlin.DE> <4AA12728.50107@capside.com> <6C7C2AB1-BA83-40AB-A08A-8DAB96669667@gmx.net> Message-ID: Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel From nagios at babar.us Fri Sep 4 17:53:44 2009 From: nagios at babar.us (Olivier 'Babar' Raginel) Date: Fri, 4 Sep 2009 17:53:44 +0200 Subject: [Nagiosplug-devel] unsubscribe In-Reply-To: References: <4A9D3C3E.9040506@aei.ca> <20090901183609.GW5441@phcomp.co.uk> <4A9D72C7.10806@aei.ca> <20090904113812.GC70048301@Waran.CIS.FU-Berlin.DE> <4AA12728.50107@capside.com> <6C7C2AB1-BA83-40AB-A08A-8DAB96669667@gmx.net> Message-ID: <20090904155344.GA19960@mail.babar.us> On Fri, Sep 04, 2009 at 11:45:08AM -0400, Max wrote: > Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel As this is written in the headers of all and every mails, I wonder how people can still send unsubscribe mails and make a fool of themselves. -- Babar. From joop3 at gmx.net Fri Sep 4 18:09:42 2009 From: joop3 at gmx.net (Roy Hogervorst) Date: Fri, 4 Sep 2009 18:09:42 +0200 Subject: [Nagiosplug-devel] unsubscribe In-Reply-To: <20090904155344.GA19960@mail.babar.us> References: <4A9D3C3E.9040506@aei.ca> <20090901183609.GW5441@phcomp.co.uk> <4A9D72C7.10806@aei.ca> <20090904113812.GC70048301@Waran.CIS.FU-Berlin.DE> <4AA12728.50107@capside.com> <6C7C2AB1-BA83-40AB-A08A-8DAB96669667@gmx.net> <20090904155344.GA19960@mail.babar.us> Message-ID: <346BF20D-7F47-4DC1-A59F-392F36DCBE23@gmx.net> All, Sorry for making a mess, was not my intention. Joop3 On 4 sep 2009, at 17:53, Olivier 'Babar' Raginel wrote: > On Fri, Sep 04, 2009 at 11:45:08AM -0400, Max wrote: >> Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > > As this is written in the headers of all and every mails, I wonder how > people can still send unsubscribe mails and make a fool of themselves. > > -- > Babar. > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > trial. Simplify your report design, integration and deployment - and > focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________________ > Nagios Plugin Development Mailing List Nagiosplug-devel at lists.sourceforge.net > Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any > issue. > ::: Messages without supporting info will risk being sent to /dev/null From dermoth at aei.ca Fri Sep 4 18:32:09 2009 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Fri, 04 Sep 2009 12:32:09 -0400 Subject: [Nagiosplug-devel] Please can I have GIT access In-Reply-To: <8C7B8BBE-29B8-43B4-A72F-711381E28A16@opsera.com> References: <20090829111204.GT21433@phcomp.co.uk> <20090829161807.GF69749771@Waran.CIS.FU-Berlin.DE> <4A9D3C3E.9040506@aei.ca> <20090901183609.GW5441@phcomp.co.uk> <4A9D72C7.10806@aei.ca> <20090904113812.GC70048301@Waran.CIS.FU-Berlin.DE> <4AA12510.7060408@aei.ca> <8C7B8BBE-29B8-43B4-A72F-711381E28A16@opsera.com> Message-ID: <4AA14109.4030603@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ton Voon wrote: > On 4 Sep 2009, at 15:32, Thomas Guyot-Sionnest wrote: > >>> If we can agree a design, I'll be looking for someone to volunteer to >>> write this with appropriate tests to go into core plugins code. Then >>> we can switch any particular plugins to use this if state info is >>> required. >> Let's not forget I also wrote the code for parsing performance data >> strings... This method is valid and already working in my >> snmp_counters_new branch. With Nagios v3 extended output could also be >> used to extend performance data length beyond usual limits. > > I think I was the one pushing you for this, but you can't pass the > Nagios envvars through NRPE (nor check_by_ssh). So I think local > storage is the best answer. Arguments would work though... Would need NRPE to support safe ways of passing them though! That seems like a trivial change but would disable shell metachars in commands... I'd do it as a separate command type, and I'd do the dame for Nagios too - it would make some things a lot simpler :) Next-gen NRPE could proxy environment and/or FH too - just FYI since no one like these methods so far :( Also, one more thing to consider with local storage is when you have multiple nagios instances - either part of distributed monitoring, migrations of just for testing. In many case data accuracy rely on the fact the the same data is relative to the last check. If you have two nagios instances doing the same NRPE check, the scheduling may cause one check to get a very small interval of data. For example, with cpu usage check, that mean instead of getting the last 5 minutes, you may get only the last few seconds. You can easily miss a CPU hog because at the moment the check is executing the CPU was idle for the last few seconds, even if it was full the rest of the time (because the test/backup/old Nagios instancegot the rest of the interval data). The fact that this method is nearly transparent make it even easier to fall into this pitfall and pretty hard to figure out the problem without knowing how the plugin actually work. By comparison, when using performance data strings the stored data is bound to a single Nagios service on a single Nagios instance. The same check can run many times yet the plugins will *always* get it's last performance data string. I don't care how it's implemented in the end, but I'm favor any method that can allow this kind of granularity without having to specifically think about it. - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqhQQkACgkQ6dZ+Kt5BchZrqQCfY4kf0cFzNVsNxepXhx2GetWU 3QcAn2ZGw9mJWqQM1JzoctqIHnvAwF2p =gXAm -----END PGP SIGNATURE----- From perldork at webwizarddesign.com Fri Sep 4 23:38:05 2009 From: perldork at webwizarddesign.com (Max) Date: Fri, 4 Sep 2009 17:38:05 -0400 Subject: [Nagiosplug-devel] Please can I have GIT access In-Reply-To: <20090901183609.GW5441@phcomp.co.uk> References: <20090829111204.GT21433@phcomp.co.uk> <20090829161807.GF69749771@Waran.CIS.FU-Berlin.DE> <4A9D3C3E.9040506@aei.ca> <20090901183609.GW5441@phcomp.co.uk> Message-ID: On Tue, Sep 1, 2009 at 2:36 PM, Alain Williams wrote: > Do the math: 1,000 plugins every 5 minutes. Let us say that all of them save > state (highly unlikely). Assume that the size of a state file is 1KB. > That is 3 state read/save per second, some 3KB read/written per second. We do have 1000 plugin calls that save state every 5 minutes to memcache out of the 8500 or so we currently run every 5 minutes. :) 80-85% of our plugins are SNMP based and we process many SNMP counters. > So: if on top of this is does one or two extra opens & a read/write - will it > really make that much of a difference ? Point taken. Our method is working quite well for us and I am absolutely fine with a file-based method being the default as well. As long as there is choice of a state backend I am ok with anything that comes out of this, very glad to see this becoming a part of the core plugin framework. - Max From jlmartinez-lists-nagplug-devel at capside.com Tue Sep 8 12:26:06 2009 From: jlmartinez-lists-nagplug-devel at capside.com (Jose Luis Martinez) Date: Tue, 08 Sep 2009 12:26:06 +0200 Subject: [Nagiosplug-devel] Please can I have GIT access In-Reply-To: <4AA14109.4030603@aei.ca> References: <20090829111204.GT21433@phcomp.co.uk> <20090829161807.GF69749771@Waran.CIS.FU-Berlin.DE> <4A9D3C3E.9040506@aei.ca> <20090901183609.GW5441@phcomp.co.uk> <4A9D72C7.10806@aei.ca> <20090904113812.GC70048301@Waran.CIS.FU-Berlin.DE> <4AA12510.7060408@aei.ca> <8C7B8BBE-29B8-43B4-A72F-711381E28A16@opsera.com> <4AA14109.4030603@aei.ca> Message-ID: <4AA6313E.2090202@capside.com> > Also, one more thing to consider with local storage is when you have > multiple nagios instances - either part of distributed monitoring, > migrations of just for testing. In many case data accuracy rely on the > fact the the same data is relative to the last check. If you have two > nagios instances doing the same NRPE check, the scheduling may cause one > check to get a very small interval of data. For example, with cpu usage > check, that mean instead of getting the last 5 minutes, you may get only > the last few seconds. You can easily miss a CPU hog because at the > moment the check is executing the CPU was idle for the last few seconds, > even if it was full the rest of the time (because the test/backup/old > Nagios instancegot the rest of the interval data). This is a problem that I've found with plugins that use their own storage for the checks. I've never had problems with multiple Nagios instances on one machine (I don't do that), but I have had it with the same check defined multiple times. Going along with the CPU example: check_cpu --cpu 1 check_cpu --cpu 2 If the developer hasn't forseen that the plugin will be executed with different parameters, the readings for cpu 1 and 2 can get mixed. Another case: check_cpu --cpu 1 --display system,iowait check_cpu --cpu 1 --display idle,irq Maybe check_cpu is a bad example, but think about a plugin that can output LOTS of performance data (hundreds of data channels), and you want a couple of subsets output in separate checks. The solution Nagios::Plugin::Differences applies is to let the developer choose an alternative temp file, but a couple of problems arise: - he has to be aware of the problem - even knowing about the problem, he can leave out a condition to select an alternative temp file. This has made me change the Nagios::Plugin::Differences API to add a user specified "id" to the temp file generation bit. This adds a string to the temp file name so you can choose from what temp file to read and write to. /tmp/_nagios_plugin_${script_basename}_${id}.tmp One method I'm using is to MD5 all the params that the plugin recieves. That creates a "unique" string for the id part of the temp file (I'm aware of the collisions that can ocurre problem... but have no elegant solution for now). > The fact that this method is nearly transparent make it even easier to > fall into this pitfall and pretty hard to figure out the problem without > knowing how the plugin actually work. You're right. Leaving things to the developer can lead to these hard to diagnose problems. > By comparison, when using performance data strings the stored data is > bound to a single Nagios service on a single Nagios instance. The same > check can run many times yet the plugins will *always* get it's last > performance data string. The problem, in my opinion, is that a plugin has no idea about what service check definition it is bound to, so it can't determine reliably the state of it's last execution. > I don't care how it's implemented in the end, but I'm favor any method > that can allow this kind of granularity without having to specifically > think about it. If Nagios / NRPE could just pass a unique ID for each service check definition, the plugins could use that by default to generate the tempfile name for their local storage. The unique ID could be a GUID, so that different Nagios instances would not generate the same IDs, thus solving the "multiple Nagios instances" problem too... Just my 2 cents, Jose Luis Martinez jlmartinez at capside.com From dermoth at aei.ca Tue Sep 8 15:17:50 2009 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Tue, 08 Sep 2009 09:17:50 -0400 Subject: [Nagiosplug-devel] Please can I have GIT access In-Reply-To: <4AA6313E.2090202@capside.com> References: <20090829111204.GT21433@phcomp.co.uk> <20090829161807.GF69749771@Waran.CIS.FU-Berlin.DE> <4A9D3C3E.9040506@aei.ca> <20090901183609.GW5441@phcomp.co.uk> <4A9D72C7.10806@aei.ca> <20090904113812.GC70048301@Waran.CIS.FU-Berlin.DE> <4AA12510.7060408@aei.ca> <8C7B8BBE-29B8-43B4-A72F-711381E28A16@opsera.com> <4AA14109.4030603@aei.ca> <4AA6313E.2090202@capside.com> Message-ID: <4AA6597E.4090900@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jose Luis Martinez wrote: >> By comparison, when using performance data strings the stored data is >> bound to a single Nagios service on a single Nagios instance. The same >> check can run many times yet the plugins will *always* get it's last >> performance data string. > > The problem, in my opinion, is that a plugin has no idea about what > service check definition it is bound to, so it can't determine reliably > the state of it's last execution. I'm not sure if you understand well how this works. Basically the plugin requires you to pass the performance data string and possibly the last check time (It can also get them from Nagios macros if they're enabled). The data is either present or not, and if it's not the neck populates the performance data and return UNKNOWN so next run will hopefully has the performance data. So the data comes from Nagios, and the result of a check *always* comes from a computation based on the same service's data since it was passed by Nagios from the same check. I have some examples (check_perfmon - a check runing against windows performance logs in CSV format, and a branch of nagios-plugins with similar feature to check_snmp), unfortunately I had to take my server down and hasn't had time to move the repositories, so no code right now :( Since both are meant to run from the central nagios server (unless in cases where checks are distributed to satellites which isn't supported unless arguments can be passed around) this work well. The downside of this method is that performance data can only contain numbers and NRPE currently doesn't support safe argument passing (this should be fairly easy to fix though). >> I don't care how it's implemented in the end, but I'm favor any method >> that can allow this kind of granularity without having to specifically >> think about it. > > If Nagios / NRPE could just pass a unique ID for each service check > definition, the plugins could use that by default to generate the > tempfile name for their local storage. The unique ID could be a GUID, so > that different Nagios instances would not generate the same IDs, thus > solving the "multiple Nagios instances" problem too... Same problem with remote checks, that ID has to be passed around, although that would be a viable solution to the problem I'm trying to solve. So far we have: - - Performance data * Pros: - Bound to service - no cross-service data overlap - No Nagios modifications needed * Cons: - Only small numeric values can be passed - Requires remote executor to pass arguments - - File-descriptor passing * Pros: - Bound to service in recommended setup - Large/binary storage possible - Allow flexibility in how data is stored regardless of plugin language * Cons: - Requires wrapper or Nagios/remote-executor modifications - Less intuitive - users are not familiar with this - May require remote executor to pass FDs or implement storage - - Plugin-bases with unique service ID * Pros: - Simple - Bound to service in recommended setup - Large/binary storage possible * Cons: - May requires Nagios modifications(*) - Requires remote executor to pass arguments - Different data storage requires modifications to the plugin (*) It is easy using a well-templated config to use a unique Nagios identifier + hostname + servicedescription as a unique ID, however I don't expect many setups to be able to do that off-hands as it require every services to use or include a single template... - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqmWX4ACgkQ6dZ+Kt5BchZHUwCg+JShyKRi++AJnByYV8qNCXan 8wEAoOS63GlniC4pxdX4QVXQ0tRbtks+ =cf/9 -----END PGP SIGNATURE----- From jlmartinez-lists-nagplug-devel at capside.com Tue Sep 8 17:05:47 2009 From: jlmartinez-lists-nagplug-devel at capside.com (Jose Luis Martinez) Date: Tue, 08 Sep 2009 17:05:47 +0200 Subject: [Nagiosplug-devel] Please can I have GIT access In-Reply-To: <4AA6597E.4090900@aei.ca> References: <20090829111204.GT21433@phcomp.co.uk> <20090829161807.GF69749771@Waran.CIS.FU-Berlin.DE> <4A9D3C3E.9040506@aei.ca> <20090901183609.GW5441@phcomp.co.uk> <4A9D72C7.10806@aei.ca> <20090904113812.GC70048301@Waran.CIS.FU-Berlin.DE> <4AA12510.7060408@aei.ca> <8C7B8BBE-29B8-43B4-A72F-711381E28A16@opsera.com> <4AA14109.4030603@aei.ca> <4AA6313E.2090202@capside.com> <4AA6597E.4090900@aei.ca> Message-ID: <4AA672CB.5050807@capside.com> Thomas Guyot-Sionnest escribi?: > Jose Luis Martinez wrote: >>> By comparison, when using performance data strings the stored data is >>> bound to a single Nagios service on a single Nagios instance. The same >>> check can run many times yet the plugins will *always* get it's last >>> performance data string. >> The problem, in my opinion, is that a plugin has no idea about what >> service check definition it is bound to, so it can't determine reliably >> the state of it's last execution. > > I'm not sure if you understand well how this works. Basically the plugin > requires you to pass the performance data string and possibly the last > check time (It can also get them from Nagios macros if they're enabled). > The data is either present or not, and if it's not the neck populates > the performance data and return UNKNOWN so next run will hopefully has > the performance data. OK, I didn't realize that this was possible now! (I'm supposing via $SERVICEPERFDATA$ and $LASTSERVICECHECK$). > So far we have: > > - - Performance data > * Pros: > - Bound to service - no cross-service data overlap > - No Nagios modifications needed > * Cons: > - Only small numeric values can be passed > - Requires remote executor to pass arguments Another con: you may be outputting perfdata in a format that is not "usable" the next time the check is executed. Suppose an incrementing counter. I normally read the counter, but output "things since last check" or "things since last check / second" in the performance data, so getting that perfdata back doesn't help me do the next calculation. I see this method as too limiting :S > - - File-descriptor passing > * Pros: > - Bound to service in recommended setup > - Large/binary storage possible > - Allow flexibility in how data is stored regardless of plugin language > * Cons: > - Requires wrapper or Nagios/remote-executor modifications > - Less intuitive - users are not familiar with this > - May require remote executor to pass FDs or implement storage I don't understand how the wrapper will be bound to the service. Isn't the wrapper just another plugin? If so, can't the wrapper and the "self contained storage" use the same method for binding to the service? I would be open to adapting Nagios::Plugin::Differences to also support the use of FD's as a pluggable storage mechanism, it shouldn't be too complex (was already planning for pluggable storage) > - - Plugin-bases with unique service ID > * Pros: > - Simple > - Bound to service in recommended setup > - Large/binary storage possible > * Cons: > - May requires Nagios modifications(*) > - Requires remote executor to pass arguments > - Different data storage requires modifications to the plugin But it's always good to give people a choice, and if you give me that unique ID, the two solutions would be usable. And thinking about this further... there is another way to bind to a service (mixing and matching tecniques). It's based on generating a token if one hasn't been passed, and then getting it back (via the last check (maybe via $SERVICEOUTPUT$, maybe via perfdata)? if ($SERVICEOUTPUT$ contains tk=UUID){ read /tmp/UUID; do_stuff(); write /tmp/UUID; output "$output tk=UUID"; exit $status; } else { UUID = gen_UUID(); write to /tmp/UUID; output "UNKNOWN tk=UUID"; exit with UNKNOWN } Of course, this is a poor man way of getting a unique ID passed back to you :D Jose Luis Martinez jlmartinez at capside.com From dermoth at aei.ca Tue Sep 8 17:53:04 2009 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Tue, 08 Sep 2009 11:53:04 -0400 Subject: [Nagiosplug-devel] Please can I have GIT access In-Reply-To: <4AA672CB.5050807@capside.com> References: <20090829111204.GT21433@phcomp.co.uk> <20090829161807.GF69749771@Waran.CIS.FU-Berlin.DE> <4A9D3C3E.9040506@aei.ca> <20090901183609.GW5441@phcomp.co.uk> <4A9D72C7.10806@aei.ca> <20090904113812.GC70048301@Waran.CIS.FU-Berlin.DE> <4AA12510.7060408@aei.ca> <8C7B8BBE-29B8-43B4-A72F-711381E28A16@opsera.com> <4AA14109.4030603@aei.ca> <4AA6313E.2090202@capside.com> <4AA6597E.4090900@aei.ca> <4AA672CB.5050807@capside.com> Message-ID: <4AA67DE0.6070503@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jose Luis Martinez wrote: > Thomas Guyot-Sionnest escribi?: >> So far we have: >> >> - - Performance data >> * Pros: >> - Bound to service - no cross-service data overlap >> - No Nagios modifications needed >> * Cons: >> - Only small numeric values can be passed >> - Requires remote executor to pass arguments > > Another con: you may be outputting perfdata in a format that is not > "usable" the next time the check is executed. Suppose an incrementing > counter. I normally read the counter, but output "things since last > check" or "things since last check / second" in the performance data, so > getting that perfdata back doesn't help me do the next calculation. > > I see this method as too limiting :S I still don't see where you have an issue. Performance data has a very specific format and this method doesn't break it (hence the "Only small numeric values can be passed" Cons. I've been using this method successfully for some time now. >> - - File-descriptor passing >> * Pros: >> - Bound to service in recommended setup >> - Large/binary storage possible >> - Allow flexibility in how data is stored regardless of plugin language >> * Cons: >> - Requires wrapper or Nagios/remote-executor modifications >> - Less intuitive - users are not familiar with this >> - May require remote executor to pass FDs or implement storage > > I don't understand how the wrapper will be bound to the service. Isn't > the wrapper just another plugin? If so, can't the wrapper and the "self > contained storage" use the same method for binding to the service? Well, either you have Nagios provide the FDs or have a properly ocnfigured wrapper doing it; that's why I say "Bound to service *in recommended setup*" It sure is easier to fuck up than the performance data method, but guarding applications against user stupidity will *always* be a tricky game ;) > I would be open to adapting Nagios::Plugin::Differences to also support > the use of FD's as a pluggable storage mechanism, it shouldn't be too > complex (was already planning for pluggable storage) As you wish... though IMHO I think we should settle on a single method. and use it. Even if we go file-based, the advantage with a perl module is that you can allow using different modules for storage given a specific API. In other words, anyone could write it's own data storage module and plug it in directly. You could use some sort of "connection string" (referring to the perl DB API since It has similar purpose) that would allow selecting the storage method using a parameter from command-line options. Similar thing could be possible in C but it's harder and would require writing the storage engine in C as well. >> - - Plugin-bases with unique service ID >> * Pros: >> - Simple >> - Bound to service in recommended setup >> - Large/binary storage possible >> * Cons: >> - May requires Nagios modifications(*) >> - Requires remote executor to pass arguments >> - Different data storage requires modifications to the plugin > > But it's always good to give people a choice, and if you give me that > unique ID, the two solutions would be usable. > > And thinking about this further... there is another way to bind to a > service (mixing and matching tecniques). It's based on generating a > token if one hasn't been passed, and then getting it back (via the last > check (maybe via $SERVICEOUTPUT$, maybe via perfdata)? > > if ($SERVICEOUTPUT$ contains tk=UUID){ > read /tmp/UUID; > do_stuff(); > write /tmp/UUID; > output "$output tk=UUID"; > exit $status; > } else { > UUID = gen_UUID(); > write to /tmp/UUID; > output "UNKNOWN tk=UUID"; > exit with UNKNOWN > } > > Of course, this is a poor man way of getting a unique ID passed back to > you :D Or another option, write a brand new plugin API which is much more extensible and allow passing specific values (besides output and performance data) back to Nagios. Most people think of XML though I believe it's up for debate - there are simpler and smaller solutions IMHO, and I believe Andreas agrees with me on this ;) Obviously that's a big change; It won't be done quickly nor easily so there mucg be strong incentives and community support for this to happen. Before someone yells about it, backwards-compatibility to the hundred of plugins out there can easily be achieved with a wrapper that runs them and return new-format output... - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqmfeAACgkQ6dZ+Kt5BchZJvQCfaN6FrRci85iHQOEf7f8gYhTm /fEAn0mVM2uMbW4DrddD8+JMp0Bz3goA =AA4h -----END PGP SIGNATURE----- From jlmartinez-lists-nagplug-devel at capside.com Wed Sep 9 09:05:57 2009 From: jlmartinez-lists-nagplug-devel at capside.com (Jose Luis Martinez) Date: Wed, 09 Sep 2009 09:05:57 +0200 Subject: [Nagiosplug-devel] Please can I have GIT access In-Reply-To: <4AA67DE0.6070503@aei.ca> References: <20090829111204.GT21433@phcomp.co.uk> <20090829161807.GF69749771@Waran.CIS.FU-Berlin.DE> <4A9D3C3E.9040506@aei.ca> <20090901183609.GW5441@phcomp.co.uk> <4A9D72C7.10806@aei.ca> <20090904113812.GC70048301@Waran.CIS.FU-Berlin.DE> <4AA12510.7060408@aei.ca> <8C7B8BBE-29B8-43B4-A72F-711381E28A16@opsera.com> <4AA14109.4030603@aei.ca> <4AA6313E.2090202@capside.com> <4AA6597E.4090900@aei.ca> <4AA672CB.5050807@capside.com> <4AA67DE0.6070503@aei.ca> Message-ID: <4AA753D5.6080201@capside.com> Thomas Guyot-Sionnest escribi?: >> I see this method as too limiting :S > > I still don't see where you have an issue. Performance data has a very > specific format and this method doesn't break it (hence the "Only small > numeric values can be passed" Cons. I've been using this method > successfully for some time now. I'm not saying this method can't be succesfully used, and think it's really clever! It actually inspired the token techinque. I think it's too limiting because: - you don't always calculate the next data with the perfdata you output - it's only valid for numbers - the size of the perfdata is limited - you may want to store multiple results and not just the last result I don't see this method of storing data as a flexible long term solution for saving plugin state in Nagios plugins, although it can be used effectively and flawlessly in some scenarios. > >> I would be open to adapting Nagios::Plugin::Differences to also support >> the use of FD's as a pluggable storage mechanism, it shouldn't be too >> complex (was already planning for pluggable storage) > > As you wish... though IMHO I think we should settle on a single method. > and use it. Even if we go file-based, the advantage with a perl module > is that you can allow using different modules for storage given a > specific API. In other words, anyone could write it's own data storage > module and plug it in directly. You could use some sort of "connection > string" (referring to the perl DB API since It has similar purpose) that > would allow selecting the storage method using a parameter from > command-line options. On the C side, you guys know better. On the Nagios::Plugin::Differences side: If the Nagios Plugins project goes for wrappers or FD passing: Nagios::Plugin::Differences will try to support it. Since in Perl it's so easy to let the developer choose, I'd still let them choose if they want to store via FDs, or the multitude of storages available on CPAN (also, the non-FD storage would be available right now). > Or another option, write a brand new plugin API which is much more > extensible and allow passing specific values (besides output and > performance data) back to Nagios. Most people think of XML though I > believe it's up for debate - there are simpler and smaller solutions > IMHO, and I believe Andreas agrees with me on this ;) > > Obviously that's a big change; It won't be done quickly nor easily so > there mucg be strong incentives and community support for this to happen. I'd opt for the almost already available than for the new bright and shiny that never comes. More so if what is almost here provides the same functionality :) Either way you choose to implement the storage on the C side, I understand there is one common problem: binding to a service. If that gets studied, discussed, selected and implemented quickly the APIs will be able to provide surprise-free operation by default. Can you expose how you were thinking of modifying Nagios and the remote executors? Jose Luis Martinez jlmartinez at capside.com From addw at phcomp.co.uk Wed Sep 9 22:47:43 2009 From: addw at phcomp.co.uk (Alain Williams) Date: Wed, 9 Sep 2009 21:47:43 +0100 Subject: [Nagiosplug-devel] Please can I have GIT access - PATCH ATTACHED In-Reply-To: <4A9D6F14.5000908@aei.ca> References: <20090829111204.GT21433@phcomp.co.uk> <20090829161807.GF69749771@Waran.CIS.FU-Berlin.DE> <4A9D3C3E.9040506@aei.ca> <4A9D6F14.5000908@aei.ca> Message-ID: <20090909204742.GI29402@phcomp.co.uk> Well, I started this thread and what I heard was: the basic patch that I made to check_procs although: 1) it was a bit big. 2) it saved state in files. This led to a long discussion where it was thought that the ability to save state would be nice but via a generalised API that also allowed the possibility of saving to something else. There not much that I can do about (1), although most of the new code was in new functions at the bottom of the codeand is associated with save/restore of state. About (2). I have written an API that, I think, meets the requirement. It is implemented using files but the API makes no reference to files so a different mechanism could be plugged in. This is implemented in: lib/state_save.c lib/state_save.h This provides the simple functions: int np_state_save_serial(const char* name, const char* instance, int version, const char* serial); that may be used to save state, resored with: char* np_state_restore_serial(const char* name, const char* instance, int version); There are other functions that may be more convenient for C programmers. These allow storing/restoring of typed strings (ie record types) and others that save/restore binary C structures. The files have a header where the date is kept and comments inserted. I have modified the check_procs plugin to use this mechanism so that you can see it working. The functions are exercised in a test program: config_test/plugin_save_test.c This provides examples as to how the functions are intended to be used. Finally it is all documented: doc/state_file.txt The patch is against nagios-plugins-trunk-200909091200. I am content to give copyright to the new code and documentation that I have written, or code and documentation derived from it, to the Nagios Plugins Development Team on condition: 1) that I may freely use this code, or parts of it, elsewhere under any license and title that I choose. 2) that the code that I give shall not be distributed under a license that is not open source according to: http://opensource.org/docs/osd 3) That my authorship remain in the source files. Having said that: enjoy! -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Past chairman of UKUUG: http://www.ukuug.org/ #include -------------- next part -------------- A non-text attachment was scrubbed... Name: nagios-plugins-trunk-200909091200.patch.gz Type: application/x-gzip Size: 20793 bytes Desc: not available URL: From noreply at sourceforge.net Thu Sep 10 07:03:56 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 10 Sep 2009 05:03:56 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2832451 ] check_snmp regression - parsing multi-line snmpget responses Message-ID: Bugs item #2832451, was opened at 2009-08-05 00:51 Message generated for change (Settings changed) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2832451&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution >Group: None Status: Open Resolution: None >Priority: 6 Private: No Submitted By: Thomas Guyot-Sionnest (dermoth) Assigned to: Thomas Guyot-Sionnest (dermoth) Summary: check_snmp regression - parsing multi-line snmpget responses Initial Comment: Bug #1985230 removed some badly written (though seemingly working) code that enabled parsing multi-line STRING responses from snmpget, causing it to segfault. The segfault has been fixed already (sort of - plugins doesn't return OK yet), and a test case has been added to tests/check_snmp.t. Since I haven't had time to fix it yet I'm opening this bug to ease tracking this regression. ---------------------------------------------------------------------- >Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-09-10 01:03 Message: Lowering priority as right now the only effect is long strings being truncated (I'm pretty sure nobody noticed they wereren't!), and a test has been added for this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2832451&group_id=29880 From dimmumeister at gmail.com Mon Sep 14 13:46:04 2009 From: dimmumeister at gmail.com (ahmed h) Date: Mon, 14 Sep 2009 04:46:04 -0700 (PDT) Subject: [Nagiosplug-devel] =?utf-8?q?Invitation_=C3=A0_se_connecter_sur_L?= =?utf-8?q?inkedIn?= Message-ID: <1999362474.2647362.1252928764779.JavaMail.app@ech3-cdn08.prod> LinkedIn ------------ Je t'invite ? faire partie de mon r?seau professionnel en ligne sur le site LinkedIn. ahmed Accepter l'invitation de ahmed h?: https://www.linkedin.com/e/isd/735696052/sAF9FHOs/ ------ (c) 2009, LinkedIn Corporation -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jason.Abraham at washco.utah.gov Tue Sep 15 21:18:19 2009 From: Jason.Abraham at washco.utah.gov (Jason Abraham) Date: Tue, 15 Sep 2009 13:18:19 -0600 Subject: [Nagiosplug-devel] Alarm problems Message-ID: <000001ca3639$48bd1ef0$da375cd0$@Abraham@washco.utah.gov> I have created a plugin which uses SNMP (http://www.washco.utah.gov/meej/check_3com_alive.txt) and as such I have employed the recommended alarm safe-guard ---- # start counting down to timeout alarm $plugin->opts->timeout; your_long_check_step_that_might_time_out(); ---- I use Nagios::Plugin to handle my exit state (nagios_exit). When testing the plugin with new_mini_epn it functions correctly and returns the correct codes. However, if I execute my plugin via new_mini_epn and then wait I eventually get the an alarm error: ----- ./new_mini_epn plugin command line: check_3com_alive.pl -H 10.0.0.10 -C pass -n 3 embedded perl plugin return code and output was: 0 & 3COM_ALIVE OK - 3 of 3 units in stack plugin command line: CHECK_3COM_ALIVE.PL UNKNOWN - plugin timed out (timeout 15s) ExitTrap: 3 (Redefine exit to trap plugin exit with eval BLOCK) at p1.pl line 61, line 1. ----- Obviously, the alarm timer is still left running even after calling nagios_exit. Is this a problem with my code, Nagios::Plugin, or is it even a problem at all? I am using nagios-plugins-1.4.13 Thanks, Jason From noreply at sourceforge.net Tue Sep 15 22:30:06 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 15 Sep 2009 20:30:06 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2859548 ] check_by_ssh exit status when reaching timeout Message-ID: Bugs item #2859548, was opened at 2009-09-15 22:30 Message generated for change (Tracker Item Submitted) made by guillomovitch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2859548&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Guillaume Rousse (guillomovitch) Assigned to: Nobody/Anonymous (nobody) Summary: check_by_ssh exit status when reaching timeout Initial Comment: check_by_ssh currently exist with CRITICAL status when reaching timeout. When used just as a transport mechanism for invoking a remote plugin, it should rather exit with UNKNOWN status in this case. The patch is trivial, I'd be happy to contribute it if this is agreed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2859548&group_id=29880 From noreply at sourceforge.net Wed Sep 16 10:19:40 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Sep 2009 08:19:40 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1164331 ] IBM-AIX 5.1 :Link-Error "Undefined symbol: .libintl_gettext" Message-ID: Bugs item #1164331, was opened at 2005-03-16 09:53 Message generated for change (Settings changed) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1164331&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Wilfried Brunken (df7be) Assigned to: Nobody/Anonymous (nobody) Summary: IBM-AIX 5.1 :Link-Error "Undefined symbol: .libintl_gettext" Initial Comment: not on AIX 4.3 ! Can configure find the Problem itself ? Workaround ./configure --disable-nls --with-included-gettext Solution found at this link: http://mail.gnome.org/archives/mc-devel/2002- September/msg00193.html ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2009-09-16 09:19 Message: There have been many changes around this area. Please try the snapshot at http://nagiosplugins.org/download Marked into pending, which will autoclose if no updates in 7 days. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1164331&group_id=29880 From addw at phcomp.co.uk Wed Sep 16 13:39:48 2009 From: addw at phcomp.co.uk (Alain Williams) Date: Wed, 16 Sep 2009 12:39:48 +0100 Subject: [Nagiosplug-devel] Patch for persistent data on plugins Message-ID: <20090916113948.GA2066@phcomp.co.uk> Please find attached a new version of the patch that I submitted a week ago. This provides an back end neutral mechanism for persistant data storage for plugins written in C. This follows the discussion that I started by trying to get accepted a patch for check_procs. I must confess to being disappointed that there has not been any comment about this. It does seem hard to help the nagios plugins project. My original email (please read): http://sourceforge.net/mailarchive/message.php?msg_name=20090909204742.GI29402%40phcomp.co.uk The patch is against nagios-plugins-trunk-200909091200. Regards -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Past chairman of UKUUG: http://www.ukuug.org/ #include -------------- next part -------------- A non-text attachment was scrubbed... Name: nagios-plugins-trunk-200909091200.patch.2009-09-16.gz Type: application/x-gzip Size: 21626 bytes Desc: not available URL: From ton.voon at opsera.com Wed Sep 16 14:02:32 2009 From: ton.voon at opsera.com (Ton Voon) Date: Wed, 16 Sep 2009 13:02:32 +0100 Subject: [Nagiosplug-devel] Patch for persistent data on plugins In-Reply-To: <20090916113948.GA2066@phcomp.co.uk> References: <20090916113948.GA2066@phcomp.co.uk> Message-ID: On 16 Sep 2009, at 12:39, Alain Williams wrote: > Please find attached a new version of the patch that I submitted a > week ago. > > This provides an back end neutral mechanism for persistant data > storage for plugins written in C. > This follows the discussion that I started by trying to get accepted > a patch for check_procs. > > I must confess to being disappointed that there has not been any > comment about this. It does > seem hard to help the nagios plugins project. > > My original email (please read): > > http://sourceforge.net/mailarchive/message.php?msg_name=20090909204742.GI29402%40phcomp.co.uk > > The patch is against nagios-plugins-trunk-200909091200. Sorry, I didn't see the email until today (because someone replied to the thread with a different subject - I know, bad excuse). I'll take a look later Ton -------------- next part -------------- An HTML attachment was scrubbed... URL: From dermoth at aei.ca Thu Sep 17 08:05:52 2009 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Thu, 17 Sep 2009 02:05:52 -0400 Subject: [Nagiosplug-devel] Patch for persistent data on plugins In-Reply-To: References: <20090916113948.GA2066@phcomp.co.uk> Message-ID: <4AB1D1C0.5070706@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 16/09/09 08:02 AM, Ton Voon wrote: > > On 16 Sep 2009, at 12:39, Alain Williams wrote: > >> Please find attached a new version of the patch that I submitted a >> week ago. >> >> This provides an back end neutral mechanism for persistant data >> storage for plugins written in C. >> This follows the discussion that I started by trying to get accepted a >> patch for check_procs. >> >> I must confess to being disappointed that there has not been any >> comment about this. It does >> seem hard to help the nagios plugins project. >> >> My original email (please read): >> >> http://sourceforge.net/mailarchive/message.php?msg_name=20090909204742.GI29402%40phcomp.co.uk >> >> The patch is against nagios-plugins-trunk-200909091200. > > Sorry, I didn't see the email until today (because someone replied to > the thread with a different subject - I know, bad excuse). > > I'll take a look later My take on this...: 1. Tests should use libtap, and lets remove those goto's before someone else see them ;) 2. Doc should go in the docbook, not a plain text file (if there are too technical portions those could be be code comments 3. A plugin shouldn't share state file for multiple different invocations. Plugins may run in parallel so this is asking for trouble (one invocation overwriting another plugin's data). That also call for a much simpler API and plugin code. 4. Should we write a temp file first and move it over instead of truncating it? IMHO the former is much better is the file is not opened and saver at once... 5. time.h is already included in common.h 6. Binary strings should go with string length - they may contain nulls. 7. Why do np_state_add_vcomment() needs first + comment_array? Why a standalone array won't work?? 8. I don't think the descripting/comments should go in there. They could be added manually or trough a serialization library, but in most cases the pluginj's verbose mode should be enough to debug. 9. On some unix unlink() may damage file system if the path is a directory and the plugin is run as root. Any sysadmin ending up in that situation should be shot in the head, but it's an easy check... 10. DIR_DEFAULT should come from configure with an option to change it. The default should likely be PREFIX/var/rw or something like that (nagios temp path... you get the idea) 12. I'd suggest having all files prefixed with "np_" instead of using some sort of heuristic to determine whenever we should add "nagios-plugin_" (bonus point: making prefix a configure parameter). 13. I like the ascii header, but I'd use a more compact version. This ensure state files are as small as possible, preventing waste (very useful when a tmpfs is used for storage and helping usage of tail files on fs that support it). 14. There's no additional tests in check_procs.t - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKsdHA6dZ+Kt5BchYRAkPbAJ9xjRNugz8UVrgggrIOy+g7hIku5wCfRzAO wdlt5+/YrVHkdnwApHabSuw= =kWYE -----END PGP SIGNATURE----- From noreply at sourceforge.net Thu Sep 17 09:17:57 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 17 Sep 2009 07:17:57 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2860507 ] ping6 from iputils support Message-ID: Patches item #2860507, was opened at 2009-09-17 09:17 Message generated for change (Tracker Item Submitted) made by arekm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2860507&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Enhancement Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Arkadiusz Miskiewicz (arekm) Assigned to: Nobody/Anonymous (nobody) Summary: ping6 from iputils support Initial Comment: Patch against Plugin Version (-V output): 1.4.13 Plugin Name: check_ping Example Plugin Commandline: check_ping --verbose -H cvs.ipv6.pld-linux.org -w 100,99% -c 5000,100% -p 1 Tested on operating system: PLD/Linux Tested on architecture: x86_64 Tested with compiler: gcc 4.4.1 Attached patch adds support for ping6 from iputils package command output. http://www.linux-ipv6.org/gitweb/gitweb.cgi?p=gitroot/iputils.git;a=blob;h=2cde1189a1a3a9bc23de220ada959b03a026dba0;hb=ecf3da14243faabaa2d385f127d6abc571f8fed2;f=ping6.c By submitting a patch, you are stating that: * this is your own work or you have full rights to publish and license it * that it can be released under the GPL Agreed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2860507&group_id=29880 From jlmartinez-lists-nagplug-devel at capside.com Thu Sep 17 10:47:39 2009 From: jlmartinez-lists-nagplug-devel at capside.com (Jose Luis Martinez) Date: Thu, 17 Sep 2009 10:47:39 +0200 Subject: [Nagiosplug-devel] Patch for persistent data on plugins In-Reply-To: <4AB1D1C0.5070706@aei.ca> References: <20090916113948.GA2066@phcomp.co.uk> <4AB1D1C0.5070706@aei.ca> Message-ID: <4AB1F7AB.8040706@capside.com> Thomas Guyot-Sionnest escribi?: > 3. A plugin shouldn't share state file for multiple different > invocations. Plugins may run in parallel so this is asking for trouble > (one invocation overwriting another plugin's data). Can we restart the discussion about the different techinques to achive this? I'd like to adopt the one that finally gets used by the C plugins in Nagios::Plugin::Differences. Jose Luis Martinez jlmartinez at capside.com From ton.voon at opsera.com Thu Sep 17 11:00:37 2009 From: ton.voon at opsera.com (Ton Voon) Date: Thu, 17 Sep 2009 10:00:37 +0100 Subject: [Nagiosplug-devel] Perfdata patternin Nagios::Plugin::Performance.pm In-Reply-To: <895D4F21D61A4DE7BBB36E386D73E497@int.consol.de> References: <4FE55472156C452F922C652BCBCEEEA4@int.consol.de><64C6AC26-49CE-4A54-A897-3EF17397226B@opsera.com> <4A5B2243.6050803@aei.ca> <29B0A583AC504F1A9836B9690F7AB189@int.consol.de> <4A5DBAD4.5090700@aei.ca> <895D4F21D61A4DE7BBB36E386D73E497@int.consol.de> Message-ID: <3EA1E43E-FDD7-498C-98AA-33B13F597571@opsera.com> On 16 Jul 2009, at 09:26, Gerhard Lausser wrote: > the developer of the plugin using = accepted to find a workaround. >>> So am I assuming that it is okay to remove "=" from the guidelines? >> From my side, yes. > I too wrote plugins whre in rare cases a = can appear in the label, > but i > also provide a --name parameter which then is used as the label > instead. > I've just updated the plugin developer docs to state that the equals sign should not be used in a performance label. I have an idea to setup a page on nagiosplugins.org where you can pass in a perf string and it will reply with what the parser from Nagios::Plugin::Performance->parse_perfstring returns and you can then click "yes" or "no" if it is correct. Then we'll add that to the database of tests to check against in future. Just need a bit of time to set it up.... Ton From nagiosplug-devel at lusis.org Thu Sep 17 12:58:28 2009 From: nagiosplug-devel at lusis.org (John Vincent) Date: Thu, 17 Sep 2009 06:58:28 -0400 Subject: [Nagiosplug-devel] Patch for persistent data on plugins In-Reply-To: <4AB1F7AB.8040706@capside.com> References: <20090916113948.GA2066@phcomp.co.uk> <4AB1D1C0.5070706@aei.ca> <4AB1F7AB.8040706@capside.com> Message-ID: On Thu, Sep 17, 2009 at 4:47 AM, Jose Luis Martinez wrote: > Can we restart the discussion about the different techinques to achive > this? I'd like to adopt the one that finally gets used by the C plugins > in Nagios::Plugin::Differences. > I wasn't able to be a part of the original discussion due to vacation, illness and other things but wouldn't it make the most sense for Nagios::Plugin::Differences to just use Cache:Cache and allow the end user to swap the storage mechanism as they see fit? I know in at least one plugin I wrote used Cache::SharedMem and just set the namespace to the hostname in the check. John E. Vincent From addw at phcomp.co.uk Thu Sep 17 13:04:49 2009 From: addw at phcomp.co.uk (Alain Williams) Date: Thu, 17 Sep 2009 12:04:49 +0100 Subject: [Nagiosplug-devel] Patch for persistent data on plugins In-Reply-To: <4AB1D1C0.5070706@aei.ca> References: <20090916113948.GA2066@phcomp.co.uk> <4AB1D1C0.5070706@aei.ca> Message-ID: <20090917110449.GM16365@phcomp.co.uk> On Thu, Sep 17, 2009 at 02:05:52AM -0400, Thomas Guyot-Sionnest wrote: > My take on this...: > > 1. Tests should use libtap, I didn't see that, it is not referenced in an appropriate README. I'll look at it. > and lets remove those goto's before someone > else see them ;) There are no gotos in state_save.c There are a few in the test program and in check_procs.c -- they are used how a goto should be used -- in an error state and to increase clarity; one target in a function does not confuse and avoids excessive nested {}. Summary: without goto the code becomes more complicated/difficult-to-read. > 2. Doc should go in the docbook, not a plain text file (if there are too > technical portions those could be be code comments I cannot see anything called docbook in the plugins tar file ? > 3. A plugin shouldn't share state file for multiple different > invocations. Plugins may run in parallel so this is asking for trouble > (one invocation overwriting another plugin's data). That also call for a > much simpler API and plugin code. That is why the functions have the 'instance' argument, from my documentation: name This should be the name of the program instance If the program may be run several times (eg to monitor different disks) this should contain a way of distinguishing the different instances. If this is not needed it should be NULL. Neither name not instance should contain spaces or slashes ('/'). An instance may be 'sda', 'sdb', ... for something that is monitoring disks. I have added a bit more to the documentation of np_state_save_start(). > 4. Should we write a temp file first and move it over instead of > truncating it? IMHO the former is much better is the file is not opened > and saver at once... That could be done. I don't think that it worth the extra complexity. There will only be an error if something really nasty happens (eg out of disk space). If state is lost then a warning may be lost, but if a disk has gone full - worse things are afoot. If a state file is corrupt then the plugin will probably rewrite it with fresh/clean state information. I won't do anything without further discussion. It might make sense if the nagios plugin state files were removed on nagios start (but not reload) anyway: discuss. > 5. time.h is already included in common.h Removed from check_procs.c > 6. Binary strings should go with string length - they may contain nulls. The C standard is NUL terminated strings. I wanted to make it easy for C programmers to use. If they have other (non usual) structures/... then they can use np_state_save_binary_record(). Did you look at the test program ? This shows the different ways of doing things - there are different ways depending on how complicated the data is that needs to be saved; ie if it is simple use: np_state_save_serial() - all done in one function call. > 7. Why do np_state_add_vcomment() needs first + comment_array? Why a > standalone array won't work?? Look at the documentation: /* Set the plugin command line arguments as a comment * in the state save file. */ if(np_state_add_vcomment("Args:", argv)) die(STATE_UNKNOWN, _("Can't add state store comments as: %s"), np_state_perror()); ie you need the first one so that you can describe what is on the rest of the line. I have added a check to allow the first argument of np_state_add_vcomment() to be NULL - in which case it is ignored and just the array added. > 8. I don't think the descripting/comments should go in there. They could > be added manually or trough a serialization library, but in most cases > the pluginj's verbose mode should be enough to debug. That is if you understand what is generating the file. Remember that people who are new to this have problems understanding how it all hangs together. I found the comments useful when debugging check_procs. Typically the comments will be just: plugin name & command line args; date in human understandable format; a DO NOT EDIT line. The over head is 100-200 bytes. (See later discussion) > 9. On some unix unlink() may damage file system if the path is a > directory and the plugin is run as root. Any sysadmin ending up in that > situation should be shot in the head, but it's an easy check... I use unlink() in np_state_destroy_save() to remove the state file. This is not a directory. I have modified the internal function generate_filename() to check & return an error if: name is empty or: name or instance contain a space or '/'. That will prevent trying to unlink a directory. Changes in my private version that I will repost when appropriate. > 10. DIR_DEFAULT should come from configure with an option to change it. > The default should likely be PREFIX/var/rw or something like that > (nagios temp path... you get the idea) I'll do that. > 12. I'd suggest having all files prefixed with "np_" instead of using > some sort of heuristic to determine whenever we should add > "nagios-plugin_" (bonus point: making prefix a configure parameter). That is only if DIR_DEFAULT is used, ie it is in /tmp. Making it a configure option (your point 10) fixes this (ie it is the same thing). One point that you did NOT make that I thought you might is my use of the environment variable NAGIOS_PLUGIN_STATE_DIRECTORY. I can't see a simple way of avoiding this without adding complexity to the plugins (which is something that I wanted to avoid). It would be nice if there was some nagios support for this -- ie a nagios config parameter that makes it set this env var, rather than having to set this in the environment before calling nagios. > 13. I like the ascii header, but I'd use a more compact version. This > ensure state files are as small as possible, preventing waste (very > useful when a tmpfs is used for storage and helping usage of tail files > on fs that support it). Hmmm, it is a trade off between compactness and ease of understanding by the nagios newbie system admin. A quick look at those generated by the test program shows that the header length is less than 180 chars. For those that have not seen it we are talking about a header like: I Nagios Plugin State File # This is generated by the plugin - DO NOT HAND EDIT # Plugin id: test instance: array V 1 # File written: Fri Sep 11 18:33:50 2009 T 4aaa89fe B 1 N 11 Removing the comments takes that down to 52 bytes (from 179). I could do something like testing for env var NAGIOS_PLUGIN_STATE_NO_COMMENT and suppress the comments, but is that worth it ? ''Nagios Plugin State File'' is 24 chars & could be shortened, I made is explicit so that if a sysadmin found the file and asked the question ''what is this file ?'' that it would be an easy answer. > 14. There's no additional tests in check_procs.t Hmmmm: what is the purpose of the extra checks ? I could check parsing of command line args. Checking of saved state is really difficult (what is happening on the system that the test is being run on ?). The main thing to test is the save/restore of test data - this is what the plugin_save_test.c does. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Past chairman of UKUUG: http://www.ukuug.org/ #include From jlmartinez-lists-nagplug-devel at capside.com Thu Sep 17 14:53:53 2009 From: jlmartinez-lists-nagplug-devel at capside.com (Jose Luis Martinez) Date: Thu, 17 Sep 2009 14:53:53 +0200 Subject: [Nagiosplug-devel] Patch for persistent data on plugins In-Reply-To: References: <20090916113948.GA2066@phcomp.co.uk> <4AB1D1C0.5070706@aei.ca> <4AB1F7AB.8040706@capside.com> Message-ID: <4AB23161.4030501@capside.com> John Vincent escribi?: > On Thu, Sep 17, 2009 at 4:47 AM, Jose Luis Martinez > wrote: >> Can we restart the discussion about the different techinques to achive >> this? I'd like to adopt the one that finally gets used by the C plugins >> in Nagios::Plugin::Differences. >> Pluggable storage is in the roadmap for N::P::Differences. But there is one issue that would have to be resolved before that: The thing is that you can be executing the same plugin with the same hostname 2 times on the same machine (with different params). One plugin would pick up the data of the other plugin. As an example: check_disk --disk=sda -w=90 -c=95 check_disk --disk=sdb -w=90 -c=95 That gets reflected as the "instance" parameter in the proposed API. The bad thing is that the developer has to be VERY aware of this situation, and could lead to very hard to understand and hard to debug results for the user of the plugin. If in the disk example, the developer chooses the --disk param as the instance id, and the plugin has a couple of extra params (to select blocks in and blocks out, for example), one possible use of the plugin would lead to problems: check_disk --disk=sda --blocksin -w=90 -c=95 check_disk --disk=sda --blocksout -w=50 -c=95 And the developer may have not been aware of this use case. IMHO, the instance id should not be selected by the developer, as he is not capable of previewing all these situations. There should be a way of automatically giving it to the plugin. The base case is: If you have a plugin that generates a piece of data, and recollects it later, and you have it defined N times in Nagios (be whatever you want it's parameters), you would exepect that every "instance" of the check gets back the data it stored. That would be that the check is "bound to the service". Thomas discussed the pros and cons of some methods to bind the plugins to their service. But no method has been agreed on. Jose Luis Martinez jlmartinez at capside.com From ton.voon at opsera.com Thu Sep 17 16:32:23 2009 From: ton.voon at opsera.com (Ton Voon) Date: Thu, 17 Sep 2009 15:32:23 +0100 Subject: [Nagiosplug-devel] Patch for persistent data on plugins In-Reply-To: <4AB23161.4030501@capside.com> References: <20090916113948.GA2066@phcomp.co.uk> <4AB1D1C0.5070706@aei.ca> <4AB1F7AB.8040706@capside.com> <4AB23161.4030501@capside.com> Message-ID: On 17 Sep 2009, at 13:53, Jose Luis Martinez wrote: > The thing is that you can be executing the same plugin with the same > hostname 2 times on the same machine (with different params). One > plugin > would pick up the data of the other plugin. > > As an example: > check_disk --disk=sda -w=90 -c=95 > check_disk --disk=sdb -w=90 -c=95 > > That gets reflected as the "instance" parameter in the proposed API. > The > bad thing is that the developer has to be VERY aware of this > situation, > and could lead to very hard to understand and hard to debug results > for > the user of the plugin. > > If in the disk example, the developer chooses the --disk param as the > instance id, and the plugin has a couple of extra params (to select > blocks in and blocks out, for example), one possible use of the plugin > would lead to problems: > > check_disk --disk=sda --blocksin -w=90 -c=95 > check_disk --disk=sda --blocksout -w=50 -c=95 > > And the developer may have not been aware of this use case. > > IMHO, the instance id should not be selected by the developer, as he > is > not capable of previewing all these situations. There should be a > way of > automatically giving it to the plugin. I think I'd rather the developer consider these options, than make it difficult for the nagios administrator to configure. > The base case is: If you have a plugin that generates a piece of data, > and recollects it later, and you have it defined N times in Nagios (be > whatever you want it's parameters), you would exepect that every > "instance" of the check gets back the data it stored. That would be > that > the check is "bound to the service". I think this actually shows that Nagios should interpret the perfdata. If nagios stored the previous values, then it can work out things like rate changes. Ton From addw at phcomp.co.uk Thu Sep 17 16:45:29 2009 From: addw at phcomp.co.uk (Alain Williams) Date: Thu, 17 Sep 2009 15:45:29 +0100 Subject: [Nagiosplug-devel] Patch for persistent data on plugins In-Reply-To: References: <20090916113948.GA2066@phcomp.co.uk> <4AB1D1C0.5070706@aei.ca> <4AB1F7AB.8040706@capside.com> <4AB23161.4030501@capside.com> Message-ID: <20090917144529.GT16365@phcomp.co.uk> On Thu, Sep 17, 2009 at 03:32:23PM +0100, Ton Voon wrote: > I think this actually shows that Nagios should interpret the perfdata. > If nagios stored the previous values, then it can work out things like > rate changes. +1 Nagios is doing all the work and just remembering 3 values: OK, Warn, Crititcal. Keeping real values (where appropriate) would be great for trend analysis and make Nagios much more useful. OK: Nagios doesn't want to keep them for long, but needs a path to be able to dump them to a database/... -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Past chairman of UKUUG: http://www.ukuug.org/ #include From hir3npatel at gmail.com Thu Sep 17 17:23:02 2009 From: hir3npatel at gmail.com (Hiren Patel) Date: Thu, 17 Sep 2009 17:23:02 +0200 Subject: [Nagiosplug-devel] check procs via nrpe Message-ID: <4AB25456.30709@gmail.com> check_procs usually reports the right number of processes running, but when run through nrpe, reports one extra process (if using args for example) because nrpe calls the shell to run the check. I noticed this after seeing nrpe reporting 2 processes yet running the command on the local box said 1 process. the diff attached causes the check to ignore the process if the processes pid is the same this checks ppid. nrpe runs the shell which runs the check, so the shell process should be the checks parent. haven't really tested this, wanted to see if it would be considered, if so I'll test it. any comments appreciated. -------------- next part -------------- A non-text attachment was scrubbed... Name: check_procs.diff Type: text/x-patch Size: 706 bytes Desc: not available URL: From jlmartinez-lists-nagplug-devel at capside.com Thu Sep 17 18:07:07 2009 From: jlmartinez-lists-nagplug-devel at capside.com (Jose Luis Martinez) Date: Thu, 17 Sep 2009 18:07:07 +0200 Subject: [Nagiosplug-devel] Patch for persistent data on plugins In-Reply-To: References: <20090916113948.GA2066@phcomp.co.uk> <4AB1D1C0.5070706@aei.ca> <4AB1F7AB.8040706@capside.com> <4AB23161.4030501@capside.com> Message-ID: <4AB25EAB.9090608@capside.com> Ton Voon escribi?: >> IMHO, the instance id should not be selected by the developer, as he >> is >> not capable of previewing all these situations. There should be a >> way of >> automatically giving it to the plugin. > > I think I'd rather the developer consider these options, than make it > difficult for the nagios administrator to configure. The Nagios administrator wouldn't have to be bothered if the plugin recieved a unique id, that the plugin would then use as an instance ID automatically. Both plugin developer and user proof :) In last discussion, I proposed a technique that can be used (based on Thomas' perfdata tecnique): > It's based on generating a token if one hasn't been passed, > and then getting it back via the last check (maybe > via $SERVICEOUTPUT$, maybe via perfdata? > >if ($SERVICEOUTPUT$ contains tk=UUID){ > read /tmp/UUID; > do_stuff(); > write /tmp/UUID; > output "$output tk=UUID"; > exit $status; >} else { > UUID = gen_UUID(); > write to /tmp/UUID; > output "UNKNOWN tk=UUID"; > exit with UNKNOWN >} note that '/tmp/UUID' is pseudo code for "storage for UUID". I don't like this tecnique because it implies having the admin to configure check --id="$SERVICEOUTPUT$". I supspect that Nagios already has an internal identifier just waiting to be exposed via a macro so that it can be used as: check --id=$SERVICEUUID$ an important property for the macro would be that a Nagios reload wouldn't change it. Is this possible? It's back compatible too! The pre-SERVICEUUID Nagios admins just have to assign an unused id... It would work via NRPE too! It could all be done automatically via an ENV var to not pester the administrators, but that, I suspect will need changes to Nagios, remote agents, and possibly protocols... And the pre-SERVICEUUID admins would have to wrap the plugin in a wrapper that would set that ENV var, or the check would still have to provide an id parameter to set it's value... > I think this actually shows that Nagios should interpret the perfdata. > If nagios stored the previous values, then it can work out things like > rate changes. But the plugin needs the info get back to it so it can decide the status. One problem I see is that if the plugin recieves the performance data it last outputted back, it may not be of utility. For example: check_disk reads from a counter in the kernel that marks how many blocks have been read from a disk since last reboot "check_disk -w 100 -c 500" first execution reads 1000 blocks. Stores the "1000" in the data store Status: UNKNOWN Perfdata: blocks= "check_disk -w 100 -c 500" executes again reading 3000 blocks. Reads the stored 1000. 100 seconds have passed. (3000 - 1000) / 100 = 200 blocks/second. Stores the 3000 Status:WARNING ( w > 200 > c ) Perfdata: blocks=200 "check_disk -w 100 -c 500" executes again reading 10000 blocks. Reads the stored 3000. 100 seconds have passed. (10000 - 3000) / 100 = 700 blocks/second. Stores the 10000 Status:CRITICAL ( c > 500 ) Perfdata: blocks=700 If I get this perfdata back, I can't do next steps calculations. (I can always output the raw counter value, and then do the calculation based on that, but that would affect the way the graphing software now has to treat those values). Use check_cpu as a case. The linux kernel returns how many slices of time it has passed in user, system, etc. But the output you want is user=50 system=30 (percent). The raw values for the system and user times would be bothering. Another limitation is that it is just for numerical only values. And another one: The plugin will only get back one set of data... How would you implement a plugin that would check every five minutes, but the status calculated with a 1 hour window of results? Just my 2c, Jose Luis Martinez jlmartinez at capside.com From noreply at sourceforge.net Fri Sep 18 08:32:23 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 Sep 2009 06:32:23 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-668778 ] check_ircd - invalid argument Message-ID: Bugs item #668778, was opened at 2003-01-15 17:51 Message generated for change (Comment added) made by justdave72 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=668778&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Harper Mann (harpermann) Summary: check_ircd - invalid argument Initial Comment: Any ideas what im doing wrong here libexec]# ./check_ircd -v -H xxx.xxx.xxx.xxx MAIN(debug): hostname = something.host.name MAIN(debug): binding to remote host: xxx.xxx.xxx.xxx - > 6667 -> something.host.name IRCD UNKNOWN: Could not connect socket (Invalid argument) something.host.name and xxx.xxx.xxx.xxx are valid hostnames and ips just edited out in this post I get the same (IRCD UNKNOWN: Could not connect socket (Invalid argument)) as status when it is run by nagios. ./check_ircd -V check_ircd (nagios-plugins 1.3.0-beta2) 1.3 The nagios plugins come with ABSOLUTELY NO WARRANTY. You may redistribute copies of the plugins under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING. This is when it is run in its unmodified form installed from source and compiled, or usign an rpm build Thanks in advance for any advice. Sarah ---------------------------------------------------------------------- Comment By: David Miller (justdave72) Date: 2009-09-18 02:32 Message: The problem seems to be that check_ircd is attempting to bind to the interface that goes with the machine's primary hostname. In many cases that's not correct. I was also getting this error if I had my hostname assigned to 127.0.0.1 in /etc/hosts, but removing that caused a timeout. This is because my monitoring host has interfaces on several vlans, and without the entry in /etc/hosts, the dns hostname resolves to the primary interface's IP address, which isn't necessarily the interface that can talk to the host being monitored. I commented out the bind() command and it now works. If you don't bind() at all, Socket will automatically pick the interface whose routes include your destination address when you connect(). ---------------------------------------------------------------------- Comment By: Harper Mann (harpermann) Date: 2006-07-24 15:59 Message: Logged In: YES user_id=939531 This is coded correctly. You need the "canonical" host name first in the /etc/hosts file so it's recognizedc by the remote system. >From the "hosts" /etc/hosts man page: "IP_address canonical_hostname aliases" Example: "127.0.0.1 localhost 192.168.1.10 foo.mydomain.org foo" Check_ircd works correctly if hosts are set properly with FQDN in DNS or /etc/hosts. [hmann at sirius plugins-scripts]$ ./check_ircd -w 4000 -c 5000 -H niven.freenode.net IRCD ok - Current Local Users: 3929 [hmann at sirius plugins-scripts]$ echo $? 0 Closing this one.. - Harper ---------------------------------------------------------------------- Comment By: Matthew Kent (mattkent) Date: 2004-12-05 17:31 Message: Logged In: YES user_id=983566 I'm having this problem in my testing as well (perl, v5.8.4 debian unstable). It seems to be something broken in perl's socket code. It's mentioned here http://wiki.apache.org/spamassassin/IoSocketInetInvalidArgument The solution for me was to remove my computers hostname from the /etc/hosts loopback 127.0.0.1 azul localhost to 127.0.0.1 localhost and poof it works... strange problem indeed! ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2004-11-23 19:50 Message: Logged In: YES user_id=664364 Moving to Bugs tracker as Support Requests will be closed. ---------------------------------------------------------------------- Comment By: Stanley Hopcroft (stanleyhopcroft) Date: 2004-11-22 23:56 Message: Logged In: YES user_id=395628 I can't repeat this behaviour (ie invalid argument -H) with check_ircd in the 1.4 alpha plugins release (check_ircd (nagios-plugins 1.4.0alpha2) 1.3). Would you retry with this release ? (Unfortch I can't test the plugin function). ---------------------------------------------------------------------- Comment By: Stanley Hopcroft (stanleyhopcroft) Date: 2004-11-22 22:06 Message: Logged In: YES user_id=395628 I can't repeat this behaviour (ie invalid argument -H) with check_ircd in the 1.4 alpha plugins release (check_ircd (nagios-plugins 1.4.0alpha2) 1.3). Would you retry with this release ? (Unfortch I can't test the plugin function). ---------------------------------------------------------------------- Comment By: Subhendu Ghosh (sghosh) Date: 2003-01-16 00:58 Message: Logged In: YES user_id=46572 Is your IRC server running on port 6667 ?? Please followup on the mailing list. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=668778&group_id=29880 From dermoth at aei.ca Fri Sep 18 09:17:31 2009 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Fri, 18 Sep 2009 03:17:31 -0400 Subject: [Nagiosplug-devel] Patch for persistent data on plugins In-Reply-To: <20090917110449.GM16365@phcomp.co.uk> References: <20090916113948.GA2066@phcomp.co.uk> <4AB1D1C0.5070706@aei.ca> <20090917110449.GM16365@phcomp.co.uk> Message-ID: <4AB3340B.7@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 17/09/09 07:04 AM, Alain Williams wrote: > On Thu, Sep 17, 2009 at 02:05:52AM -0400, Thomas Guyot-Sionnest wrote: Thanks for quickly addressing these issues! >> My take on this...: >> >> 1. Tests should use libtap, > > I didn't see that, it is not referenced in an appropriate README. > I'll look at it. Use --enable-libtap on the configure line if you don't have it installed. Libtab tests are in /lib/tests/. >> and lets remove those goto's before someone >> else see them ;) > > There are no gotos in state_save.c > There are a few in the test program and in check_procs.c -- they are used > how a goto should be used -- in an error state and to increase clarity; one target > in a function does not confuse and avoids excessive nested {}. > Summary: without goto the code becomes more complicated/difficult-to-read. Ok... well actually I believe code should be much simpler anyway... see below. >> 2. Doc should go in the docbook, not a plain text file (if there are too >> technical portions those could be be code comments > > I cannot see anything called docbook in the plugins tar file ? in /docs. This is called the "developer guidelines" and is in docbook format... don't bother too much with if though if you're uncomfortable with docbook, it's mostly a copy-paste + adding some formatting job. >> 3. A plugin shouldn't share state file for multiple different >> invocations. Plugins may run in parallel so this is asking for trouble >> (one invocation overwriting another plugin's data). That also call for a >> much simpler API and plugin code. > > That is why the functions have the 'instance' argument, from my documentation: > > name This should be the name of the program > instance If the program may be run several times (eg to monitor different > disks) this should contain a way of distinguishing the different > instances. If this is not needed it should be NULL. > Neither name not instance should contain spaces or slashes ('/'). > > An instance may be 'sda', 'sdb', ... for something that is monitoring disks. > > I have added a bit more to the documentation of np_state_save_start(). Yes, but that's not how you apparently used it in check_procs (or did you?- maybe it's for storing multiple invocations of the same data though). I'll have a deeper look at that if you don't, but I feel both the API and the plugin code could be simpler... I was thinking of something that store a single blob (no matter if it's binary or ascii, although one function could exist for each) and the plugin could give a meaning to this "blob" (records, serialisation, etc.). I'm not a heavy check_proc user but I was under the impression it checks one thing at time, so there shouldn't be more tan one set of values to store per invocation. Am I wrong? >> 4. Should we write a temp file first and move it over instead of >> truncating it? IMHO the former is much better is the file is not opened >> and saver at once... > > That could be done. I don't think that it worth the extra complexity. > There will only be an error if something really nasty happens (eg out of > disk space). If state is lost then a warning may be lost, but if a disk > has gone full - worse things are afoot. > If a state file is corrupt then the plugin will probably rewrite it with > fresh/clean state information. > > I won't do anything without further discussion. Atomicity. Although it shouldn't happen, if the same plugin instance is invoked twice then worst case if that one run's data will be overwritten by the other (should give pretty much the same result if it's the same check). Without it, both plugin will write their own data in the same file, which is likely to cause corruption. This is less a problem if the open and write is triggered by a single function call (which is not the case afaik), but there's still place for a race. > It might make sense if the nagios plugin state files were removed on > nagios start (but not reload) anyway: discuss. Not IMHO. Even the perfdata method retains data with state retention... Some people restart nagios *very* often too, that would be an issue for them. >> 8. I don't think the descripting/comments should go in there. They could >> be added manually or trough a serialization library, but in most cases >> the pluginj's verbose mode should be enough to debug. > > That is if you understand what is generating the file. Remember that people who > are new to this have problems understanding how it all hangs together. > I found the comments useful when debugging check_procs. > Typically the comments will be just: plugin name & command line args; date in human > understandable format; a DO NOT EDIT line. The over head is 100-200 bytes. > (See later discussion) Well, my fear is that more space might be occupied by the header and comments than by the data itself In some plugins all I need is the time and an integer; this is no more than 8 bytes in binary and probably no more than 16 in ascii/hex. ... and as explained making sure we're as small as possible will ensure best performance, either through the use of tail files (much faster with less space waste on FS that support it or less waste of memory on tmpfs filesystems (RAM). >> 9. On some unix unlink() may damage file system if the path is a >> directory and the plugin is run as root. Any sysadmin ending up in that >> situation should be shot in the head, but it's an easy check... > > I use unlink() in np_state_destroy_save() to remove the state file. This is > not a directory. I have modified the internal function generate_filename() > to check & return an error if: name is empty or: name or instance contain > a space or '/'. That will prevent trying to unlink a directory. > > Changes in my private version that I will repost when appropriate. I know it's dumb, but my fear was: rm path//to/state_file; mkdir /path/to/state_file then run the plugin... Remember murphy's law: if there's the slightest possibility of something going wrong it will happen. :) >> 12. I'd suggest having all files prefixed with "np_" instead of using >> some sort of heuristic to determine whenever we should add >> "nagios-plugin_" (bonus point: making prefix a configure parameter). > > That is only if DIR_DEFAULT is used, ie it is in /tmp. > Making it a configure option (your point 10) fixes this (ie it is > the same thing). > > One point that you did NOT make that I thought you might is my use of > the environment variable NAGIOS_PLUGIN_STATE_DIRECTORY. I can't see > a simple way of avoiding this without adding complexity to the plugins > (which is something that I wanted to avoid). It would be nice if there > was some nagios support for this -- ie a nagios config parameter that > makes it set this env var, rather than having to set this in the > environment before calling nagios. My point is that having a prefix everywhere (but a smaller one) won't hurt, and it won't use different name whenever you leave it the default of change it. I didn't like that the the file name was changing *implicitely*. >> 13. I like the ascii header, but I'd use a more compact version. This >> ensure state files are as small as possible, preventing waste (very >> useful when a tmpfs is used for storage and helping usage of tail files >> on fs that support it). > > Hmmm, it is a trade off between compactness and ease of understanding by the > nagios newbie system admin. A quick look at those generated by the test > program shows that the header length is less than 180 chars. > For those that have not seen it we are talking about a header like: If this is done properly the newbiew will not have to worry about whatever is in the state file. It's probably better actually to make sure they won't mess with it because it appears they can! > I Nagios Plugin State File > # This is generated by the plugin - DO NOT HAND EDIT > # Plugin id: test instance: array > V 1 > # File written: Fri Sep 11 18:33:50 2009 > T 4aaa89fe > B 1 > N 11 > > Removing the comments takes that down to 52 bytes (from 179). > I could do something like testing for env var > NAGIOS_PLUGIN_STATE_NO_COMMENT and suppress the comments, > but is that worth it ? Not just the comments... I would compact the header in one small line.. just enough readable to recognise/decode it manually without scarifying much space for it. > ''Nagios Plugin State File'' is 24 chars & could be shortened, > I made is explicit so that if a sysadmin found the file and asked > the question ''what is this file ?'' that it would be an easy answer. What about adding a file(1) signature? Besides, it should be stored in a nagios-related directory... >> 14. There's no additional tests in check_procs.t > > Hmmmm: what is the purpose of the extra checks ? > I could check parsing of command line args. Checking of saved state > is really difficult (what is happening on the system that the test is > being run on ?). > The main thing to test is the save/restore of test data - this is what > the plugin_save_test.c does. It's a real-world test, making sure the plugin runs fine with it. Your library tests don't test individual plugin's data save and restore routines. for instance. - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKszQL6dZ+Kt5BchYRAtxLAJ0SZvOswSRLyZc6mxI6PG18VqDLYQCg1c76 bMAp0kaLsYIQ1Hgd/YulgtI= =TxfR -----END PGP SIGNATURE----- From noreply at sourceforge.net Sat Sep 19 00:21:41 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 Sep 2009 22:21:41 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2861789 ] memory leak Message-ID: Bugs item #2861789, was opened at 2009-09-19 00:21 Message generated for change (Tracker Item Submitted) made by franck78 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2861789&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: v1.4.14 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Franck Bourdonnec (franck78) Assigned to: Nobody/Anonymous (nobody) Summary: memory leak Initial Comment: the check_smtp.c plugin have malloc() used (line 144) and no corresponding free() Should be converted into buffer allocated on stack. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2861789&group_id=29880 From noreply at sourceforge.net Sat Sep 19 07:28:00 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 19 Sep 2009 05:28:00 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2861789 ] memory leak Message-ID: Bugs item #2861789, was opened at 2009-09-18 18:21 Message generated for change (Settings changed) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2861789&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: v1.4.14 >Status: Pending >Resolution: Later Priority: 5 Private: No Submitted By: Franck Bourdonnec (franck78) Assigned to: Nobody/Anonymous (nobody) Summary: memory leak Initial Comment: the check_smtp.c plugin have malloc() used (line 144) and no corresponding free() Should be converted into buffer allocated on stack. ---------------------------------------------------------------------- >Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-09-19 01:27 Message: If you start tracking every memory allocation leak in nagios plugins you'll find hundreds (or maybe even thousands) of them. The truth is that plugins runs for a very short time and it is much faster to let the OS reclaim the memory on process exit than reclaiming it with free(). OTOH I'm not against it; the difference is not very significant and it could be useful in the future. For example the plugins code could be loaded by a daemon instead of running in standalone plugins. It's not the case right now so this is not a priority. I'm marking this bug as Pending/Later for now. Feel free to comment if you think the memory leakage within a single run could be so significant this is problematic, of if you want to attach an acceptable fix for it. Otherwise it's just not a priority. Thanks for reporting bugs against the Nagios Plugins though, this is always appreciated. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2861789&group_id=29880 From noreply at sourceforge.net Sat Sep 19 08:09:21 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 19 Sep 2009 06:09:21 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-668778 ] check_ircd - invalid argument Message-ID: Bugs item #668778, was opened at 2003-01-15 17:51 Message generated for change (Settings changed) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=668778&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Harper Mann (harpermann) Summary: check_ircd - invalid argument Initial Comment: Any ideas what im doing wrong here libexec]# ./check_ircd -v -H xxx.xxx.xxx.xxx MAIN(debug): hostname = something.host.name MAIN(debug): binding to remote host: xxx.xxx.xxx.xxx - > 6667 -> something.host.name IRCD UNKNOWN: Could not connect socket (Invalid argument) something.host.name and xxx.xxx.xxx.xxx are valid hostnames and ips just edited out in this post I get the same (IRCD UNKNOWN: Could not connect socket (Invalid argument)) as status when it is run by nagios. ./check_ircd -V check_ircd (nagios-plugins 1.3.0-beta2) 1.3 The nagios plugins come with ABSOLUTELY NO WARRANTY. You may redistribute copies of the plugins under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING. This is when it is run in its unmodified form installed from source and compiled, or usign an rpm build Thanks in advance for any advice. Sarah ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-09-19 02:09 Message: This problem is now fixed in Git. Thank you for your report. ---------------------------------------------------------------------- Comment By: David Miller (justdave72) Date: 2009-09-18 02:32 Message: The problem seems to be that check_ircd is attempting to bind to the interface that goes with the machine's primary hostname. In many cases that's not correct. I was also getting this error if I had my hostname assigned to 127.0.0.1 in /etc/hosts, but removing that caused a timeout. This is because my monitoring host has interfaces on several vlans, and without the entry in /etc/hosts, the dns hostname resolves to the primary interface's IP address, which isn't necessarily the interface that can talk to the host being monitored. I commented out the bind() command and it now works. If you don't bind() at all, Socket will automatically pick the interface whose routes include your destination address when you connect(). ---------------------------------------------------------------------- Comment By: Harper Mann (harpermann) Date: 2006-07-24 15:59 Message: Logged In: YES user_id=939531 This is coded correctly. You need the "canonical" host name first in the /etc/hosts file so it's recognizedc by the remote system. >From the "hosts" /etc/hosts man page: "IP_address canonical_hostname aliases" Example: "127.0.0.1 localhost 192.168.1.10 foo.mydomain.org foo" Check_ircd works correctly if hosts are set properly with FQDN in DNS or /etc/hosts. [hmann at sirius plugins-scripts]$ ./check_ircd -w 4000 -c 5000 -H niven.freenode.net IRCD ok - Current Local Users: 3929 [hmann at sirius plugins-scripts]$ echo $? 0 Closing this one.. - Harper ---------------------------------------------------------------------- Comment By: Matthew Kent (mattkent) Date: 2004-12-05 17:31 Message: Logged In: YES user_id=983566 I'm having this problem in my testing as well (perl, v5.8.4 debian unstable). It seems to be something broken in perl's socket code. It's mentioned here http://wiki.apache.org/spamassassin/IoSocketInetInvalidArgument The solution for me was to remove my computers hostname from the /etc/hosts loopback 127.0.0.1 azul localhost to 127.0.0.1 localhost and poof it works... strange problem indeed! ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2004-11-23 19:50 Message: Logged In: YES user_id=664364 Moving to Bugs tracker as Support Requests will be closed. ---------------------------------------------------------------------- Comment By: Stanley Hopcroft (stanleyhopcroft) Date: 2004-11-22 23:56 Message: Logged In: YES user_id=395628 I can't repeat this behaviour (ie invalid argument -H) with check_ircd in the 1.4 alpha plugins release (check_ircd (nagios-plugins 1.4.0alpha2) 1.3). Would you retry with this release ? (Unfortch I can't test the plugin function). ---------------------------------------------------------------------- Comment By: Stanley Hopcroft (stanleyhopcroft) Date: 2004-11-22 22:06 Message: Logged In: YES user_id=395628 I can't repeat this behaviour (ie invalid argument -H) with check_ircd in the 1.4 alpha plugins release (check_ircd (nagios-plugins 1.4.0alpha2) 1.3). Would you retry with this release ? (Unfortch I can't test the plugin function). ---------------------------------------------------------------------- Comment By: Subhendu Ghosh (sghosh) Date: 2003-01-16 00:58 Message: Logged In: YES user_id=46572 Is your IRC server running on port 6667 ?? Please followup on the mailing list. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=668778&group_id=29880 From noreply at sourceforge.net Mon Sep 21 22:14:19 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 21 Sep 2009 20:14:19 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2863772 ] check_disk shows bad results on OS X Message-ID: Bugs item #2863772, was opened at 2009-09-21 16:14 Message generated for change (Tracker Item Submitted) made by acranox You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2863772&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parsing problem Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Peter Doherty (acranox) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk shows bad results on OS X Initial Comment: check_disk is reporting incorrect information for the large filesystem on a PPC Xserve. It's NFS mounted. It used to work, and then it spontaneously stopped working, I think once the disk had more than 2TB of data on it. Using -x provides some information, but it's wrong. # ~/check_disk -w 10% -c 5% -p /galactica/battlestar/ DISK CRITICAL - free space: /galactica/battlestar 0 MB (0% inode=63%);| /galactica/battlestar=2147483647MB;559964;591073;0;622183 # df Filesystem 512-blocks Used Available Capacity Mounted on /dev/disk0s10 1562355920 1059936744 501907176 68% / map -static 0 0 0 100% /galactica/battlestar 192.168.1.213:/Volumes/battlestar 18454101336 6669463232 11784638104 37% /galactica/battlestar # df -h Filesystem Size Used Avail Capacity Mounted on /dev/disk0s10 745Gi 505Gi 239Gi 68% / map -static 0Bi 0Bi 0Bi 100% /galactica/battlestar 192.168.1.213:/Volumes/battlestar 8.6Ti 3.1Ti 5.5Ti 37% /galactica/battlestar # uname -a Darwin 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:57:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_PPC Power Macintosh # ~/check_disk -x 192.168.1.213:/Volumes/battlestar DISK OK - free space: / 245071 MB (32% inode=32%); /dev 0 MB (0% inode=98%);| /=517547MB;;;0;762869 /dev=0MB;;;0;0 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2863772&group_id=29880 From bryair01 at noa.nintendo.com Mon Sep 21 23:15:09 2009 From: bryair01 at noa.nintendo.com (Bryan Irvine) Date: Mon, 21 Sep 2009 14:15:09 -0700 Subject: [Nagiosplug-devel] check_http patch Message-ID: <265566AA9428654EB96E974CEE0087A70699B419BC@EX-MB2.noa.nintendo.com> Would you please incorporate the patch found here: http://sourceforge.net/tracker/?func=detail&aid=1323230&group_id=29880&atid=397599 I've verified the patch compiles and works as expected in our environment. Thanks, -Bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From nagios at its.washco.utah.gov Tue Sep 22 00:44:56 2009 From: nagios at its.washco.utah.gov (Jason Abraham) Date: Mon, 21 Sep 2009 16:44:56 -0600 Subject: [Nagiosplug-devel] Alarm problems In-Reply-To: <000001ca3639$48bd1ef0$da375cd0$@Abraham@washco.utah.gov> References: <000001ca3639$48bd1ef0$da375cd0$@Abraham@washco.utah.gov> Message-ID: <000101ca3b0d$2430ec00$6c92c400$@washco.utah.gov> Perhaps I was not very clear with my question. Nagios::Plugin::GetOpt defines a $SIG{ALRM} handler. I use this alarm handler in my code: alarm($np->opt>timeout) I realize that I can call alarm(0) to disable the alarm. However, if my plugin makes multiple network calls shouldn't the timeout value apply to the entire plugin and not each individual network call? If I wish to accomplish a global plugin network timeout I can start my network code section with alarm($np->opt>timeout) and end it with alarm(0). However, inside this code I have various tests which result in calls to nagios_exit/nagios_die. As things stand I would have to proceed each nagios_exit/die call With alarm(0) which can quickly become cumbersome. Why doesn't Nagios:Plugin:Functions call alarm(0) by default on exit? A lingering alarm may be no problem when a script is executed standalone. But won't a lingering alarm cause problems with Nagios's embedded perl engine? Jason Abraham -----Original Message----- From: Jason Abraham [mailto:Jason.Abraham at washco.utah.gov] Sent: Tuesday, September 15, 2009 1:18 PM To: nagiosplug-devel at lists.sourceforge.net Subject: [Nagiosplug-devel] Alarm problems I have created a plugin which uses SNMP (http://www.washco.utah.gov/meej/check_3com_alive.txt) and as such I have employed the recommended alarm safe-guard ---- # start counting down to timeout alarm $plugin->opts->timeout; your_long_check_step_that_might_time_out(); ---- I use Nagios::Plugin to handle my exit state (nagios_exit). When testing the plugin with new_mini_epn it functions correctly and returns the correct codes. However, if I execute my plugin via new_mini_epn and then wait I eventually get the an alarm error: ----- ./new_mini_epn plugin command line: check_3com_alive.pl -H 10.0.0.10 -C pass -n 3 embedded perl plugin return code and output was: 0 & 3COM_ALIVE OK - 3 of 3 units in stack plugin command line: CHECK_3COM_ALIVE.PL UNKNOWN - plugin timed out (timeout 15s) ExitTrap: 3 (Redefine exit to trap plugin exit with eval BLOCK) at p1.pl line 61, line 1. ----- Obviously, the alarm timer is still left running even after calling nagios_exit. Is this a problem with my code, Nagios::Plugin, or is it even a problem at all? I am using nagios-plugins-1.4.13 Thanks, Jason From noreply at sourceforge.net Tue Sep 22 00:48:09 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 21 Sep 2009 22:48:09 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1323230 ] check_http proxy-authorization option Message-ID: Patches item #1323230, was opened at 2005-10-10 15:41 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1323230&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Enhancement Group: None Status: Open >Resolution: Out of Date Priority: 5 Private: No Submitted By: Marcel Kuiper (ku1111) >Assigned to: Thomas Guyot-Sionnest (dermoth) Summary: check_http proxy-authorization option Initial Comment: I've added an option (-b, --proxy-authorization user:password) for doing basic Proxy-Authorization with check_http. (Plus added --authorization to the long optionlist as the help describes) Patch is against version 1.81 of check_httpd.c in context diff format Hopefully this will be incoporated in some form in a next relelase THNX Marcel Kuiper ---------------------------------------------------------------------- >Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-09-21 18:48 Message: This patch won't apply to the current release. Unified diff's (diff -u) are also preferred. I *could* apply and test it myself, but this is unlikely considering the little time I have for that. If you can provide a patch that apply to 1.4.14 in unified diff format I will run basic tests and apply it. Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1323230&group_id=29880 From dermoth at aei.ca Tue Sep 22 00:49:34 2009 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Mon, 21 Sep 2009 18:49:34 -0400 Subject: [Nagiosplug-devel] check_http patch In-Reply-To: <265566AA9428654EB96E974CEE0087A70699B419BC@EX-MB2.noa.nintendo.com> References: <265566AA9428654EB96E974CEE0087A70699B419BC@EX-MB2.noa.nintendo.com> Message-ID: <4AB802FE.4000702@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 21/09/09 05:15 PM, Bryan Irvine wrote: > Would you please incorporate the patch found here: > > http://sourceforge.net/tracker/?func=detail&aid=1323230&group_id=29880&atid=397599 > > > > > I?ve verified the patch compiles and works as expected in our environment. I updated the tracker; feel free to upload an updated patch there. Thank you - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKuAL+6dZ+Kt5BchYRAhksAJ9ixZHeH7EKS1MI8eUGzi+s6hiZbgCgvxTu 6eGhazRurJedffOoK/+ztVQ= =EVmG -----END PGP SIGNATURE----- From noreply at sourceforge.net Tue Sep 22 00:56:59 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 21 Sep 2009 22:56:59 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2863772 ] check_disk shows bad results on OS X Message-ID: Bugs item #2863772, was opened at 2009-09-21 16:14 Message generated for change (Settings changed) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2863772&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parsing problem Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Peter Doherty (acranox) >Assigned to: Thomas Guyot-Sionnest (dermoth) Summary: check_disk shows bad results on OS X Initial Comment: check_disk is reporting incorrect information for the large filesystem on a PPC Xserve. It's NFS mounted. It used to work, and then it spontaneously stopped working, I think once the disk had more than 2TB of data on it. Using -x provides some information, but it's wrong. # ~/check_disk -w 10% -c 5% -p /galactica/battlestar/ DISK CRITICAL - free space: /galactica/battlestar 0 MB (0% inode=63%);| /galactica/battlestar=2147483647MB;559964;591073;0;622183 # df Filesystem 512-blocks Used Available Capacity Mounted on /dev/disk0s10 1562355920 1059936744 501907176 68% / map -static 0 0 0 100% /galactica/battlestar 192.168.1.213:/Volumes/battlestar 18454101336 6669463232 11784638104 37% /galactica/battlestar # df -h Filesystem Size Used Avail Capacity Mounted on /dev/disk0s10 745Gi 505Gi 239Gi 68% / map -static 0Bi 0Bi 0Bi 100% /galactica/battlestar 192.168.1.213:/Volumes/battlestar 8.6Ti 3.1Ti 5.5Ti 37% /galactica/battlestar # uname -a Darwin 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:57:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_PPC Power Macintosh # ~/check_disk -x 192.168.1.213:/Volumes/battlestar DISK OK - free space: / 245071 MB (32% inode=32%); /dev 0 MB (0% inode=98%);| /=517547MB;;;0;762869 /dev=0MB;;;0;0 ---------------------------------------------------------------------- >Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-09-21 18:56 Message: You did not specify the release you're using. If you're not using 1.4.12 or later this is a known bug. Please try against the latest version of nagios-plugins. If you can reproduce it, please sent the output with "-vvv", your config.log and the strace-like output (on Darwin I believe the command is ktrace) of both check_disk and df. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2863772&group_id=29880 From noreply at sourceforge.net Tue Sep 22 02:42:48 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Sep 2009 00:42:48 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2863925 ] check_http basic auth patch Message-ID: Patches item #2863925, was opened at 2009-09-21 17:42 Message generated for change (Tracker Item Submitted) made by bmirvine You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2863925&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Enhancement Group: release-1.4.14 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bryan Irvine (bmirvine) Assigned to: Nobody/Anonymous (nobody) Summary: check_http basic auth patch Initial Comment: Adds basic proxy auth to check_http ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2863925&group_id=29880 From bryair01 at noa.nintendo.com Tue Sep 22 02:44:03 2009 From: bryair01 at noa.nintendo.com (Bryan Irvine) Date: Mon, 21 Sep 2009 17:44:03 -0700 Subject: [Nagiosplug-devel] check_http patch In-Reply-To: <4AB802FE.4000702@aei.ca> References: <265566AA9428654EB96E974CEE0087A70699B419BC@EX-MB2.noa.nintendo.com> <4AB802FE.4000702@aei.ca> Message-ID: <265566AA9428654EB96E974CEE0087A70699B41AA7@EX-MB2.noa.nintendo.com> I might be a dummy, did I submit this correctly? https://sourceforge.net/tracker/?func=detail&aid=2863925&group_id=29880&atid=397599 -Bryan -----Original Message----- From: Thomas Guyot-Sionnest [mailto:dermoth at aei.ca] Sent: Monday, September 21, 2009 3:50 PM To: Nagios Plugin Development Mailing List Subject: Re: [Nagiosplug-devel] check_http patch -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 21/09/09 05:15 PM, Bryan Irvine wrote: > Would you please incorporate the patch found here: > > http://sourceforge.net/tracker/?func=detail&aid=1323230&group_id=29880&atid=397599 > > > > > I?ve verified the patch compiles and works as expected in our environment. I updated the tracker; feel free to upload an updated patch there. Thank you - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKuAL+6dZ+Kt5BchYRAhksAJ9ixZHeH7EKS1MI8eUGzi+s6hiZbgCgvxTu 6eGhazRurJedffOoK/+ztVQ= =EVmG -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________________ Nagios Plugin Development Mailing List Nagiosplug-devel at lists.sourceforge.net Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel ::: Please include plugins version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null From noreply at sourceforge.net Tue Sep 22 03:20:47 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Sep 2009 01:20:47 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2863925 ] check_http basic auth patch Message-ID: Patches item #2863925, was opened at 2009-09-21 20:42 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2863925&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Enhancement Group: release-1.4.14 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Bryan Irvine (bmirvine) Assigned to: Nobody/Anonymous (nobody) Summary: check_http basic auth patch Initial Comment: Adds basic proxy auth to check_http ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-09-21 21:20 Message: This problem is now fixed in Git. Thank you for your report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2863925&group_id=29880 From noreply at sourceforge.net Tue Sep 22 03:23:32 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Sep 2009 01:23:32 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1323230 ] check_http proxy-authorization option Message-ID: Patches item #1323230, was opened at 2005-10-10 15:41 Message generated for change (Settings changed) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1323230&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Enhancement Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Marcel Kuiper (ku1111) Assigned to: Thomas Guyot-Sionnest (dermoth) Summary: check_http proxy-authorization option Initial Comment: I've added an option (-b, --proxy-authorization user:password) for doing basic Proxy-Authorization with check_http. (Plus added --authorization to the long optionlist as the help describes) Patch is against version 1.81 of check_httpd.c in context diff format Hopefully this will be incoporated in some form in a next relelase THNX Marcel Kuiper ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-09-21 21:23 Message: This problem is now fixed in Git. Thank you for your report. ---------------------------------------------------------------------- Comment By: Bryan Irvine (bmirvine) Date: 2009-09-21 20:39 Message: Of course. I had a patch on friday that applied to 1.4.13. ;-) I've now tested with 1.4.14 and it works: -bash-3.2$ ./check_http proxy.example.com -p 8080 -u http://www.google.com HTTP WARNING: HTTP/1.1 407 Proxy Authentication Required - 7258 bytes in 0.003 second response time |time=0.003167s;;;0.000000 size=7258B;;;0 -bash-3.2$ ./check_http -b user:pass proxy.example.com -p 8080 -u http://www.google.com HTTP OK: HTTP/1.1 200 OK - 5773 bytes in 0.249 second response time |time=0.249411s;;;0.000000 size=5773B;;;0 ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-09-21 18:48 Message: This patch won't apply to the current release. Unified diff's (diff -u) are also preferred. I *could* apply and test it myself, but this is unlikely considering the little time I have for that. If you can provide a patch that apply to 1.4.14 in unified diff format I will run basic tests and apply it. Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1323230&group_id=29880 From dermoth at aei.ca Tue Sep 22 03:24:54 2009 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Mon, 21 Sep 2009 21:24:54 -0400 Subject: [Nagiosplug-devel] check_http patch In-Reply-To: <265566AA9428654EB96E974CEE0087A70699B41AA7@EX-MB2.noa.nintendo.com> References: <265566AA9428654EB96E974CEE0087A70699B419BC@EX-MB2.noa.nintendo.com> <4AB802FE.4000702@aei.ca> <265566AA9428654EB96E974CEE0087A70699B41AA7@EX-MB2.noa.nintendo.com> Message-ID: <4AB82766.5000707@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 21/09/09 08:44 PM, Bryan Irvine wrote: > I might be a dummy, did I submit this correctly? > > https://sourceforge.net/tracker/?func=detail&aid=2863925&group_id=29880&atid=397599 You could have uploaded directly to the original tracker... Other than that, awesome! I applied it. - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKuCdm6dZ+Kt5BchYRAqcGAKDryF0KI3S8Eb9DOw3Lhdg+pD3c2QCfT5Dd VzRbsAWGL9jFpnjVJse7vfY= =k0KF -----END PGP SIGNATURE----- From noreply at sourceforge.net Tue Sep 22 02:39:24 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Sep 2009 00:39:24 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1323230 ] check_http proxy-authorization option Message-ID: Patches item #1323230, was opened at 2005-10-10 12:41 Message generated for change (Comment added) made by bmirvine You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1323230&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Enhancement Group: None Status: Open Resolution: Out of Date Priority: 5 Private: No Submitted By: Marcel Kuiper (ku1111) Assigned to: Thomas Guyot-Sionnest (dermoth) Summary: check_http proxy-authorization option Initial Comment: I've added an option (-b, --proxy-authorization user:password) for doing basic Proxy-Authorization with check_http. (Plus added --authorization to the long optionlist as the help describes) Patch is against version 1.81 of check_httpd.c in context diff format Hopefully this will be incoporated in some form in a next relelase THNX Marcel Kuiper ---------------------------------------------------------------------- Comment By: Bryan Irvine (bmirvine) Date: 2009-09-21 17:39 Message: Of course. I had a patch on friday that applied to 1.4.13. ;-) I've now tested with 1.4.14 and it works: -bash-3.2$ ./check_http proxy.example.com -p 8080 -u http://www.google.com HTTP WARNING: HTTP/1.1 407 Proxy Authentication Required - 7258 bytes in 0.003 second response time |time=0.003167s;;;0.000000 size=7258B;;;0 -bash-3.2$ ./check_http -b user:pass proxy.example.com -p 8080 -u http://www.google.com HTTP OK: HTTP/1.1 200 OK - 5773 bytes in 0.249 second response time |time=0.249411s;;;0.000000 size=5773B;;;0 ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-09-21 15:48 Message: This patch won't apply to the current release. Unified diff's (diff -u) are also preferred. I *could* apply and test it myself, but this is unlikely considering the little time I have for that. If you can provide a patch that apply to 1.4.14 in unified diff format I will run basic tests and apply it. Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1323230&group_id=29880 From bryair01 at noa.nintendo.com Tue Sep 22 18:22:15 2009 From: bryair01 at noa.nintendo.com (Bryan Irvine) Date: Tue, 22 Sep 2009 09:22:15 -0700 Subject: [Nagiosplug-devel] check_http patch In-Reply-To: <4AB82766.5000707@aei.ca> References: <265566AA9428654EB96E974CEE0087A70699B419BC@EX-MB2.noa.nintendo.com> <4AB802FE.4000702@aei.ca> <265566AA9428654EB96E974CEE0087A70699B41AA7@EX-MB2.noa.nintendo.com> <4AB82766.5000707@aei.ca> Message-ID: <265566AA9428654EB96E974CEE0087A70699B41B28@EX-MB2.noa.nintendo.com> I had a feeling I was doing it wrong but couldn't see the other way. (: Oh well. Does this get applied to the current 1.4.14? or do I need to wait for 1.4.15? -Bryan -----Original Message----- From: Thomas Guyot-Sionnest [mailto:dermoth at aei.ca] Sent: Monday, September 21, 2009 6:25 PM To: Nagios Plugin Development Mailing List Subject: Re: [Nagiosplug-devel] check_http patch -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 21/09/09 08:44 PM, Bryan Irvine wrote: > I might be a dummy, did I submit this correctly? > > https://sourceforge.net/tracker/?func=detail&aid=2863925&group_id=29880&atid=397599 You could have uploaded directly to the original tracker... Other than that, awesome! I applied it. - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKuCdm6dZ+Kt5BchYRAqcGAKDryF0KI3S8Eb9DOw3Lhdg+pD3c2QCfT5Dd VzRbsAWGL9jFpnjVJse7vfY= =k0KF -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________________ Nagios Plugin Development Mailing List Nagiosplug-devel at lists.sourceforge.net Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel ::: Please include plugins version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null From dermoth at aei.ca Tue Sep 22 20:29:05 2009 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Tue, 22 Sep 2009 14:29:05 -0400 Subject: [Nagiosplug-devel] check_http patch In-Reply-To: <265566AA9428654EB96E974CEE0087A70699B41B28@EX-MB2.noa.nintendo.com> References: <265566AA9428654EB96E974CEE0087A70699B419BC@EX-MB2.noa.nintendo.com> <4AB802FE.4000702@aei.ca> <265566AA9428654EB96E974CEE0087A70699B41AA7@EX-MB2.noa.nintendo.com> <4AB82766.5000707@aei.ca> <265566AA9428654EB96E974CEE0087A70699B41B28@EX-MB2.noa.nintendo.com> Message-ID: <4AB91771.3070206@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bryan Irvine wrote: > I had a feeling I was doing it wrong but couldn't see the other way. (: > > Oh well. Does this get applied to the current 1.4.14? or do I need to wait for 1.4.15? You can apply the patch to 1.4.14 or download a daily snapshot (Which right now is 1.4.14 + 2 patches - check_ircd and check_http). The next release (1.4.15) will have the feature built in. - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkq5F3EACgkQ6dZ+Kt5BchYlmwCg/XfTOCnRbJQIZc3VIPVJ7A+J yTgAnAy3aYoZJObZac43/U3v9FQuiSh1 =Pv1S -----END PGP SIGNATURE----- From noreply at sourceforge.net Tue Sep 22 23:38:07 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Sep 2009 21:38:07 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2864596 ] 1.4.14 no longer compiles on solaris Message-ID: Bugs item #2864596, was opened at 2009-09-22 17:38 Message generated for change (Tracker Item Submitted) made by robert_sheets You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2864596&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: v1.4.14 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Robert C. Sheets (robert_sheets) Assigned to: Nobody/Anonymous (nobody) Summary: 1.4.14 no longer compiles on solaris Initial Comment: This is a regression relative to 1.4.13. Compilation aborts with the following messages: /bin/bash ../libtool --tag=CC --mode=link gcc -DNP_VERSION='"1.4.14"' -g -O2 -L. -o pst3 -m64 pst3-pst3.o -lpthread -ldl gcc -DNP_VERSION=\"1.4.14\" -g -O2 -o pst3 -m64 pst3-pst3.o -L/home/rsheets/nagios-plugins-trunk-200909221200/plugins-root -lpthread -ldl Undefined first referenced symbol in file rpl_open pst3-pst3.o ld: fatal: Symbol referencing errors. No output written to pst3 collect2: ld returned 1 exit status *** Error code 1 make: Fatal error: Command failed for target `pst3' Current working directory /home/rsheets/nagios-plugins-trunk-200909221200/plugins-root *** Error code 1 make: Fatal error: Command failed for target `all-recursive' Current working directory /home/rsheets/nagios-plugins-trunk-200909221200 *** Error code 1 make: Fatal error: Command failed for target `all' options to configure were --prefix=/opt/nagios-plugins-trunk --without-openssl OS is solaris 9 uname -a output is SunOS remedy0 5.9 Generic_118558-05 sun4u sparc SUNW,Sun-Fire-280R I'm not sure how to get make to tell me its version, but it is /usr/ccs/bin/make gcc -v reports the following: Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.1/specs Configured with: ../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls Thread model: posix gcc version 3.4.1 Please contact me if any other information would be helpful. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2864596&group_id=29880 From noreply at sourceforge.net Tue Sep 22 23:39:47 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Sep 2009 21:39:47 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2864596 ] 1.4.14 no longer compiles on solaris Message-ID: Bugs item #2864596, was opened at 2009-09-22 17:38 Message generated for change (Comment added) made by robert_sheets You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2864596&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: v1.4.14 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Robert C. Sheets (robert_sheets) Assigned to: Nobody/Anonymous (nobody) Summary: 1.4.14 no longer compiles on solaris Initial Comment: This is a regression relative to 1.4.13. Compilation aborts with the following messages: /bin/bash ../libtool --tag=CC --mode=link gcc -DNP_VERSION='"1.4.14"' -g -O2 -L. -o pst3 -m64 pst3-pst3.o -lpthread -ldl gcc -DNP_VERSION=\"1.4.14\" -g -O2 -o pst3 -m64 pst3-pst3.o -L/home/rsheets/nagios-plugins-trunk-200909221200/plugins-root -lpthread -ldl Undefined first referenced symbol in file rpl_open pst3-pst3.o ld: fatal: Symbol referencing errors. No output written to pst3 collect2: ld returned 1 exit status *** Error code 1 make: Fatal error: Command failed for target `pst3' Current working directory /home/rsheets/nagios-plugins-trunk-200909221200/plugins-root *** Error code 1 make: Fatal error: Command failed for target `all-recursive' Current working directory /home/rsheets/nagios-plugins-trunk-200909221200 *** Error code 1 make: Fatal error: Command failed for target `all' options to configure were --prefix=/opt/nagios-plugins-trunk --without-openssl OS is solaris 9 uname -a output is SunOS remedy0 5.9 Generic_118558-05 sun4u sparc SUNW,Sun-Fire-280R I'm not sure how to get make to tell me its version, but it is /usr/ccs/bin/make gcc -v reports the following: Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.1/specs Configured with: ../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls Thread model: posix gcc version 3.4.1 Please contact me if any other information would be helpful. ---------------------------------------------------------------------- >Comment By: Robert C. Sheets (robert_sheets) Date: 2009-09-22 17:39 Message: Forgot to add to my initial report: the problem exists in 1.4.14 as well as trunk-200909221200 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2864596&group_id=29880 From noreply at sourceforge.net Wed Sep 23 07:52:38 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Sep 2009 05:52:38 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2864596 ] 1.4.14 no longer compiles on solaris Message-ID: Bugs item #2864596, was opened at 2009-09-22 17:38 Message generated for change (Settings changed) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2864596&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation >Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Robert C. Sheets (robert_sheets) >Assigned to: Thomas Guyot-Sionnest (dermoth) Summary: 1.4.14 no longer compiles on solaris Initial Comment: This is a regression relative to 1.4.13. Compilation aborts with the following messages: /bin/bash ../libtool --tag=CC --mode=link gcc -DNP_VERSION='"1.4.14"' -g -O2 -L. -o pst3 -m64 pst3-pst3.o -lpthread -ldl gcc -DNP_VERSION=\"1.4.14\" -g -O2 -o pst3 -m64 pst3-pst3.o -L/home/rsheets/nagios-plugins-trunk-200909221200/plugins-root -lpthread -ldl Undefined first referenced symbol in file rpl_open pst3-pst3.o ld: fatal: Symbol referencing errors. No output written to pst3 collect2: ld returned 1 exit status *** Error code 1 make: Fatal error: Command failed for target `pst3' Current working directory /home/rsheets/nagios-plugins-trunk-200909221200/plugins-root *** Error code 1 make: Fatal error: Command failed for target `all-recursive' Current working directory /home/rsheets/nagios-plugins-trunk-200909221200 *** Error code 1 make: Fatal error: Command failed for target `all' options to configure were --prefix=/opt/nagios-plugins-trunk --without-openssl OS is solaris 9 uname -a output is SunOS remedy0 5.9 Generic_118558-05 sun4u sparc SUNW,Sun-Fire-280R I'm not sure how to get make to tell me its version, but it is /usr/ccs/bin/make gcc -v reports the following: Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.1/specs Configured with: ../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls Thread model: posix gcc version 3.4.1 Please contact me if any other information would be helpful. ---------------------------------------------------------------------- >Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-09-23 01:52 Message: Looks like YAGB (Yet Another Gnulib Bug). Please try the attached patch: 1. Get the latest snapshot from repos.or.cz (not the daily snapsot!) http://repo.or.cz/w/nagiosplugins.git?a=snapshot;f=tgz 2. Apply the patch (see attached files below) 3. Run tools/setup (this can be done form another system like Linux if you don't have recent auto-tools on Solaris), then you can copy the directory tree to the solaris and run configure.) NB: There's a small probklem with gnulib that I haven't sorted out yet, if make fails with something like: *** /bin/bash: arpa: command not found just add MKDIR_P="mkdir -p" to your make command, i.e.: $ make MKDIR_P="mkdir -p" Please let me know if you have difficulties getting the source patched/setup'ed and I'll prepare a distrib snapshot for you ---------------------------------------------------------------------- Comment By: Robert C. Sheets (robert_sheets) Date: 2009-09-22 17:39 Message: Forgot to add to my initial report: the problem exists in 1.4.14 as well as trunk-200909221200 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2864596&group_id=29880 From noreply at sourceforge.net Wed Sep 23 12:52:46 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Sep 2009 10:52:46 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2864922 ] NTP Time Offset Message-ID: Patches item #2864922, was opened at 2009-09-23 11:52 Message generated for change (Tracker Item Submitted) made by urg987 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2864922&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Enhancement Group: release-1.4.14 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Patrick McAndrew (urg987) Assigned to: Nobody/Anonymous (nobody) Summary: NTP Time Offset Initial Comment: Not sure if this is of use or not - we have a strange requirement to run certain servers 5 minutes fast. I've added a switch to the check_ntp_time to allow for this offset. Patch against Plugin Version (-V output): check_ntp_time vtrunk.2244.dirty (nagios-plugins 1.4.14) Plugin Name: check_ntp_time Example Plugin Commandline: check_ntp_time -H ntp2c.mcc.ac.uk -o 500 Tested on operating system: CentOS release 5.3 (Final) Tested on architecture: x86_64 Tested with compiler: gcc version 4.1.2 20080704 (Red Hat 4.1.2-44) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2864922&group_id=29880 From noreply at sourceforge.net Wed Sep 23 13:01:35 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Sep 2009 11:01:35 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2864922 ] NTP Time Offset Message-ID: Patches item #2864922, was opened at 2009-09-23 06:52 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2864922&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Enhancement >Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Patrick McAndrew (urg987) >Assigned to: Thomas Guyot-Sionnest (dermoth) Summary: NTP Time Offset Initial Comment: Not sure if this is of use or not - we have a strange requirement to run certain servers 5 minutes fast. I've added a switch to the check_ntp_time to allow for this offset. Patch against Plugin Version (-V output): check_ntp_time vtrunk.2244.dirty (nagios-plugins 1.4.14) Plugin Name: check_ntp_time Example Plugin Commandline: check_ntp_time -H ntp2c.mcc.ac.uk -o 500 Tested on operating system: CentOS release 5.3 (Final) Tested on architecture: x86_64 Tested with compiler: gcc version 4.1.2 20080704 (Red Hat 4.1.2-44) ---------------------------------------------------------------------- >Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-09-23 07:01 Message: That doesn't sound right... What is your use case for this? can you show the verbose output of two runs, one with and one without that option? Thank you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2864922&group_id=29880 From noreply at sourceforge.net Wed Sep 23 13:32:25 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Sep 2009 11:32:25 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2864922 ] NTP Time Offset Message-ID: Patches item #2864922, was opened at 2009-09-23 11:52 Message generated for change (Comment added) made by urg987 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2864922&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Enhancement Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Patrick McAndrew (urg987) Assigned to: Thomas Guyot-Sionnest (dermoth) Summary: NTP Time Offset Initial Comment: Not sure if this is of use or not - we have a strange requirement to run certain servers 5 minutes fast. I've added a switch to the check_ntp_time to allow for this offset. Patch against Plugin Version (-V output): check_ntp_time vtrunk.2244.dirty (nagios-plugins 1.4.14) Plugin Name: check_ntp_time Example Plugin Commandline: check_ntp_time -H ntp2c.mcc.ac.uk -o 500 Tested on operating system: CentOS release 5.3 (Final) Tested on architecture: x86_64 Tested with compiler: gcc version 4.1.2 20080704 (Red Hat 4.1.2-44) ---------------------------------------------------------------------- >Comment By: Patrick McAndrew (urg987) Date: 2009-09-23 12:32 Message: [root at supporttools plugins]# ./check_ntp_time -H ntp2c.mcc.ac.uk -o 500 -v sending request to peer 0 response from peer 0: offset 6.841329217 sending request to peer 0 response from peer 0: offset 6.841068745 sending request to peer 0 response from peer 0: offset 6.840787172 sending request to peer 0 response from peer 0: offset 6.841123223 overall average offset: 6.841329217 NTP OK: Offset 6.841329217 secs|offset=6.841329s;60.000000;120.000000; [root at supporttools plugins]# ./check_ntp_time -H ntp2c.mcc.ac.uk -v sending request to peer 0 response from peer 0: offset -493.1589068 sending request to peer 0 response from peer 0: offset -493.1592188 sending request to peer 0 response from peer 0: offset -493.1590137 sending request to peer 0 response from peer 0: offset -493.1590893 overall average offset: -493.1589068 NTP CRITICAL: Offset -493.1589068 secs|offset=-493.158907s;60.000000;120.000000; ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-09-23 12:01 Message: That doesn't sound right... What is your use case for this? can you show the verbose output of two runs, one with and one without that option? Thank you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2864922&group_id=29880 From noreply at sourceforge.net Wed Sep 23 14:23:54 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Sep 2009 12:23:54 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2864973 ] check_ircd fails when using epn Message-ID: Bugs item #2864973, was opened at 2009-09-23 14:23 Message generated for change (Tracker Item Submitted) made by cyco_dd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2864973&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Embedded Perl failure Group: CVS Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jan Wagner (cyco_dd) Assigned to: Nobody/Anonymous (nobody) Summary: check_ircd fails when using epn Initial Comment: The following Bugreport we got against our debian package: The check_ircd plugin works just fine using the commandline using this command: /usr/lib/nagios/plugins/check_ircd -H localhost -p 1984 Configuring this command for nagios: command_line /usr/lib/nagios/plugins/check_ircd -H '$HOSTADDRESS$' -p '$ARG1$' This check will return an UNKNOWN state in nagios with an error output: "invalid port: -H" The same happens with other constellations. The solution i found on the web was to remove '-H' so that the command looks like: command_line /usr/lib/nagios/plugins/check_ircd '$HOSTADDRESS$' -p '$ARG1$' That command works just fine, so i assume there is an error in the argument parsing logic. You can track the bugreport and read the followup via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=545940 I seemed that check_ircd isn't epn ready. Attached you can find a patch which should fix the problem. Thanks and kind regards, Jan. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2864973&group_id=29880 From noreply at sourceforge.net Wed Sep 23 16:29:31 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Sep 2009 14:29:31 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2864596 ] 1.4.14 no longer compiles on solaris Message-ID: Bugs item #2864596, was opened at 2009-09-22 17:38 Message generated for change (Comment added) made by robert_sheets You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2864596&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Robert C. Sheets (robert_sheets) Assigned to: Thomas Guyot-Sionnest (dermoth) Summary: 1.4.14 no longer compiles on solaris Initial Comment: This is a regression relative to 1.4.13. Compilation aborts with the following messages: /bin/bash ../libtool --tag=CC --mode=link gcc -DNP_VERSION='"1.4.14"' -g -O2 -L. -o pst3 -m64 pst3-pst3.o -lpthread -ldl gcc -DNP_VERSION=\"1.4.14\" -g -O2 -o pst3 -m64 pst3-pst3.o -L/home/rsheets/nagios-plugins-trunk-200909221200/plugins-root -lpthread -ldl Undefined first referenced symbol in file rpl_open pst3-pst3.o ld: fatal: Symbol referencing errors. No output written to pst3 collect2: ld returned 1 exit status *** Error code 1 make: Fatal error: Command failed for target `pst3' Current working directory /home/rsheets/nagios-plugins-trunk-200909221200/plugins-root *** Error code 1 make: Fatal error: Command failed for target `all-recursive' Current working directory /home/rsheets/nagios-plugins-trunk-200909221200 *** Error code 1 make: Fatal error: Command failed for target `all' options to configure were --prefix=/opt/nagios-plugins-trunk --without-openssl OS is solaris 9 uname -a output is SunOS remedy0 5.9 Generic_118558-05 sun4u sparc SUNW,Sun-Fire-280R I'm not sure how to get make to tell me its version, but it is /usr/ccs/bin/make gcc -v reports the following: Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.1/specs Configured with: ../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls Thread model: posix gcc version 3.4.1 Please contact me if any other information would be helpful. ---------------------------------------------------------------------- >Comment By: Robert C. Sheets (robert_sheets) Date: 2009-09-23 10:29 Message: Make failed, but not as you predicted. If it matters, I applied the patch and ran tools/setup on a linux machine, as the solaris box does not have GNU Make, among other apparent prerequisites of the setup script. The patch applied cleanly. Here's the last few lines of the make output (on solaris): Making all in plugins make: Fatal error in reader: Makefile, line 1579: Unexpected end of line seen Current working directory /home/rsheets/nagiosplugins/plugins *** Error code 1 make: Fatal error: Command failed for target `all-recursive' Current working directory /home/rsheets/nagiosplugins *** Error code 1 make: Fatal error: Command failed for target `all' Line 1579 of plugins/Makefile is this: install-html: install-html-am ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-09-23 01:52 Message: Looks like YAGB (Yet Another Gnulib Bug). Please try the attached patch: 1. Get the latest snapshot from repos.or.cz (not the daily snapsot!) http://repo.or.cz/w/nagiosplugins.git?a=snapshot;f=tgz 2. Apply the patch (see attached files below) 3. Run tools/setup (this can be done form another system like Linux if you don't have recent auto-tools on Solaris), then you can copy the directory tree to the solaris and run configure.) NB: There's a small probklem with gnulib that I haven't sorted out yet, if make fails with something like: *** /bin/bash: arpa: command not found just add MKDIR_P="mkdir -p" to your make command, i.e.: $ make MKDIR_P="mkdir -p" Please let me know if you have difficulties getting the source patched/setup'ed and I'll prepare a distrib snapshot for you ---------------------------------------------------------------------- Comment By: Robert C. Sheets (robert_sheets) Date: 2009-09-22 17:39 Message: Forgot to add to my initial report: the problem exists in 1.4.14 as well as trunk-200909221200 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2864596&group_id=29880 From noreply at sourceforge.net Wed Sep 23 18:31:05 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Sep 2009 16:31:05 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2865114 ] freebsd: Message-ID: Bugs item #2865114, was opened at 2009-09-23 16:31 Message generated for change (Tracker Item Submitted) made by charlo212 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2865114&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: snapshot tarball Status: Open Resolution: None Priority: 5 Private: No Submitted By: charlo212 (charlo212) Assigned to: Nobody/Anonymous (nobody) Summary: freebsd: Initial Comment: Hi, Trying to compile the plugins on a freebsd 6.3 box. The configure stage looks okay but it fails on make with the following.... - SNIP - if gcc -DLOCALEDIR=\"/usr/local/nagios/share/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../gl -I../intl -I/usr/include -DNP_VERSION='"1.4.14"' -g -O2 -MT check_http.o -MD -MP -MF ".deps/check_http.Tpo" -c -o check_http.o check_http.c; then mv -f ".deps/check_http.Tpo" ".deps/check_http.Po"; else rm -f ".deps/check_http.Tpo"; exit 1; fi check_http.c:63: error: syntax error before '*' token check_http.c:63: warning: data definition has no type or storage class *** Error code 1 Stop in /home/nagios/nagios-plugins-trunk-200909231200/plugins. *** Error code 1 Stop in /home/nagios/nagios-plugins-trunk-200909231200. *** Error code 1 Stop in /home/nagios/nagios-plugins-trunk-200909231200. - SNIP - Host Details: uname -m = i386 uname -r = 6.3-RELEASE uname -s = FreeBSD uname -v = FreeBSD 6.3-RELEASE #3: Fri Jan 23 16:43:41 MST 2009 root at fc:/usr/src/sys/i386/compile/VKERN I've tried to upload my config.log but it's 504k and the restriction is down to 2XXk Let me know what else you'd need or if anything needs to be taken from the config.log that would help. Charlie ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2865114&group_id=29880 From noreply at sourceforge.net Wed Sep 23 18:31:32 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Sep 2009 16:31:32 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2865114 ] freebsd: fails on make Message-ID: Bugs item #2865114, was opened at 2009-09-23 16:31 Message generated for change (Settings changed) made by charlo212 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2865114&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: snapshot tarball Status: Open Resolution: None Priority: 5 Private: No Submitted By: charlo212 (charlo212) Assigned to: Nobody/Anonymous (nobody) >Summary: freebsd: fails on make Initial Comment: Hi, Trying to compile the plugins on a freebsd 6.3 box. The configure stage looks okay but it fails on make with the following.... - SNIP - if gcc -DLOCALEDIR=\"/usr/local/nagios/share/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../gl -I../intl -I/usr/include -DNP_VERSION='"1.4.14"' -g -O2 -MT check_http.o -MD -MP -MF ".deps/check_http.Tpo" -c -o check_http.o check_http.c; then mv -f ".deps/check_http.Tpo" ".deps/check_http.Po"; else rm -f ".deps/check_http.Tpo"; exit 1; fi check_http.c:63: error: syntax error before '*' token check_http.c:63: warning: data definition has no type or storage class *** Error code 1 Stop in /home/nagios/nagios-plugins-trunk-200909231200/plugins. *** Error code 1 Stop in /home/nagios/nagios-plugins-trunk-200909231200. *** Error code 1 Stop in /home/nagios/nagios-plugins-trunk-200909231200. - SNIP - Host Details: uname -m = i386 uname -r = 6.3-RELEASE uname -s = FreeBSD uname -v = FreeBSD 6.3-RELEASE #3: Fri Jan 23 16:43:41 MST 2009 root at fc:/usr/src/sys/i386/compile/VKERN I've tried to upload my config.log but it's 504k and the restriction is down to 2XXk Let me know what else you'd need or if anything needs to be taken from the config.log that would help. Charlie ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2865114&group_id=29880 From noreply at sourceforge.net Wed Sep 23 18:34:25 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Sep 2009 16:34:25 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2865114 ] freebsd: fails on make Message-ID: Bugs item #2865114, was opened at 2009-09-23 16:31 Message generated for change (Comment added) made by charlo212 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2865114&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: snapshot tarball Status: Open Resolution: None Priority: 5 Private: No Submitted By: charlo212 (charlo212) Assigned to: Nobody/Anonymous (nobody) Summary: freebsd: fails on make Initial Comment: Hi, Trying to compile the plugins on a freebsd 6.3 box. The configure stage looks okay but it fails on make with the following.... - SNIP - if gcc -DLOCALEDIR=\"/usr/local/nagios/share/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../gl -I../intl -I/usr/include -DNP_VERSION='"1.4.14"' -g -O2 -MT check_http.o -MD -MP -MF ".deps/check_http.Tpo" -c -o check_http.o check_http.c; then mv -f ".deps/check_http.Tpo" ".deps/check_http.Po"; else rm -f ".deps/check_http.Tpo"; exit 1; fi check_http.c:63: error: syntax error before '*' token check_http.c:63: warning: data definition has no type or storage class *** Error code 1 Stop in /home/nagios/nagios-plugins-trunk-200909231200/plugins. *** Error code 1 Stop in /home/nagios/nagios-plugins-trunk-200909231200. *** Error code 1 Stop in /home/nagios/nagios-plugins-trunk-200909231200. - SNIP - Host Details: uname -m = i386 uname -r = 6.3-RELEASE uname -s = FreeBSD uname -v = FreeBSD 6.3-RELEASE #3: Fri Jan 23 16:43:41 MST 2009 root at fc:/usr/src/sys/i386/compile/VKERN I've tried to upload my config.log but it's 504k and the restriction is down to 2XXk Let me know what else you'd need or if anything needs to be taken from the config.log that would help. Charlie ---------------------------------------------------------------------- >Comment By: charlo212 (charlo212) Date: 2009-09-23 16:34 Message: Also to note, that this fails the same with the stable and snapshot version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2865114&group_id=29880 From John.Carroll at govdelivery.com Wed Sep 23 23:06:05 2009 From: John.Carroll at govdelivery.com (John Patrick Carroll) Date: Wed, 23 Sep 2009 16:06:05 -0500 Subject: [Nagiosplug-devel] check_users Nagios plugin Message-ID: <6E66FBDB43DE0F47A921161C395545B435DE92F0AC@mail1.office.gdi> I would like to request a fairly minor enhancement to the check_users Nagios plugin. It would be nice if the man page/help output gave some indication of what the performance data actually means. I can't even find this info out on Google, etc. thanks, John John Patrick Carroll | Senior Systems Administrator GovDelivery, Inc. 408 St. Peter St, Ste 600 | St Paul, MN 55102-1147 651.757.4124 or 866.276.5583 ext. 124 Resources Website: www.govdelivery.com Blog: www.reachthepublic.com Twitter: www.twitter.com/govdelivery -------------- next part -------------- An HTML attachment was scrubbed... URL: From dermoth at aei.ca Wed Sep 23 23:25:01 2009 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Wed, 23 Sep 2009 17:25:01 -0400 Subject: [Nagiosplug-devel] check_users Nagios plugin In-Reply-To: <6E66FBDB43DE0F47A921161C395545B435DE92F0AC@mail1.office.gdi> References: <6E66FBDB43DE0F47A921161C395545B435DE92F0AC@mail1.office.gdi> Message-ID: <4ABA922D.7080307@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 John Patrick Carroll wrote: > I would like to request a fairly minor enhancement to the check_users > Nagios plugin. It would be nice if the man page/help output gave some > indication of what the performance data actually means. I can?t even > find this info out on Google, etc. First two hits on Google for "nagios documentation performance data" (I added the marker on the first link so you get straight to the right section): http://nagiosplug.sourceforge.net/developer-guidelines.html#AEN201 http://nagios.sourceforge.net/docs/1_0/perfdata.html - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkq6ki0ACgkQ6dZ+Kt5BchalQgCfQupAF3wAufvW2NdeEWioHnIl jR4AoOxykuJZEoFvo5xAtVRC/aYGMewk =uhzZ -----END PGP SIGNATURE----- From noreply at sourceforge.net Wed Sep 23 23:36:54 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Sep 2009 21:36:54 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2865114 ] freebsd: fails on make Message-ID: Bugs item #2865114, was opened at 2009-09-23 12:31 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2865114&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: snapshot tarball Status: Open Resolution: None Priority: 5 Private: No Submitted By: charlo212 (charlo212) Assigned to: Nobody/Anonymous (nobody) Summary: freebsd: fails on make Initial Comment: Hi, Trying to compile the plugins on a freebsd 6.3 box. The configure stage looks okay but it fails on make with the following.... - SNIP - if gcc -DLOCALEDIR=\"/usr/local/nagios/share/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../gl -I../intl -I/usr/include -DNP_VERSION='"1.4.14"' -g -O2 -MT check_http.o -MD -MP -MF ".deps/check_http.Tpo" -c -o check_http.o check_http.c; then mv -f ".deps/check_http.Tpo" ".deps/check_http.Po"; else rm -f ".deps/check_http.Tpo"; exit 1; fi check_http.c:63: error: syntax error before '*' token check_http.c:63: warning: data definition has no type or storage class *** Error code 1 Stop in /home/nagios/nagios-plugins-trunk-200909231200/plugins. *** Error code 1 Stop in /home/nagios/nagios-plugins-trunk-200909231200. *** Error code 1 Stop in /home/nagios/nagios-plugins-trunk-200909231200. - SNIP - Host Details: uname -m = i386 uname -r = 6.3-RELEASE uname -s = FreeBSD uname -v = FreeBSD 6.3-RELEASE #3: Fri Jan 23 16:43:41 MST 2009 root at fc:/usr/src/sys/i386/compile/VKERN I've tried to upload my config.log but it's 504k and the restriction is down to 2XXk Let me know what else you'd need or if anything needs to be taken from the config.log that would help. Charlie ---------------------------------------------------------------------- >Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-09-23 17:36 Message: This has to do with ssl. Did you ever been able to compile nagios plugins on that box in the past? Are you sure your ssl installation is correct including development headers? For the config.log, gzip it; it should be small enough then. If you can compile an older version of nagios plugins please upload the config.log for that version as well. Also some things you may try: ./configure --without-openssl - You won't have ssll support at all (check_https, check_ldaps, etc...) ./configure --with-openssl=/path/to/openssl - If you have multiple openssl installations you may try with each of them. For example: ./configure --with-openssl=/usr ./configure --with-openssl=/usr/local/openssl ./configure --with-openssl=/opt/openssl ---------------------------------------------------------------------- Comment By: charlo212 (charlo212) Date: 2009-09-23 12:34 Message: Also to note, that this fails the same with the stable and snapshot version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2865114&group_id=29880 From noreply at sourceforge.net Mon Sep 28 11:11:50 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 28 Sep 2009 09:11:50 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2859548 ] check_by_ssh exit status when reaching timeout Message-ID: Bugs item #2859548, was opened at 2009-09-15 22:30 Message generated for change (Comment added) made by guillomovitch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2859548&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Guillaume Rousse (guillomovitch) Assigned to: Nobody/Anonymous (nobody) Summary: check_by_ssh exit status when reaching timeout Initial Comment: check_by_ssh currently exist with CRITICAL status when reaching timeout. When used just as a transport mechanism for invoking a remote plugin, it should rather exit with UNKNOWN status in this case. The patch is trivial, I'd be happy to contribute it if this is agreed. ---------------------------------------------------------------------- >Comment By: Guillaume Rousse (guillomovitch) Date: 2009-09-28 11:11 Message: I just noticed check_nrpe has -u switch for this very purpose. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2859548&group_id=29880 From John.Carroll at govdelivery.com Tue Sep 29 00:43:11 2009 From: John.Carroll at govdelivery.com (John Patrick Carroll) Date: Mon, 28 Sep 2009 17:43:11 -0500 Subject: [Nagiosplug-devel] check_users Nagios plugin In-Reply-To: References: Message-ID: <6E66FBDB43DE0F47A921161C395545B4362F4B09D7@mail1.office.gdi> I am talking about specific information for performance data returned by the check_users plugin, not performance data in general. thanks, John John Patrick Carroll?| Senior Systems Administrator? GovDelivery, Inc. 408 St. Peter St, Ste 600?| St Paul, MN 55102-1147 651.757.4124 or 866.276.5583 ext. 124 Resources Website: www.govdelivery.com Blog: www.reachthepublic.com Twitter: www.twitter.com/govdelivery -----Original Message----- Message: 3 Date: Wed, 23 Sep 2009 16:06:05 -0500 From: John Patrick Carroll Subject: [Nagiosplug-devel] check_users Nagios plugin To: "nagiosplug-devel at lists.sourceforge.net" Message-ID: <6E66FBDB43DE0F47A921161C395545B435DE92F0AC at mail1.office.gdi> Content-Type: text/plain; charset="us-ascii" I would like to request a fairly minor enhancement to the check_users Nagios plugin. It would be nice if the man page/help output gave some indication of what the performance data actually means. I can't even find this info out on Google, etc. thanks, John ------------------------------ Message: 4 Date: Wed, 23 Sep 2009 17:25:01 -0400 From: Thomas Guyot-Sionnest Subject: Re: [Nagiosplug-devel] check_users Nagios plugin To: Nagios Plugin Development Mailing List Message-ID: <4ABA922D.7080307 at aei.ca> Content-Type: text/plain; charset=UTF-8 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 John Patrick Carroll wrote: > I would like to request a fairly minor enhancement to the check_users > Nagios plugin. It would be nice if the man page/help output gave some > indication of what the performance data actually means. I can?t even > find this info out on Google, etc. First two hits on Google for "nagios documentation performance data" (I added the marker on the first link so you get straight to the right section): http://nagiosplug.sourceforge.net/developer-guidelines.html#AEN201 http://nagios.sourceforge.net/docs/1_0/perfdata.html - -- Thomas From dermoth at aei.ca Tue Sep 29 03:03:59 2009 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Mon, 28 Sep 2009 21:03:59 -0400 Subject: [Nagiosplug-devel] check_users Nagios plugin In-Reply-To: <6E66FBDB43DE0F47A921161C395545B4362F4B09D7@mail1.office.gdi> References: <6E66FBDB43DE0F47A921161C395545B4362F4B09D7@mail1.office.gdi> Message-ID: <4AC15CFF.2030600@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 28/09/09 06:43 PM, John Patrick Carroll wrote: > I am talking about specific information for performance data returned by the check_users plugin, not performance data in general. $./check_users Usage:check_users -w -c $ ./check_users -w 1 -c 2 USERS CRITICAL - 3 users currently logged in |users=3;1;2;0 Isn't that obvious? - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKwVz/6dZ+Kt5BchYRAssRAJ99TX2NlDjpNJ60mqh7zb/q9MRAPACgynTo JMrgRhPTQkv378cB0JVDOQ4= =UaYf -----END PGP SIGNATURE----- From paul.graziano at rbc.com Tue Sep 29 22:01:28 2009 From: paul.graziano at rbc.com (Graziano, Paul) Date: Tue, 29 Sep 2009 16:01:28 -0400 Subject: [Nagiosplug-devel] Plug-in check_procs In-Reply-To: <298120721DB07746B9D2F23F9DB4A5D0057A7930@SXGM-302.fg.rbc.com> References: <298120721DB07746B9D2F23F9DB4A5D0057A7930@SXGM-302.fg.rbc.com> Message-ID: <298120721DB07746B9D2F23F9DB4A5D0057A7939@SXGM-302.fg.rbc.com> Hi, we discovered a bug with check_procs & I've downloaded the source code. How do I know If I have the correct version of the source based on our binary that we are running. When I run check_procs --help the top line says check_procs v1758 (nagios-plugins 1.4.11). I can't find these values in the source code. print_revision (progname, NP_VERSION) Bug Details When executing the check_procs on HPUX or AIX the plug-in executes "ps -el" not "ps -ef". This means that the pattern is not matched and the plugin thinks the process is not running when it is. ./check_procs -w1 -c1 -C gcp_get_mistral_results.pl -vvv CMD: /usr/bin/ps -el (AIX 4.1 and HP-UX) Shows that for HPUX & AIX check_procs runs "ps -el" And if I do ps -el on the command line - bigbro at lntrs184# ps -el | grep mistral_recv.pl But the process is running. bigbro at lntrs184# ps -ef | grep mistral_recv.pl rbc 23426 1 0 Sep 9 ? 15:10 /usr/bin/perl -w ./mistral_recv.pl Thanks, Paul Graziano _______________________________________________________________________ This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. Ce courrier ?lectronique est confidentiel et prot?g?. L'exp?diteur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) d?sign?(s) est interdite. Si vous recevez ce courrier ?lectronique par erreur, veuillez m'en aviser imm?diatement, par retour de courrier ?lectronique ou par un autre moyen. -------------- next part -------------- An HTML attachment was scrubbed... URL: