A SIGTERM shouldn't corrupt anything?
No idea, I prefer BareMetal OS. I don't like interface with a lot of icons.
SIGTERM is the signal sent by Unix 'kill' command as the standard way to cleanly shutdown a process.
Taking a short look at the code, totally possible that it messes up everything.
Usually, you'd first write to a temporary file, and when it's finished you'd move it in place and therefore overwrite the old one, since that's only one atomic operation...
In case the process ends while writing, you just have a half-written temporary lying around.
This client doesn't do the moving thing, so as soon as you SIGKILL or even SIGTERM it while it's writing, it's in a bad state.
Ok... brushed up on my Java and dove in:
@Override
public void destroy() {
scheduledThreadPool.shutdown();
cachedThreadPool.shutdown();
try {
Block.saveBlocks("blocks.nxt");
} catch (Exception e) { }
try {
Transaction.saveTransactions("transactions.nxt");
} catch (Exception e) { }
try {
blockchainChannel.close();
} catch (Exception e) { }
logMessage("Nxt stopped.");
}
}
Since scheduledThreadPool.shutdown() (and cachedThreadPool) doesn't wait for the threads to actually finish before returning, it might create a condition where saveBlocks blocks the threads that are trying to shutdown due to the synchronized on blocks. So it might be possible for destroy() to exit before the thread pools have completely shutdown, which could cause corruption of blocks.nxt if something bad happens in the threads.
The fix is to call
awaitTermination on the threadpools before call Block.saveBlocks.
TRULY APPRECIATED! 
