At 04:53 PM 10/21/02 -0000, Cron Daemon wrote: >err: Couldn't open the property file "index.swish-e.prop.temp": No such file or directory
I'm looking at this, but response is very slow on daedalus right now.
When indexing swish writes to *.temp files and when finally done indexing the files are renamed, which replace the existing files.
This is error message is odd, in a number of ways:
1) When indexing swish writes a couple of files. On of them, the .prop.temp file shown in this error, is closed and reopened in read mode (for speed up read access for the final indexing stage). So swish was able to close the file without any errors, but when it tried to reopen it the OS said the file didn't exist. I've never seen this happened before. There's plenty of disk space.
2) There was an index file created at the time of this message from cron (09:53:34 -0700), but it's corrupt. The error above aborts swish indexing so the .temp files should still exist (and not overwrite the existing index files) since swish aborted before the files could be renamed. I'm not clear how corrupted indexes got written.
Hmm, definitely weird, but I suppose it's linked to the load. Let's wait til things settle down, I suppose it'll work then :)
3) Maybe I need coffee. On my machine I keep the swish-e binary in the "search" directory and then the search script runs ./swish-e.
On the live site it lives at /home/perlwww/bin/swish-e.
But in the swish.cgi program I see:
my $swish_binary = $ENV{SWISH_BINARY_PATH} || './swish-e';
and I don't see where SWISH_BINARY_PATH is set when running as a CGI script (I looked in httpd.conf, and .htaccess and ../.htaccess).
I fear I'm missing something obvious here.
We have an eval require apache.org-setup.pl at the top of swish.cgi which sets SWISH_BINARY_PATH to its correct value.
4) It's impossible to work on daedalus now. Very slow to respond. Server seems loaded. I've never seen it so slow. I don't know what normal is for the web server, but:
41.6 requests/sec - 5.1 MB/second - 124.6 kB/request 900 requests currently being processed, 0 idle workers
I can't see any obvious reason for it, but, well, Apache is popular.
5) Brian's plea to reduce disk space hasn't freed much space, if any. At 96% now.
Ah, those Java people with their large builds :) It doesn't matter too much for now; there is like 500MB free, and we need only 28. But it would be good if they could get some of the old things out, that's true. Give them some time.
-- Per Einar Ellefsen [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
