Search failing with missing file

[Thunderstone]

After having Webinator running successfully for a while a problem has
popped up that I can't pin down.

Whenever a search is performed, a warning message is printed at the
top of the page along the lines:

WARNING: Could not open index /home/www1/export/webinator/db/xhtmlbod

Hits are returned against the search - maybe an unlimited number - but
the relevance of the hits is always 0.

Reindexing the database has no effect - and I'm reluctant to rebuild the
whole thing because it takes a long time.

Any ideas,

Steve.

[Thunderstone]

Steven Heaney said:

It appears that the program cannot open the index. The first step would
be to make sure that all the files in the db directory have appropriate
permissions. If that does not work you will need to rebuild the index
be executing:

gw -unindex
gw -index

The unindex first is important.

You should not need to rewalk the entire site, as it sounds as if the data
is still there.

[Thunderstone]

On Mon, Jun 16, 1997 5:08 pm, John Turnbull <mailto:john@thunderstone.com>
wrote:

I tried this before I posted.


Good!

Here's a listing of the contents of the db directory. The files prefixed
xhtmlbod were previously -rw------- for offsite, but changing them to
group and world read seems to make no difference.

heaney> ls -l
total 492988

-rw------- 1 offsite other 17074 Jun 10 14:02 SYSCOLUMNS.tbl

-rw------- 1 offsite other 6344 Jun 16 10:59 SYSINDEX.tbl

-rw-rw-rw- 1 offsite other 49488 Jun 16 10:59 SYSLOCKS

-rw-rw-rw- 1 offsite other 8 Jun 16 10:59 SYSLOCKS.SEQ

-rw------- 1 offsite other 3314 Feb 10 12:12 SYSMETAINDEX.tbl

-r--r--r-- 1 offsite other 2259771 Feb 10 12:12 SYSOBJECTS.tbl

-rw------- 1 offsite other 5398 Jun 10 14:02 SYSPERMS.tbl
-rw------- 1 offsite other 8770 Jun 10 14:02 SYSTABLES.tbl
-rw------- 1 offsite other 3314 Feb 10 12:12 SYSTRIG.tbl
-rw------- 1 offsite other 3438 Feb 10 12:12 SYSUSERS.tbl
-rw-r--r-- 1 heaney cis 209 Jun 16 11:57 bottom.html
-rw------- 1 offsite other 1161918 Jun 12 00:36 error.tbl
-rw-r--r-- 1 offsite other 1386397 Jun 16 10:59 gw.log
-rw------- 1 offsite other 134006242 Jun 12 00:36 html.tbl
-rw------- 1 offsite other 36361562 Jun 12 00:37 refs.tbl
-rw------- 1 offsite other 1502398 Jun 12 00:36 todo.tbl
-rw-r--r-- 1 heaney cis 449 Jun 11 12:01 top.html
-rw-r--r-- 1 offsite other 746278 Jun 16 10:18 xhtmlbod_B.btr
-rw-r--r-- 1 offsite other 46 Jun 16 10:00 xhtmlbod_D.btr
-rw-r--r-- 1 offsite other 5360037 Jun 16 10:18 xhtmlbod_M.blb
-rw-r--r-- 1 offsite other 3189068 Jun 16 10:18 xhtmlbod_M.btr
-rw-r--r-- 1 offsite other 3343 Jun 16 10:00 xhtmlbod_P.tbl
-rw-r--r-- 1 offsite other 46 Jun 16 10:00 xhtmlbod_T.btr
-rw-r--r-- 1 offsite other 46 Jun 16 10:00 xhtmlbod_U.btr
-rw-r--r-- 1 offsite other 1238050 Jun 16 10:23 xhtmlid.btr
-rw-r--r-- 1 offsite other 4213924 Jun 12 00:37 xhtmlurl.btr
-rw-r--r-- 1 offsite other 27889748 Jun 16 10:59 xrefsref.btr
-rw-r--r-- 1 offsite other 31234532 Jun 16 10:34 xrefsurl.btr
-rw-r--r-- 1 offsite other 1448170 Jun 12 00:37 xtodourl.btr
heaney>

A separate database, built much earlier also has this problem. It
could be that some system configuration changed over the weekend, but
I don't have any obvious leads to follow.

The webinator executable is installed on the same disk as the
database and it is accessible from the machine running the web server.
Changing all the files in the directory listed above to '644' seems to
make no difference either.

Any suggestions? Is there a debug switch I can pass to the CGI to
get some more information?

Steve.

[Thunderstone]

Steven Heaney said:

I am assuming that the webinator executable is running as offsite,
otherwise you would not be able to open the database. When you say
"accessible from the machine running the web server", is the database
mounted from a different machine than that which the webinator executable
is running? This is not a supported configuration. The other things
you can check are that the ulimit on number of open files, and amount
of memory available have not been reduced.

You might also look at the end of gw.log for any messages after it created
the index.