On Tue, 08 Oct 2002 at 20:54:49 -0500, Searcher wrote: > the screen, line after line then very suddenly started doing this. It's been at > the same line all day long now but the drive space continues to be used up a tiny > bit at a time. Since it's queued, now I can understand but still don't get why > the same URL has been showing up on the terminal screen all day now.
Is there logging still occuring in aspseek/logs.txt (what does 'tail -f logs.txt' show when observed for a few minutes)? Are you sure you haven't run out of disk space on the filesystem that you are logging to? > Also, index -D, is this only if I terminate it or once it terminates on it's own > as well? I've learned a bit about setting it up, configuring and running it so If index exits without intervention i.e. it completes indexing all URLs then it will automatically rebuild deltas. If, however, you terminate it early (with 'index -E') or it crashes for whatever reason then it will not have rebuilt it's deltas and you must run 'index -D'. Basically, if the deltas are not rebuilt then newly indexed documents will not match in a search query. > I can't wait to see some sort of real time stats added to this. It would be > wonderful to log into another session, run the stats program and be able to see > everything that's going on, in real time on aspseek. Well, realtime is a little missplaced here. Within the last minute of operation is more to the point. Being able to see a graphical representation is pretty good, for the visually inclined at least. Actually you should be able to get something out of the logs.txt file with a pretty simple perl script which you can feed into an RRD database and produce some graphs from. What I've implemented is a light weight UDP client/server, the client portion is embedded in ASPseek, feeding the server with data during it's indexing run. It adds virtually no overhead and you don't have to write nasty perl scripts. It's what I've used to generate these http://aspseek.unixatwork.com/snapshot/ Matt.
