Sugg: Crash Doctor

So far it seems that the majority of Logos crashes have come from corrupt databases, whether from the index or the Updates.db. A lot of troubleshooting around here is trying to figure out which database to delete to let Logos 4 rebuild it. Now that 4.0b (in Beta) has the ability to generate a crash report what if we take it one step further. What about a utility program that launches after a crash that reads the crash log for indications of a corrupt db and then prompts the user to delete that db and relaunch Logos. A function like this might greatly reduce calls to tech support.

Is this a feasible idea or is it a pipe dream of a non-programmer?

Find more posts tagged with

Comments

Rosie Perera

So far it seems that the majority of Logos crashes have come from corrupt databases, whether from the index or the Updates.db. A lot of troubleshooting around here is trying to figure out which database to delete to let Logos 4 rebuild it. Now that 4.0b (in Beta) has the ability to generate a crash report what if we take it one step further. What about a utility program that launches after a crash that reads the crash log for indications of a corrupt db and then prompts the user to delete that db and relaunch Logos. A function like this might greatly reduce calls to tech support.

Is this a feasible idea or is it a pipe dream of a non-programmer?

Sounds like an awesome idea. I wasn't sure how to interpret your sentence "prompt the user to..." as it could be taken two wasy. But rather than merely instructing the user to delete the db and relaunch Logos, have the Crash Doctor do that for them (upon confirmation that's what the user wants to do, but who wouldn't, if it's the only thing that will get them up and running again). So the user doesn't have to go looking through hidden folders to find the db and delete it. Perhaps you meant that latter meaning anyway. I've noticed a lot of very non-techie users lately having to be hand-held through doing stuff like this manually, uploading logs and helping Logos debug the program, and they don't like it one bit. That just gives Logos a bad reputation as people complain about it. The more easily the crashing problems can be remedied the better. And the more they can be avoided entirely, even better!!!

Kevin Becker

https://community.logos.com/discussion/comment/94786#Comment_94786

Sounds like an awesome idea. I wasn't sure how to interpret your sentence "prompt the user to..." as it could be taken two wasy. But rather than merely instructing the user to delete the db and relaunch Logos, have the Crash Doctor do that for them (upon confirmation that's what the user wants to do, but who wouldn't, if it's the only thing that will get them up and running again). So the user doesn't have to go looking through hidden folders to find the db and delete it. Perhaps you meant that latter meaning anyway. I've noticed a lot of very non-techie users lately having to be hand-held through doing stuff like this manually, uploading logs and helping Logos debug the program, and they don't like it one bit. That just gives Logos a bad reputation as people complain about it. The more easily the crashing problems can be remedied the better. And the more they can be avoided entirely, even better!!!

I meant the second interpretation. I imagine something like this message "It appears your crash came from index.db being corrupt, click yes to delete it and start Logos again (Logos will then rebuild this db)."

Terry Poperszky

https://community.logos.com/discussion/comment/94789#Comment_94789

Why wait for a crash? Why not have L4 validate the integrity of the index and then rebuild it as necessary.

FYI, I am not a programmer, not do I play one on TV. I am something much, much better, a sysadmin. [:P] 30 minutes and a good perl script should be all it takes to do this. [;)]

Mark Smith

https://community.logos.com/discussion/comment/94797#Comment_94797

Why wait for a crash? Why not have L4 validate the integrity of the index and then rebuild it as necessary.

I agree with the need for the Logos indexer and/or updater to be more fault tolerant or for Logos to pre-screen the usual suspects before running a re-index. People are dealing with update and indexing problems over and over again. It is time for Logos to develop the tool needed to cut these incidents down. It can't be that hard.

Robert Pavich

https://community.logos.com/discussion/comment/94816#Comment_94816

"...I agree with the need for the Logos indexer and/or updater to be more fault tolerant....

hmmm...I think I've seen this situation before somewhere....and it didn't turn out good at all....

"....I'm sorry to bother you Dave.....but it looks like the AE-35 antenna array will fail in 38 hours.....I think it should be replaced...."

Alan Macgregor

https://community.logos.com/discussion/comment/94878#Comment_94878

hmmm...I think I've seen this situation before somewhere....and it didn't turn out good at all....

"....I'm sorry to bother you Dave.....but it looks like the AE-35 antenna array will fail in 38 hours.....I think it should be replaced...."

Yes, but my computer isn't a psychotic savage … that's me but for the grace of God! Nor is it called HAL. It's SAL [;)]

Seriously, though as long as we know what is happening and have some input into the recovery process, even clicking "Yes", then I would welcome it. L4 is simply too fragile for the real world. Now I expect that in L4Mac Alpha, but reading L4Win forum shows me that things aren't much better with the finished product. I think we are paying a high price in lost stability for the sake of high speed searching, online interface and a glitzy front-end. Auto-rebuilding and recovery would go a long way to restoring my confidence in Logos. Thank goodness we still have L3 to fall back on.