ArmoryDB fails to stop (Mac OS X)

[gangtraet]

Hi,

I have been running bitcoind and Armory in a virtual linux box for a while, but for various reasons wanted to move back to running natively on my MacBook.

I started Armory with a completely empty ~/Library/Application Suppport/Armory directory except for the wallet files, and with BitcoinQT running and up to date.  Armory got stuck while ArmoryDB was scaning the TX's (I think it said).  Killing everything, and restarting, Armory is working fine, can both send and receive bitcoins.

But whenever I quit Armory, the ArmoryDB process keeps running.  I have to kill it manually to start Armory again.  Also, when Armory exits, the Mac pops up a window claiming it crashed, and offering to restart it.

It is not a serious problem, only a nuisance.  But for new users it could be problematic.

Log files:
armorycpplog.txt: http://pastebin.com/jXdvm88C
armorylog.txt: http://pastebin.com/fvm61ZGU
dbLog.txt: http://pastebin.com/e1MZjHBu

[goatpig]

I am considering an additional approach to shutting down the DB already. The current DB will not shutdown on its own if the client that spawned it crashes or terminates without sending the shutdown signal. This should cover most other cases.

[gangtraet]

Then I guess the two problems I see are related.  Apparently, Armory does not send the shutdown signal, perhaps because it crashes during the shutdown.

Strange: I just tried two times more, it shut down without problems and stopped ArmoryDB.

Ah well ...  The problem went away by itself.

:-)

[goatpig]

Most likely a race condition in the shutdown process.

[droark]

Most likely a race condition in the shutdown process.

This is a likely culprit. Can't confirm if it's the culprit, unfortunately.

In any event, thanks for pointing out that ArmoryDB doesn't shut down. I only now noticed this. I'm guessing there's a shutdown signal that's either not sent or is the wrong signal. I'll look into it.

[goatpig]

Most likely a race condition in the shutdown process.

This is a likely culprit. Can't confirm if it's the culprit, unfortunately.

In any event, thanks for pointing out that ArmoryDB doesn't shut down. I only now noticed this. I'm guessing there's a shutdown signal that's either not sent or is the wrong signal. I'll look into it.

Most likely the FCGI library doesn't shutdown its listen socket as expected.

[droark]

Most likely the FCGI library doesn't shutdown its listen socket as expected.

Makes sense. I'm kinda amazed that code works with OSX at all! Anyway, I'll be in touch and see if I can troubleshoot it.

[gangtraet]

Just a follow-up.  It is not consisten that ArmoryDB does not shut down, but it does happen in the majority of the cases.  In a few cases, it does not shut down right away, but after a while the ArmoryDB processes stops anyway.

Weird.

A small possiblity for improving Armory:  ArmoryQT could check if ArmoryDB is already running, and give a warning/error or the like.  Currently, it just crashes.

[goatpig]

A small possiblity for improving Armory:  ArmoryQT could check if ArmoryDB is already running, and give a warning/error or the like.  Currently, it just crashes.

I going to tie Armory client shutdown to ArmoryDB's shutdown when the client spawns it. The distinction at startup is too wide to simplify it to just that.