[bug]: lncli getinfo indicates "synced_to_chain: false" despite logs showing "Chain backend is fully synced"

[Dominion5254]

Background

Reporting behavior described by @chrisguida here.
lncli getinfo return value indicates "synced_to_chain": false - despite the logs indicating "Chain backend is fully synced".

Logs:

2024-09-05T18:24:10-06:00  2024-09-06 00:24:10.173 [INF] LNWL: Started rescan from block 00000000000000000001e49e5678118a46d43055ebfcd493249da9cf8a2a2f81 (height 860066) for 27726 addresses
2024-09-05T18:24:10-06:00  2024-09-06 00:24:10.285 [INF] LNWL: Catching up block hashes to height 860066, this might take a while
2024-09-05T18:24:10-06:00  2024-09-06 00:24:10.293 [INF] LNWL: Done catching up block hashes
2024-09-05T18:24:10-06:00  2024-09-06 00:24:10.293 [INF] LNWL: Finished rescan for 27726 addresses (synced to block 00000000000000000001e49e5678118a46d43055ebfcd493249da9cf8a2a2f81, height 860066)
2024-09-05T18:24:10-06:00  2024-09-06 00:24:10.386 [INF] LTND: Chain backend is fully synced (end_height=860066)!
2024-09-05T18:24:10-06:00  2024-09-06 00:24:10.386 [INF] NANN: HostAnnouncer starting
2024-09-05T18:24:10-06:00  2024-09-06 00:24:10.386 [WRN] HLCK: check: disk space configured with 0 attempts, skipping it
2024-09-05T18:24:10-06:00  2024-09-06 00:24:10.386 [WRN] HLCK: check: tls configured with 0 attempts, skipping it
2024-09-05T18:24:10-06:00  2024-09-06 00:24:10.386 [INF] LNWL: SigPool starting
2024-09-05T18:24:10-06:00  2024-09-06 00:24:10.389 [INF] NTFN: New block epoch subscription
2024-09-05T18:24:10-06:00  2024-09-06 00:24:10.389 [INF] NTFN: New block epoch subscription
2024-09-05T18:24:10-06:00  2024-09-06 00:24:10.389 [INF] CHNF: ChannelNotifier starting
2024-09-05T18:24:10-06:00  2024-09-06 00:24:10.389 [INF] PRNF: PeerNotifier starting
2024-09-05T18:24:10-06:00  2024-09-06 00:24:10.389 [INF] BTCN: Broadcaster now active
2024-09-05T18:24:10-06:00  2024-09-06 00:24:10.389 [INF] HSWC: HtlcNotifier starting
2024-09-05T18:24:10-06:00  2024-09-06 00:24:10.389 [INF] NTFN: New block epoch subscription

Your environment

• LND 0.18.0 running on StartOS 0.3.5~1
• bitcoind backend (fully synced)

Steps to reproduce

Behavior can't seem to be reproduced aside from the user in question. But for the user in question, the behavior persists across restarts of lnd.

Expected behaviour

If the logs are indicating "Chain backend is fully synced', lncli getinfo requests should show synced_to_chain as true.

Actual behaviour

Despite the logs indicating "Chain backend is fully synced', lncli getinfo requests indefinitely continue to show synced_to_chain as false.

[ziggie1984]

This can easily be possible. The log entry just confirms that the sync was true when starting up lnd, however this can change during operation. Can you provide your lncli getinfo output especially for:

    "block_height": 860983,
    "block_hash": "000000000000000000020bd8864ba9f95d91e115ab83717b74494a3e4bf3deae",
    "best_header_timestamp": "1726131695",

[chrisguida]

It's definitely staying synced to tip

    "num_pending_channels":  0,
    "num_active_channels":  0,
    "num_inactive_channels":  1,
    "num_peers":  0,
    "block_height":  861031,
    "block_hash":  "000000000000000000016a449be0aea93340660276ff4e52b0df6dea7336af5f",
    "best_header_timestamp":  "1726157341",
    "synced_to_chain":  false,
    "synced_to_graph":  false,
    "testnet":  false,
    "chains":  [
        {
            "chain":  "bitcoin",
            "network":  "mainnet"
        }
    ],

[guggero]

Might want to check your ZMQ settings.

[chrisguida]

What am I looking for?

lnd.conf:

# cat .lnd/lnd.conf | grep zmq
bitcoind.zmqpubrawblock=tcp://bitcoind.embassy:28332
bitcoind.zmqpubrawtx=tcp://bitcoind.embassy:28333

bitcoin.conf:

## ZERO MQ
zmqpubrawblock=tcp://0.0.0.0:28332
zmqpubhashblock=tcp://0.0.0.0:28332
zmqpubrawtx=tcp://0.0.0.0:28333
zmqpubhashtx=tcp://0.0.0.0:28333
zmqpubsequence=tcp://0.0.0.0:28333

[guggero]

I'd try removing the types lnd doesn't need (and possibly doesn't understand):

zmqpubhashblock=tcp://0.0.0.0:28332
zmqpubhashtx=tcp://0.0.0.0:28333
zmqpubsequence=tcp://0.0.0.0:28333

[chrisguida]

Those are needed for other services, I can't remove them

[chrisguida]

I can temporarily disable, but this is a bug if the solution is to turn them off

[chrisguida]

Anyway those settings have been active on Start9 for a couple of years at least, I doubt that's the issue. Discussing with @Dominion5254 how to turn three of these off while leaving the other two on

[Dominion5254]

I'd try removing the types lnd doesn't need (and possibly doesn't understand):

zmqpubhashblock=tcp://0.0.0.0:28332
zmqpubhashtx=tcp://0.0.0.0:28333
zmqpubsequence=tcp://0.0.0.0:28333

This seems like a red herring. Every single lnd-startos user has these same config options set in their Bitcoin Core config - But aside from Chris's case, this particular issue has never come up before.

Is there anything else that could explain this behavior?

[guggero]

Okay, was just a hunch.

[bitromortac]

Does it still report as not being synced? Are there any changes to bitcoin.conf or lnd.conf compared to the original configuration?

[ziggie1984]

Can you also verify you are not doing a wallet rescan by accident, because LND will not report sync_to_chain=true, in case your walllet is not caught up with the current chain.