If you accidentally warp your clock backwards far enough, you'll cause log noise and stall:
2015-11-11 12:34:56 ERROR: CheckBlockHeader(): block timestamp too far in the future
2015-11-11 12:34:56 InvalidChainFound: invalid block=00000000000000000d22b34a54be999f4eadde2ee895c208d4b3dc0210aa044f height=123456 log2_work=12.345678 date=2015-11-11 12:34:56
2015-11-11 12:34:56 ERROR: ConnectTip(): ConnectBlock 00000000000000000d22b34a54be999f4eadde2ee895c208d4b3dc0210aa044f failed
but after you restart, the futuristic-looking block causing the stall is still considered invalid and no more messages about it get logged. If you miss the original message and you don't tend to scan backwards past the most recent startup, you'll see a comforting LoadBlockIndexDB: hashBestChain=... and No coin database inconsistencies in last N blocks at startup, and you'll see the node acquiring peers; you might see more ConnectInputs failed and AcceptToMemoryPool: non-final than usual, but nothing explicit to alert you to the fact that the longest chain is considered invalid, nor why.
@laanwj suggests "'timestamp too far in the future' is a temporary condition, it probably shouldn't cache it indefinitely"; failing that, maybe it's easy enough to get caught in this trap that it merits an extra startup-time breadcrumb in the logs.
