Running LND with systemd, Without Containers (6) - Configuring LND and Running It as a Service

Part 6 of the series. Part 5 gave LND an RPC login to bitcoind and turned on the ZMQ feeds.

Configuring LND

lnd.conf

LND’s configuration lives in /etc/lnd/lnd.conf, in the directory Part 4 created for it: owned by root, readable by the lnd group. It tells LND where bitcoind is and how to log in, using the lnd user and the password rpcauth.py printed in Part 5.

sudo cat /etc/lnd/lnd.conf

The RPC password is covered.

The two sides of each connection now match: the RPC address and login on the bitcoind side and the LND side, and the same two ZMQ addresses on both.

Who listens, who connects

In this lab, Bitcoin Core and LND run in the same VM, so every address is 127.0.0.1, the loopback address. Each one is either a port a program listens on, or a port another program connects to:

So the lines in lnd.conf point in different directions, even though they look alike:

# LND waits for connections on this address
rpclisten=127.0.0.1:10009

# LND connects out to Bitcoin Core at this address
bitcoind.rpchost=127.0.0.1:18443

The ZMQ addresses are connection targets from LND’s side too. LND subscribes to sockets that bitcoind opened, and tcp:// names the transport:

bitcoind.zmqpubrawblock=tcp://127.0.0.1:28332

Beyond the lab

On a production node, these addresses don’t all change the same way. Only one of them is meant for the outside world:

Changing every 127.0.0.1 to a public IP would put the Bitcoin RPC and the unauthenticated ZMQ feeds on the internet. The lab’s loopback-only setup is the safe default; only the Lightning port gets opened later, on purpose.

This file holds a secret. bitcoin.conf only stores a salt and HMAC, but LND needs the actual password to log in, so bitcoind.rpcpass is in plain text here. The file’s permissions are what protect it, so it gets the same treatment as bitcoin.conf in Part 2: root:lnd and 0640, readable by the lnd group and nobody else.

Running LND with systemd

The unit file

LND gets a unit file built the same way as bitcoind’s in Part 3:

sudo tee /etc/systemd/system/lnd.service > /dev/null <<'EOF'
[Unit]
Description=LND regtest node
Wants=bitcoind.service
After=bitcoind.service

[Service]
Type=simple
User=lnd
Group=lnd
ExecStart=/usr/local/bin/lnd --configfile=/etc/lnd/lnd.conf --lnddir=/var/lib/lnd
Restart=on-failure
RestartSec=5
TimeoutStopSec=300
UMask=0077
NoNewPrivileges=true
ProtectHome=true
ProtectSystem=full

[Install]
WantedBy=multi-user.target
EOF

Most of it is Part 3’s unit with bitcoin swapped for lnd: the same restart policy, the same shutdown window, and the same four hardening lines. The new parts:

Wants= and After= do different jobs, which is why both are here. Wants= pulls Bitcoin Core in; After= orders the two.

Neither one says anything about the RPC connection between them. systemd manages processes: it can start bitcoind before LND, but it doesn’t know what RPC is, and After= waits only for bitcoind’s process to be started, not for its RPC to answer. Whether LND can actually reach bitcoind, with the right address, the rpcauth login, and the ZMQ feeds, is a separate question, answered by LND’s own logs once it runs. If LND comes up before bitcoind’s RPC is ready, Restart=on-failure tries again five seconds later; if the address or the password is wrong, restarting won’t fix it, and the logs will say so.

Checking, starting, and the first status

The same three steps as for bitcoind in Part 3, then status:

sudo systemd-analyze verify /etc/systemd/system/lnd.service
sudo systemctl daemon-reload
sudo systemctl start lnd
sudo systemctl status lnd --no-pager -l

verify flagged nothing in lnd.service; the two warnings are the same Ubuntu XFS units as in Part 3. LND is active (running) as its own process, with the configuration and data paths from the unit.

The log tells the rest of the story:

That last line is where this part of the setup ends. A running process isn’t a working node yet: LND hasn’t connected to bitcoind at this point, because it starts its chain backend only after the wallet is unlocked. So the RPC login and the ZMQ feeds still haven’t been tested by LND itself. Creating the wallet comes next, and LND’s logs after that will show whether it reached bitcoind.

Loaded: … disabled is also back, the same as bitcoind in Part 3 before enable. Once LND has shown it can run end to end, sudo systemctl enable lnd wires it to boot the same way.

The full log with journalctl

status shows only the last few lines. When something goes wrong, the full log is in the systemd journal, which collects the output of both services:

sudo journalctl -u lnd -n 40 --no-pager

The earlier lines that status cut off fill in the startup:

So the two admin APIs are listening where lnd.conf says, and nothing failed. The wallet is next.

Creating the wallet

LND keeps its on-chain funds and channel keys in a wallet, and it won’t go further until that wallet exists. lncli create makes one through the gRPC API that’s already listening:

sudo -u lnd lncli --lnddir=/var/lib/lnd --network=regtest --rpcserver=127.0.0.1:10009 create

The cipher seed is covered.

create asks three things:

LND then prints the cipher seed: 24 words that can recreate the wallet’s keys on any machine. I wrote them down and stored them away from the VM. The password and the seed do different jobs. The password protects the wallet file on this disk; the seed is the wallet itself, so anyone holding the words holds the funds, which is why LND prints the warning twice. These are regtest coins, but I treat the seed the way I would on mainnet.

lnd successfully initialized! means the wallet exists and is unlocked, so LND can now move past the line it was waiting on and start its chain backend.

Is LND talking to bitcoind?

getinfo is the quickest way to see what LND knows about the chain, and the chain is something it can only learn from bitcoind:

sudo -u lnd lncli --lnddir=/var/lib/lnd --network=regtest --rpcserver=127.0.0.1:10009 getinfo

The tip height and hash match bitcoind exactly, which answers the question this part kept open: LND logged in over RPC with the rpcauth credentials and is reading the chain from the local Bitcoin Core.

synced_to_chain: false looks wrong next to a matching tip, but it comes from the tip’s age, not from the connection. Like initialblockdownload in Part 3, LND judges whether it’s caught up partly by how recent the best block is, and the last block on this chain was mined hours before this check. On regtest no new block arrives unless I mine one.

So I mined one more block, and added an lncli shortcut, lnc, built like Part 3’s btc:

MINER_ADDRESS=$(btc -rpcwallet=miner getnewaddress)
btc generatetoaddress 1 "$MINER_ADDRESS"
lnc() {
  sudo -u lnd lncli \
    --lnddir=/var/lib/lnd \
    --network=regtest \
    --rpcserver=127.0.0.1:10009 \
    "$@"
}
lnc getinfo

MINER_ADDRESS is set again because shell variables don’t outlive the session where Part 3 created it. The new address comes from the same miner wallet.

A fresh tip was all synced_to_chain needed, as expected. The block hash matters more: LND reports the block bitcoind mined moments earlier, without being restarted or asked to look. With a bitcoind backend, LND learns about new blocks from the zmqpubrawblock feed, so this is the ZMQ path from Part 5 working end to end, alongside the RPC login.

LND is running under systemd, logged in to Bitcoin Core over RPC, receiving blocks over ZMQ, and synced to the chain.

Funding the LND wallet

An address and an unconfirmed deposit

A Lightning node needs on-chain bitcoin before it can open a channel. LND’s wallet can hand out as many receiving addresses as needed, one per deposit if I like, so I asked it for a new one and sent it 1 BTC from the miner wallet:

lnc newaddress p2wkh
read -r -p 'LND deposit address: ' LND_ADDRESS
btc -rpcwallet=miner -named sendtoaddress address="$LND_ADDRESS" amount=1 fee_rate=2
btc getrawmempool
lnc walletbalance

The read prompt in the screenshot is in Korean; it means “LND deposit address”.

walletbalance shows 100,000,000 sat, exactly 1 BTC, as unconfirmed_balance, with nothing confirmed yet. That matches the mempool: the payment exists but isn’t in a block.

LND knowing about it at all is the other half of the ZMQ check. The transaction is only in bitcoind’s mempool, and the way LND hears about mempool transactions is the zmqpubrawtx feed from Part 5. The block feed showed up in the height change above; this shows the transaction feed.

Confirming it

Mining one block puts the payment into the chain:

MINER_ADDRESS=$(btc -rpcwallet=miner getnewaddress)
btc generatetoaddress 1 "$MINER_ADDRESS"
btc getrawmempool
lnc walletbalance

The mempool is empty because the new block included the payment, and LND moved the full 1 BTC from unconfirmed to confirmed. It learned about the block over ZMQ again, without being asked. The node now has confirmed funds on chain, which is what opening a channel will need.

Reading the transaction from LND’s side

listchaintxns lists the on-chain transactions LND’s wallet is involved in, with everything it knows about each:

lnc listchaintxns

The numbers add up. The input was a 50 BTC reward, 5,000,000,000 sat. The two outputs come to 4,999,999,718 sat, so the fee was 282 sat. At the fee_rate=2 I asked for, that’s a 141-vbyte transaction, the usual size of a SegWit payment with one input and two outputs.

The fee, from the sender’s side

LND reports total_fees: 0 because it didn’t pay any. The sender did, and the miner wallet in bitcoind records it directly:

btc -rpcwallet=miner gettransaction \
  43e03f34b609f98438072831febd4b92d12a4a5f88da612d4eb76c3de057ca25

The two wallets describe the same transaction from opposite ends. bitcoind’s miner wallet shows 1 BTC out and 282 sat in fees; LND shows 1 BTC in and no fee of its own. Together they account for every satoshi of the 50 BTC input.

Where this leaves the lab

LND is now a working regtest node: managed by systemd, logged in to Bitcoin Core over RPC with its own credentials, following the chain over ZMQ, and holding 1 BTC of confirmed funds.

A second node, connected

Opening a channel needs a second node. I set one up in the same VM by repeating this series’ steps with its own user, directories, and ports, pointed at the same bitcoind, and with its own lncli shortcut, lnb. Since the setup is identical, I’m not walking through it again; the result is what matters. The two nodes are connected as peers:

lnc listpeers
lnb listpeers

Each node lists the other’s public key, so the connection runs both ways. Both nodes share the VM and one bitcoind, which is why loopback addresses work here; nodes on separate machines would need the reachable Lightning port described in “Beyond the lab”.

lnc walletbalance
lnb listchannels
lnc listchannels
lnb walletbalance

The starting position for a channel is set. The nodes are peers, neither has a channel yet, and the funds are on the lnc side, which is the side that will open the channel and commit those funds to it.

Next: Opening a channel and sending a payment.