monit-general
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: configuring monit's httpd


From: Jan-Henrik Haukeland
Subject: Re: configuring monit's httpd
Date: Wed, 14 Jan 2004 20:56:01 +0100
User-agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Reasonable Discussion, linux)

Hi Allen

I looked at the gdb stack trace and strace list you sent (mailman
refused to send your mail to this list because it was to big. Besides
sending a 700Kb mail to the list may not be appreciated by everyone :)

Anyway, the stack trace did not give much information bacause it was
run with a stripped monit. (The Makefile that installs monit strips
away debug information).

The backtrace you sent seems to indicate that the segmentation fault
is caused by a string copy:

#262024 0x080503c8 in strcpy ()
#262025 0x08055ead in signal ()
#262026 0x0804fe25 in strcpy ()
#262027 0x0804f97e in strcpy ()
#262028 0x0804f649 in strcpy ()

And the strace listing:

8403  15:18:32 open("/proc/8436/statm", O_RDONLY) = 7
8403  15:18:32 read(7, "308 308 250 45 0 263 58\n", 4095) = 24
8403  15:18:32 close(7)                 = 0
8403  15:18:32 --- SIGSEGV (Segmentation fault) ---
8403  15:18:32 +++ killed by SIGSEGV +++

seems to point to the sub-system in monit that reads process data from
the /proc system.

But as long as there is no debug info it's impossible to see where the
problem is in monit. Here's what to do to get a backtrace with debug
info:

1. tar zxvf monit-4.1.1.tar.gz 
2. cd monit-4.1.1/
3. ./configure && make
4. ./monit -Iv
5. If you get a core dump do
6. gdb ./monit core
7. (If the stack trace is not listed when loaded, do a)
8. (gdb) bt
9. Send the relevant parts of the output, i.e. the first 10-20 lines

This is what the outout from gdb should look like when debug info is
available (I did this with a small test program that dumps core):

#0  0x080483ca in main () at test.c:5
5               printf("Value: %x\n", *p);
(gdb) bt
#0  0x080483ca in main () at test.c:5
#1  0x42017589 in __libc_start_main () from /lib/i686/libc.so.6


Finally, I _did_ test monit version 4.1.1 with the config file you
submitted, but could not reproduce the problem. Please do a 'uname -a'
such as shown below so we can see what kind of system you are running.

# uname -a
Linux localhost 2.4.20-27.7 #1 Thu Dec 11 15:04:48 EST 2003 i686 unknown


Ps. Have you updated glibc or installed a new kernel recently? it's
not unthinkable that the problem could be related to the system
itself.

-- 
Jan-Henrik Haukeland




reply via email to

[Prev in Thread] Current Thread [Next in Thread]