According to Franck Horlaville: > >> Using ht://Dig 3.2.0b4-081901 on MacOS X 10.0.4 (Darwin) ... > I now am reindexing my whole data and it seems to me like htdig is > stuck. Here's the info: ... > 22104:24476:13:http://www.medi1.co.ma/present/journalistes/fontana_n.htm: > -********--******-*-- size = 6533 > 22105:24464:13:http://www.medi1.co.ma/present/journalistes/fourt_n.htm: > -********--******-*-- size = 6531 > 22106:24463:13:http://www.medi1.co.ma/present/journali > > % ls -l /var/log/htdig.log > -rw-rw-rw- 1 root wheel 2105344 Oct 9 16:16 /var/log/htdig.log
Yes, the log ends pretty abruptly, but it doesn't give a clear indication of where htdig is when it hangs. There's probably lots of debugging messages still stuck in cout's output buffer. Running htdig with more -v's might help to get closer to the problem. Some systems keep updating the modification time of a file as long as it's open for writing, whether or not anything is actually written to the file, so that doesn't mean much. > % ps -auwx|grep htdig > root 21936 40.2 4.4 31368 25868 std- R 3605:49.74 > bin/htdig -a -v -s -c conf/myconf.conf > > % top > > Processes: 73 total, 3 running, 70 sleeping... 223 threads 09:29:21 > Load Avg: 1.56, 1.70, 1.73 CPU usage: 20.4% user, 79.6% sys, 0.0% idle > SharedLibs: num = 103, resident = 18.8M code, 640K data, 5.43M LinkEdit > MemRegions: num = 5526, resident = 152M + 3.93M private, 15.9M shared > PhysMem: 60.5M wired, 197M active, 282M inactive, 540M used, 36.4M free > VM: 910M + 50.7M 40879(0) pageins, 181(0) pageouts > > PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE > 21936 htdig 66.0% 95:28:29 1 16 29 24.4M 2.27M 25.2M 30.6M > > % cd db > % ll > total 246424 > drwxrwxr-x 12 root admin 364 Oct 5 20:13 . > drwxrwxr-x 11 root admin 330 Oct 5 18:48 .. > -rw-r--r-- 1 root admin 98304 Oct 5 19:52 db.docdb > -rw-r--r-- 1 root admin 5480448 Oct 6 20:07 db.docdb.work > -rw-r--r-- 1 root admin 49152 Oct 5 19:52 db.docs.index > -rw-r--r-- 1 root admin 2670592 Oct 6 20:07 db.docs.index.work > -rw-r--r-- 1 root admin 1417216 Oct 5 19:52 db.excerpts > -rw-r--r-- 1 root admin 73809920 Oct 6 20:07 db.excerpts.work > -rw-r--r-- 1 root admin 619520 Oct 5 19:53 db.words.db > -rw-r--r-- 1 root admin 41784320 Oct 6 20:06 db.words.db.work > -rw-r--r-- 1 root admin 16384 Oct 5 20:13 db.words.db.work_weakcmpr > -rw-r--r-- 1 root admin 16384 Oct 5 19:53 db.words.db_weakcmpr > > Should I kill it and restart the dig for it to continue ? Am I going > to corrupt my db ? The log file is not moving anymore (although the > mod date is recent for an unknown reason) Yes, it's obviously hung, so you should kill it. Depending on how you kill it, it may or may not corrupt the db. If you just Ctrl-C, or kill it with SIGINT or SIGTERM, it should try to recover, but I can't promise that it will be successful, or that your database isn't already corrupted. On the other hand, it may be useful to kill it in such a way that it dumps core. E.g. using SIGABRT (kill -6 pid) should do that. In this case, you'll almost certainly lose the database (which may not be a great loss at this point), but hopefully you can get a meaningful stack backtrace from the core file. I'd like to get to the bottom of why htdig seems to get into an infinite loop. -- Gilles R. Detillieux E-mail: <[EMAIL PROTECTED]> Spinal Cord Research Centre WWW: http://www.scrc.umanitoba.ca/~grdetil Dept. Physiology, U. of Manitoba Phone: (204)789-3766 Winnipeg, MB R3E 3J7 (Canada) Fax: (204)789-3930 _______________________________________________ htdig-general mailing list <[EMAIL PROTECTED]> To unsubscribe, send a message to <[EMAIL PROTECTED]> with a subject of unsubscribe FAQ: http://htdig.sourceforge.net/FAQ.html
