Sorry if this message is a duplicate for anyone. I sent this
message earlier today but from another email address that isn't
subscribed to this list. I got notification that the moderator
was looking at it but I never saw the message come through. I've
seen other messages make it to the list so I figured I try again
from my subscribed address just in case the first one got dropped
in the bit bucket.
I've been experiencing a lot (sometimes several times a day) of
coredumps on my listserv box. I just moved the whole setup to a
brand new, much bigger machine and things seemed to have gotten
better temporarily, but it seems my problems are back again. For
now I've had to resort to running the following script as a
cronjob once every minute.
#!/bin/sh
ps -awx | grep lsv | grep -v grep
if [ $? = 1 ]; then
cd /home/listserv
./go bg
date | mail -s 'listserv is down' [log in to unmask]
fi
Has anyone had similar problems running 1.8d on a RedHat 6.2 box?
The box is a dual-capable PIII-600MHz with 1GB of RAM and 1GB of
swap. This box is also primary mail and secondary DNS for about
500 domains, hosts a handful of SSL sites, and runs a single
instance of listserv. As can be seen from the first few lines of
a typical top(1) output this box is far from being overutilized.
last pid: 34318; load averages: 0.00, 0.01, 0.00 up 4+10:24:27 07:46:51
56 processes: 1 running, 54 sleeping, 1 zombie
CPU states: 0.4% user, 0.0% nice, 0.8% system, 0.0% interrupt, 98.8% idle
Mem: 66M Active, 389M Inact, 75M Wired, 36M Cache, 112M Buf, 437M Free
Swap: 996M Total, 4K Used, 996M Free
It also has plenty of HD space.
root@spitz(/home/listserv)# df
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/ad0s1a 93365 33683 52213 39% /
/dev/ad0s3f 992239 229664 683196 25% /tmp
/dev/ad0s3g 11147989 1967421 8288729 19% /usr
/dev/ad0s3e 992239 144091 768769 16% /var
procfs 4 4 0 100% /proc
root@spitz(/home/listserv)# ls -ld /home
lrwxr-xr-x 1 root wheel 9 Jun 12 2000 /home -> /usr/home
If it helps, here's a brief analysis of one of the core files. Any
suggestions/workarounds would be much appreciated.
root@spitz(/home/listserv)# gdb ./lsv lsv.core
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...(no debugging symbols found)...
Core was generated by `lsv'.
Program terminated with signal 11, Segmentation fault.
/lib/libNoVersion.so.1: No such file or directory.
#0 0x2817972a in ?? ()
(gdb) where
#0 0x2817972a in ?? ()
#1 0x281858e3 in ?? ()
#2 0x8057660 in LSV_sprintf ()
#3 0x80c0434 in LSWSETEP ()
#4 0x804fdfd in LSWCMDCL ()
#5 0x8072c8c in LSWCMD ()
#6 0x8096c6b in LSWJCMD ()
#7 0x80bad22 in LSWRDR ()
#8 0x80b4f91 in Process ()
#9 0x80b5918 in LSWPRFGO ()
#10 0x80600d2 in Go ()
#11 0x8060123 in main ()
(gdb) up 2
#2 0x8057660 in LSV_sprintf ()
(gdb) disas
Dump of assembler code for function LSV_sprintf:
0x805764c <LSV_sprintf>: push %ebp
0x805764d <LSV_sprintf+1>: mov %esp,%ebp
0x805764f <LSV_sprintf+3>: push %ebx
0x8057650 <LSV_sprintf+4>: mov 0x8(%ebp),%ebx
0x8057653 <LSV_sprintf+7>: lea 0x10(%ebp),%eax
0x8057656 <LSV_sprintf+10>: push %eax
0x8057657 <LSV_sprintf+11>: pushl 0xc(%ebp)
0x805765a <LSV_sprintf+14>: push %ebx
0x805765b <LSV_sprintf+15>: call 0x804924c <vsprintf>
0x8057660 <LSV_sprintf+20>: mov %ebx,%eax
0x8057662 <LSV_sprintf+22>: mov 0xfffffffc(%ebp),%ebx
0x8057665 <LSV_sprintf+25>: leave
0x8057666 <LSV_sprintf+26>: ret
0x8057667 <LSV_sprintf+27>: nop
End of assembler dump.
(gdb) quit
root@spitz(/home/listserv)#
|
