Possible Solaris 8/INN-2.3.2 Problem

Alex Kiernan alexk at demon.net
Tue Jun 12 05:43:58 UTC 2001

Timothy Demarest <demarest at arraycomm.com> writes:

> >>>>> "Alex" == Alex Kiernan <alexk at demon.net>
> >>>>> wrote the following on 29 May 2001 13:11:26 +0100
>   >> I even tried recompiling everything under Solaris 2.5.1, but that
>   >> hasn't helped. If there doesn't seem to be a fix for 2.3.2, I'll
>   >> probably go back to 2.3.0 which works on my Solaris 8 box. In this
>   >> case, what do I need to do to recreated my ovdb and history files from
>   >> the articles that are in my spool? The history* and ovdb files
>   >> currently are probably damaged pretty badly - what ovdb files can I
>   >> delete before recreting them?
>   >> 
>   Alex> Same version of Berkeley DB or different?
> OK. There is definitely something really broken with my 2.3.2 under Solaris
> 8. I recompiled eveything for Solaris 8 with the following options:
> env LDFLAGS="-R /opt/local/lib -R /opt/local/gnu/lib" ./configure 
> --with-sendmai
> l=/usr/lib/sendmail --with-largefiles --with-run-dir=/var/run/news 
> --with-spool-
> dir=/var/spool/news --with-log-dir=/var/log/news --with-tmp-path=/var/spool/new
> s
> /tmp --with-perl --with-berkeleydb=/opt/local
> Berkeley DB is v3.2.9.
> After recompiling installing, I decided to completely wipe out the overview
> database files, the history file, and history indexes. I recreated both
> from the existing spool with makehistory and makedbz, which worked fine. I
> started news using rc.news, which worked just fine. However, all is not
> well. The innd daemon is running, but I'm back to my same old issues: it's
> stuck in LWP mutex lock loops. No errors to the various log files -- it's
> running, but not really doing anything.

Anything dieing (core dumps etc.)? The ovdb implementation isn't well
behaved with respect to that kind of thing (its really the way BDB
wants to handle inter process users of the same database which is
phenomenally hard for ovdb to support).

If you do get things croaking there's a good chance you'll end up in
mutex sleep.

Alex Kiernan, Principal Engineer, Development, Thus PLC

More information about the inn-workers mailing list