Just one noit running. A while back I had tried 2, but I've started
over since then (drop the database, rm -rf the reconnoiter
directories, etc.).
There shouldn't be any remnants of the old setup left.

On Fri, Aug 20, 2010 at 1:05 PM, Theo Schlossnagle <jesus at omniti.com> wrote:
> Do you have two remote noits with the same CN?
>
> On Aug 20, 2010, at 12:40 PM, dan (ddp) wrote:
>
>> Thanks for the info. I should have mentioned that this is
>> OpenBSD/amd64, and I'm using the following malloc.conf options:
>> # ls -l /etc/malloc.conf
>> lrwxr-xr-x  1 root  wheel  2 Jun 24 17:18 /etc/malloc.conf -> AS
>>
>> Although it coredumps without the malloc.conf also.
>>
>> You can get a gzip'd coredump at http://ddp.devio.us/stratcond.core.gz
>>
>> Thanks again!
>> dan
>>
>> Here's the gdb info:
>> Pushing transient/iep checkpoint [noit]: [159/30746]
>> [2010-08-20 12:23:46.393918] attempted checkpoint on non-existing
>> workingset: 'noit'
>>
>> Program received signal SIGABRT, Aborted.
>> [Switching to process 30200, thread 0x20bbcf800]
>> 0x000000020979097a in kill () from /usr/lib/libc.so.56.0
>> (gdb) info threads
>>  11 process 30200, thread 0x20bbcf000 (COND_WAIT)  _thread_kern_sched
>> (scp=0x0) at /usr/src/lib/libpthread/uthread/uthread_kern.c:482
>>  10 process 30200, thread 0x20e238800 (COND_WAIT)  _thread_kern_sched
>> (scp=0x0) at /usr/src/lib/libpthread/uthread/uthread_kern.c:482
>>  9 process 30200, thread 0x206d33800 (COND_WAIT)  _thread_kern_sched
>> (scp=0x0) at /usr/src/lib/libpthread/uthread/uthread_kern.c:482
>>  8 process 30200, thread 0x206d33000 (COND_WAIT)  _thread_kern_sched
>> (scp=0x0) at /usr/src/lib/libpthread/uthread/uthread_kern.c:482
>>  7 process 30200, thread 0x206d72000 (COND_WAIT)  _thread_kern_sched
>> (scp=0x0) at /usr/src/lib/libpthread/uthread/uthread_kern.c:482
>>  6 process 30200, thread 0x206d72800 (COND_WAIT)  _thread_kern_sched
>> (scp=0x0) at /usr/src/lib/libpthread/uthread/uthread_kern.c:482
>>  5 process 30200, thread 0x2074d8000 (COND_WAIT)  _thread_kern_sched
>> (scp=0x0) at /usr/src/lib/libpthread/uthread/uthread_kern.c:482
>>  4 process 30200, thread 0x205112000 (COND_WAIT)  _thread_kern_sched
>> (scp=0x0) at /usr/src/lib/libpthread/uthread/uthread_kern.c:482
>>  3 process 30200, thread 0x20c034800 (COND_WAIT)  _thread_kern_sched
>> (scp=0x0) at /usr/src/lib/libpthread/uthread/uthread_kern.c:482
>>  2 process 30200  0x000000020979097a in kill () from /usr/lib/libc.so.56.0
>> * 1 process 30200, thread 0x20bbcf800 (RUNNING)  0x000000020979097a in
>> kill () from /usr/lib/libc.so.56.0
>> (gdb) thread apply all bt full
>>
>> Thread 11 (process 30200, thread 0x20bbcf000):
>> #0  _thread_kern_sched (scp=0x0) at
>> /usr/src/lib/libpthread/uthread/uthread_kern.c:482
>>        curthread = (struct pthread *) 0x20bbcf000
>>        pthread = Variable "pthread" is not available.
>> #0  0x000000020979097a in kill () from /usr/lib/libc.so.56.0
>>
>>
>> On Fri, Aug 20, 2010 at 12:03 PM, Theo Schlossnagle <jesus at omniti.com> wrote:
>>> If you can manage to get a core, we'll be able to do more gdb commands post-mordem.  But something like this would be useful:
>>>
>>> info threads
>>>
>>> thread apply all bt full
>>>
>>>
>>
>> _______________________________________________
>> Reconnoiter-users mailing list
>> Reconnoiter-users at lists.omniti.com
>> http://lists.omniti.com/mailman/listinfo/reconnoiter-users
>
> --
> Theo Schlossnagle
> http://omniti.com/is/theo-schlossnagle
>
>
>
>
>
>