[Top][All Lists]
[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
- configuring monit's httpd, Allen Shaw, 2004/01/08
- Re: configuring monit's httpd, Christian Hopp, 2004/01/09
- Re: configuring monit's httpd,
Jan-Henrik Haukeland <=
- Re: configuring monit's httpd, Allen Shaw, 2004/01/14
- Re: configuring monit's httpd, Christian Hopp, 2004/01/15
- Re: configuring monit's httpd, Jan-Henrik Haukeland, 2004/01/15
- Re: configuring monit's httpd, Christian Hopp, 2004/01/15
- Re: configuring monit's httpd, Jan-Henrik Haukeland, 2004/01/16
- Re: configuring monit's httpd, Martin Pala, 2004/01/16
- Re: configuring monit's httpd, Jan-Henrik Haukeland, 2004/01/18
- Re: configuring monit's httpd, Christian Hopp, 2004/01/18
- Re: configuring monit's httpd, Allen Shaw, 2004/01/15