[ajaysehwal]

We loaded the TLS config, bound the gRPC port and registered the signal handlers only after node.start(). If the port was already in use we panicked, which with panic = "abort" kills a node that is already running without calling node.stop(). A SIGTERM or Ctrl-C during node.start() killed the process without a graceful shutdown.

Now we load the TLS config and bind the listener before starting the node, exiting with an error if either fails, and register the SIGHUP, SIGTERM and SIGINT handlers up front. Signals received during startup are handled by the main loop once the node is running. This still happens after building the node, so a restarting instance keeps waiting for a Postgres lease held by the previous one.

Tested against a mock Esplora server:

• Port already in use: before, the node started and then aborted (exit -6). Now it exits with Failed to bind gRPC service address before starting the node.
• SIGTERM during node.start(): before, the process was killed (exit -15). Now it shuts down gracefully (exit 0).

Added e2e test test_config_fail_grpc_address_in_use. It compiles, but I couldn't run it locally because it needs bitcoind.

[ldk-reviews-bot]

👋 Thanks for assigning @benthecarman as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[ajaysehwal]

Hi @benthecarman, when you have time, could you take a look at this? It sets up TLS, the gRPC bind and the signal handlers before node.start(), so a port conflict or TLS error no longer leaves a running node that then aborts, and a SIGTERM during startup shuts down gracefully instead of killing the process. The second commit adds a flock on the network directory so two instances can't share one SQLite store.

One decision I'd like your input on: the lock adds a direct libc dependency (already in the lock file via other crates) and one unsafe call. If you'd rather not have that, I can drop it from this PR (or open it separately) and keep only the first commit. I added the "proof" output for each case to the description.

[Anyitechs]

Tested ACK 6b1396f!

Tested the changes on my ubuntu server and both work well. The changes proposed in the second commit makes sense as well, but I don't have an opinion on the approach.

[benthecarman]

the second commit is not needed, we do this in our database already.

also please don't just have AI write your entire PR desc and commit message without you cleaning it up first

[ajaysehwal]

the second commit is not needed, we do this in our database already.

also please don't just have AI write your entire PR desc and commit message without you cleaning it up first

Thanks, dropped the lock commit and shortened the commit message and description. I had added the long write-up and repro output just to show the issue was real, but I understand it was too much. I’ve kept only a short summary.