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)#