brian@sys11:~/tree/sup$ ./bin/sup-dump | bzip2 > ~/sup_2010-02-10.bzip2
/home/brian/tree/sup/lib/sup/xapian_index.rb:354:in `find_docid': unhandled
exception
from /home/brian/tree/sup/lib/sup/xapian_index.rb:359:in `find_doc'
from /home/brian/tree/sup/lib/sup/xapian_index.rb:369:in `get_entry'
from /home/brian/tree/sup/lib/sup/xapian_index.rb:77:in `build_message'
from /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
from /home/brian/tree/sup/lib/sup/xapian_index.rb:378:in `synchronize'
from /home/brian/tree/sup/lib/sup/xapian_index.rb:77:in `build_message'
from /home/brian/tree/sup/lib/sup/index.rb:154:in `each_message'
from /home/brian/tree/sup/lib/sup/xapian_index.rb:114:in `each_id'
from /home/brian/tree/sup/lib/sup/xapian_index.rb:114:in `each'
from /home/brian/tree/sup/lib/sup/xapian_index.rb:114:in `each_id'
from /home/brian/tree/sup/lib/sup/index.rb:153:in `each_message'
from ./bin/sup-dump:29
:-(
Ok, was trying to avoid this action because it is dodgy, but lets do it anyway:
brian@sys11:~/tree/sup$ cp /home/brian/.sup/xapian/
/home/brian/.sup/xapian_2010-02-10/
=== cut ===
diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb
index cf701b4..9fa22a4 100644
--- a/lib/sup/xapian_index.rb
+++ b/lib/sup/xapian_index.rb
@@ -345,7 +345,6 @@ EOS
def find_docid id
docids = term_docids(mkterm(:msgid,id))
- fail unless docids.size <= 1
docids.first
end
=== cut ===
Ok, much better. I guess the "most correct" think to do now would be to dump the
index, remove my hack, and rebuild everything. On the assumption that when I
restore the message state it isn't going to add this id back again...
msgid = rt-3.6.7-1625-1265687524-1872.8973-15-0@vpac.org
docids = 2371881340 and 2371881341
I greped the msgid in my mail and found one match, and automatic message
generated by request tracker.
What should I do now?
The web page you said pointed out suggested this should do something:
irb(main):009:0> puts Index.build_message(6047).raw_message
TypeError: can't convert Range into Integer
from ./lib/sup/xapian_index.rb:578:in `[]'
from ./lib/sup/xapian_index.rb:578:in `mkterm'
from ./lib/sup/xapian_index.rb:347:in `find_docid'
from ./lib/sup/xapian_index.rb:359:in `find_doc'
from ./lib/sup/xapian_index.rb:369:in `get_entry'
from ./lib/sup/xapian_index.rb:77:in `build_message'
from /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
from ./lib/sup/xapian_index.rb:378:in `synchronize'
from ./lib/sup/xapian_index.rb:77:in `build_message'
from ./lib/sup/index.rb:236:in `send'
from ./lib/sup/index.rb:236:in `method_missing'
from (irb):9
but this doesn't work for me.
Maybe I should rebuild the index and see if the same problem reoccurs.
Yes, I put print statements in where it was crashing, and obtained the message-
id, docid, and the email.
Unfortunately the details are at work.
However, there was nothing that really stood out with the email either, it was
just a standard email generated by request-tracker. It wasn't the email that I
had just sent. There only seem to be one message with the message-id that I
could find too. I couldn't see anything that looked remotely wrong or unusual.
I tried removing the message, and running sup-sync, but then it crashes when it
tries to delete it. So the problem seems to be the index.
How is the docid generated?
Unfortunately am rather busy at work at the moment, so I haven't had time to put
as much effort into debugging this issue as I would like. Maybe tomorrow.
Brian May
Sorry, I replied using mail before I checked further messages in this
tracker.
Could you be able to identify the offending docid and maybe the
mail(s) that docid points to? Just to get a hint on what happened.
Hit ~ to get console buffer where you can play just like in
devel/console.sh, see
<http://sup.rubyforge.org/wiki/wiki.pl?ProgrammaticallyAccessingSupsIndex>
anonymous, 2010-02-09 06:03:
> sup crashed after I sent an email, and won't start anymore.
I expect the exception log is the failing start? Index seems to be in
inconsistent state.
Could you describe in more detail how exactly sup crashed after
sending mail. When exactly it crashed? What did it say?
You can try to get back on your feet by recreating your index. Try
creating sup-dump (back up index) first so that you can preserve
labels. If that doesn't work, you unfortunately can't preserve your
message states. But don't throw your old index away just yet, before
sup-sync do cd ~/.sup/; mv xapian xapian.bak . We might find another
way to recover.
Quoting from http://sup.rubyforge.org/FAQ.txt
Q: How do I back up my index?
A: Since the contents of the messages are recoverable from their
sources using sup-sync, all you need to back up is the message
state. To do this, simply run:
sup-dump > <dumpfile>
This will save all message state in a big text file, which you
should probably compress.
Q: How do I restore the message state I saved in my state dump?
A: Run:
sup-sync [<source>+] --restored --restore <dumpfile>
where <dumpfile> was created as above.
sup crashed after I sent an email, and won't start anymore.
This is with the latest git version. Ubuntu/Karmic.
[Tue Feb 09 14:59:30 +1100 2010] ERROR: oh crap, an exception
----------------------------------------------------------------
I'm very sorry. It seems that an error occurred in Sup. Please
accept my sincere apologies. Please submit the contents of
/home/brian/.sup/exception-log.txt and a brief report of the
circumstances to http://masanjin.net/sup-bugs/ so that I might
address this problem. Thank you!
Sincerely,
William
----------------------------------------------------------------
--- RuntimeError from thread: load threads for thread-index-mode
/home/brian/tree/sup/lib/sup/xapian_index.rb:348:in `find_docid'
/home/brian/tree/sup/lib/sup/xapian_index.rb:353:in `find_doc'
/home/brian/tree/sup/lib/sup/xapian_index.rb:363:in `get_entry'
/home/brian/tree/sup/lib/sup/xapian_index.rb:77:in `build_message'
/usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
/home/brian/tree/sup/lib/sup/xapian_index.rb:372:in `synchronize'
/home/brian/tree/sup/lib/sup/xapian_index.rb:77:in `build_message'
/home/brian/tree/sup/lib/sup/xapian_index.rb:121:in `each_id_by_date'
/home/brian/tree/sup/lib/sup/thread.rb:332:in `call'
/home/brian/tree/sup/lib/sup/thread.rb:332:in `load_n_threads'
/home/brian/tree/sup/lib/sup/xapian_index.rb:121:in `each_id_by_date'
/home/brian/tree/sup/lib/sup/xapian_index.rb:114:in `each_id'
/home/brian/tree/sup/lib/sup/xapian_index.rb:114:in `each'
/home/brian/tree/sup/lib/sup/xapian_index.rb:114:in `each_id'
/home/brian/tree/sup/lib/sup/xapian_index.rb:121:in `each_id_by_date'
/home/brian/tree/sup/lib/sup/thread.rb:328:in `load_n_threads'
/home/brian/tree/sup/lib/sup/modes/thread-index-mode.rb:630:in
`__unprotected_load_n_threads'
(eval):12:in `load_n_threads'
/home/brian/tree/sup/lib/sup/modes/thread-index-mode.rb:614:in
`load_n_threads_background'
/home/brian/tree/sup/lib/sup.rb:77:in `reporting_thread'
/home/brian/tree/sup/lib/sup.rb:75:in `initialize'
/home/brian/tree/sup/lib/sup.rb:75:in `new'
/home/brian/tree/sup/lib/sup.rb:75:in `reporting_thread'
/home/brian/tree/sup/lib/sup/modes/thread-index-mode.rb:613:in
`load_n_threads_background'
/home/brian/tree/sup/lib/sup/modes/thread-index-mode.rb:684:in
`__unprotected_load_threads'
(eval):12:in `load_threads'
/home/brian/tree/sup/bin/sup:226
Brian May