mobile: Add ServiceStatus for retrieving started up status of lnd by hsjoberg · Pull Request #4595 · lightningnetwork/lnd

hsjoberg · 2020-09-04T13:21:40Z

This PR adds a new exported gomobile function ServiceStatus that can be used to figure out lnd's runtime state (as in whether it's considered started or not).
This is helpful in certain situations, see my comments below (#4595 (comment)).

Cheers

cfromknecht

@hsjoberg thanks for the PR! no major comments, just one small nit about avoiding race conditions

cfromknecht · 2020-09-15T17:55:57Z


+// LndStatus holds the current status of lnd.
+type LndStatus struct {
+	// lndStarted tells whether the lnd is started or not.


it looks these fields could use a mutex, since it's modified and read concurrently

bhandras · 2020-10-06T18:40:28Z

+}
+
+func GetStatus(callback LndStatusCallback) {
+	callback.OnResponse(lndStatus.lndStarted, lndStatus.walletUnlocked)


Is the application going to poll by calling GetStatus from time to time?

@bhandras No that's not what I had in mind -- rather call GetStatus once on app startup.
But sure an application could also possibly poll this one if needed.

halseth · 2020-10-09T11:22:48Z

@hsjoberg This is something we def want, but I'm hesitant to expose it as a mobile only API. Since we want this functionality also for LND in general, I think we rather should work on it as a "real" gRPC API (something I've started in the work with #3982)

hsjoberg · 2020-10-09T11:47:46Z

@halseth What I'm trying to accomplish is checking the state of lnd regardless if a gRPC server is active or not. So using a gRPC server here defeats the purpose.

Compared to running as a daemon/in terminal, when using mobile bindings you call lndmobile.Start to start up lnd and thus the gPRC server(s), so knowing beforehand if one should run Start becomes important (see OP for more info).

halseth · 2020-10-09T11:57:18Z

@hsjoberg I see, thanks for explaining! Would an alternative solution be to make Start idempotent, and return immediately if it notices that lnd already is running? (that way we don't have to add/change the API)

hsjoberg · 2020-10-09T14:27:40Z

@halseth Yes possibly if we can get #3982 rolling.
Well maybe not return, the first callback is being used to signal that lnd and the (as of now) walletunlocker rpc is ready, so that would have to be called immediately.

halseth · 2021-02-10T12:35:23Z

Aiming to solve something similar with #5005

hsjoberg · 2021-04-15T12:19:23Z

Closing this in favor of #5010 and #5005.

djkazic · 2023-07-23T19:58:36Z

I think we should revisit this. Currently, there is a chicken-or-egg problem when it comes to starting Blixt.

Start Blixt, set some local variable lndStarted = true
Background Blixt app
Now, Blixt app has lost tracked state of if lnd is running (react-native does not cleanly resume state when backgrounded app is resumed)
If we treat startLnd() as idempotent, we don't progress because it's already running and the callback is never fired
If we track state locally in a react-native variable outside of the mobile bindings context, we risk desyncing where the app's boolean flag is set to false for lndStarted due to reset app contexts on resume -- but it in fact is running. This can then lead to a collision where code that is only supposed to run when lnd is not running runs

For these reasons, I think it makes sense to expose status in a non-grpc manner, so mobile clients and other embedded-lnd usecases can track state reliably. GRPC is unusable at this stage of the app "booting up".

Also proposing a rename here of GetStatus -> ServiceStatus or something similar to clarify the purpose of the binding.

hsjoberg · 2026-02-19T13:18:20Z

Reopening this one as there are certain situations where it's beneficial or needed to know whether is considered started up or not, without querying the gRPC API itself.

In Blixt Wallet for Android, our background sync job calls stopDaemon in order to shutdown lnd and exit the job.
However, stopDaemon returns immediately and does not wait for the gRPCs to close down (kinda catch-22 if it would).
Android will then suspend the job, but preserving the go runtime in-process, causing issues the next time the user opens Blixt.
Therefore knowing from outside the gRPC whether lnd is started or not is needed, so that we can wait with exiting the job until after all gRPC servers are fully closed down.

Another potential scenario could be if the app needs to close down lnd, for example in order to change the configuration.
As aforementioned, response stopDaemon does not wait until lnd is completely shut down, so there is no good way to tell when it's possible to start lnd up again.

hsjoberg · 2026-02-19T13:19:34Z

Greatly simplified the implementation and changed the name of the function to ServiceStatus as per @djkazic's suggestion.

Also, this code has been used in production in Blixt for some years now, so it is battle-tested.

hsjoberg · 2026-02-19T13:26:47Z

/gemini review

gemini-code-assist

Code Review

This pull request introduces a ServiceStatus function to the mobile bindings, allowing the host application to check if the lnd service has been started. This is a useful addition for mobile applications to manage the lnd lifecycle correctly.

My review includes two main points:

A minor style guide fix for the function comment to adhere to the repository's standards.
A more critical fix for a potential data race by ensuring an atomic read of the status variable.

After addressing these points, the change should be good to merge.

hsjoberg · 2026-02-19T13:38:18Z

/gemini review

gemini-code-assist

Code Review

This pull request introduces a ServiceStatus function to allow mobile clients to query the status of the lnd service. This is a useful addition for mobile applications to handle state synchronization with the lnd process, especially in scenarios like service crashes.

My main feedback is to make the returned status more comprehensive by including the wallet's lock state, as mentioned in your pull request description. The current implementation only returns whether lnd has started. Expanding the status information would greatly increase the utility of this new API for mobile clients. I've provided a suggestion on how to structure this.

gemini-code-assist · 2026-02-19T13:42:40Z

+type LndStatusCallback interface {
+	OnResponse(lndStarted int32)
+}
+
+// ServiceStatus returns 1 if lnd has started up successfully, allowing the
+// caller to interact with the in-memory gRPC servers. If 0 is returned,
+// the caller should invoke `Start` to initialize lnd.
+//
+// ServiceStatus can also be used to determine when lnd has shut down, since
+// `stopDaemon` returns immediately and does not wait for the gRPC servers to be
+// fully closed.
+func ServiceStatus(callback LndStatusCallback) {
+	callback.OnResponse(atomic.LoadInt32(&lndStarted))
+}


Your PR description mentions that the status should include walletUnlocked, which is a great idea for mobile clients. The current implementation only returns lndStarted. To make this function more useful and align with your description, I suggest returning a structured status object.

This makes the API more extensible for future status fields. You could then use the generated gRPC bindings for the StateService to query the wallet's state when lnd is running.

Here is a suggested structure that you can build upon. Note that you'll also need to import the encoding/json package.

// LndStatus represents the current status of the lnd daemon. type LndStatus struct { LndStarted bool `json:"lnd_started"` // WalletState is the current state of the wallet, matching the states // from the `lnrpc.WalletState` enum. A value of 0 indicates that the // state is unknown, which is the case if lnd is not running. WalletState int `json:"wallet_state"` } // LndStatusCallback is an interface that must be implemented by the caller // to retrieve the service status. type LndStatusCallback interface { // OnResponse is called with the status of lnd, serialized as a JSON // byte slice. An error is returned as a string if one occurred. OnResponse(statusBytes []byte, errStr string) } // ServiceStatus retrieves the current status of the lnd daemon, including // whether it has started and the wallet's current state. The status is passed // to the provided callback as a JSON-encoded byte slice. func ServiceStatus(callback LndStatusCallback) { // NOTE: This implementation only returns the lndStarted status. // A future commit should expand this to query the wallet state via the // State gRPC service when lnd is running. status := &LndStatus{ LndStarted: atomic.LoadInt32(&lndStarted) == 1, } statusBytes, err := json.Marshal(status) if err != nil { callback.OnResponse(nil, "error marshalling status: "+err.Error()) return } callback.OnResponse(statusBytes, "") }

I've updated the PR description now.

The old implementation had walletUnlocked bool.
But to keep the scope low and functionality targeted, I suggest checking wallet state in the gRPC server later on once lnd is running. This can be done with subscribeState. It's basically a necessity for wallet apps to subscribe to this stream anyway.
Figuring out wallet state is a solved problem. However figuring out whether lnd is started is not.

Used for checking whether lnd is started or not. ServiceStatus can also be used to determine when lnd has shut down, since `stopDaemon` returns immediately and does not wait for the gRPC servers to be fully closed.

Roasbeef

LGTM 🐛

bhandras

LGTM! 🎉

litbot-9000 · 2026-08-10T06:10:50Z

@hsjoberg, remember to re-request review from reviewers when ready

litbot-9000 · 2026-08-17T07:16:08Z

@hsjoberg, remember to re-request review from reviewers when ready

litbot-9000 · 2026-08-24T07:58:20Z

@hsjoberg, remember to re-request review from reviewers when ready

hsjoberg force-pushed the lndmobile-status branch from 915084f to fa9ca9b Compare September 4, 2020 13:57

cfromknecht reviewed Sep 15, 2020

View reviewed changes

bhandras reviewed Oct 6, 2020

View reviewed changes

hsjoberg mentioned this pull request Mar 15, 2021

[mobile] Allow state API on mobile, simplify callback mechanism #5010

Merged

3 tasks

hsjoberg closed this Apr 15, 2021

hsjoberg reopened this Feb 19, 2026

hsjoberg force-pushed the lndmobile-status branch from fa9ca9b to 94a9972 Compare February 19, 2026 13:18

hsjoberg changed the title ~~mobile: Add GetStatus for retrieving current status of lnd~~ mobile: Add ServiceStatus for retrieving started up status of lnd Feb 19, 2026

litbot-9000 added the severity-medium Focused review required label Feb 19, 2026

gemini-code-assist Bot reviewed Feb 19, 2026

View reviewed changes

Comment thread mobile/bindings.go Outdated

Comment thread mobile/bindings.go Outdated

hsjoberg force-pushed the lndmobile-status branch from 94a9972 to 90937c2 Compare February 19, 2026 13:37

gemini-code-assist Bot reviewed Feb 19, 2026

View reviewed changes

mobile: Add ServiceStatus for retrieving current runtime status of lnd

aca307f

Used for checking whether lnd is started or not. ServiceStatus can also be used to determine when lnd has shut down, since `stopDaemon` returns immediately and does not wait for the gRPC servers to be fully closed.

hsjoberg force-pushed the lndmobile-status branch from 90937c2 to aca307f Compare February 19, 2026 15:00

Roasbeef approved these changes Feb 20, 2026

View reviewed changes

bhandras approved these changes Mar 27, 2026

View reviewed changes

Uh oh!

Conversation

hsjoberg commented Sep 4, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cfromknecht left a comment

Choose a reason for hiding this comment

Uh oh!

cfromknecht Sep 15, 2020

Choose a reason for hiding this comment

Uh oh!

bhandras Oct 6, 2020

Choose a reason for hiding this comment

Uh oh!

hsjoberg Oct 7, 2020

Choose a reason for hiding this comment

Uh oh!

halseth commented Oct 9, 2020

Uh oh!

hsjoberg commented Oct 9, 2020

Uh oh!

halseth commented Oct 9, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

hsjoberg commented Oct 9, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

halseth commented Feb 10, 2021

Uh oh!

hsjoberg commented Apr 15, 2021

Uh oh!

djkazic commented Jul 23, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

hsjoberg commented Feb 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

hsjoberg commented Feb 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

hsjoberg commented Feb 19, 2026

Uh oh!

gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

Uh oh!

Uh oh!

hsjoberg commented Feb 19, 2026

Uh oh!

gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

gemini-code-assist Bot Feb 19, 2026

Choose a reason for hiding this comment

Uh oh!

hsjoberg Feb 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Roasbeef left a comment

Choose a reason for hiding this comment

Uh oh!

bhandras left a comment

Choose a reason for hiding this comment

Uh oh!

litbot-9000 commented Aug 10, 2026

Uh oh!

litbot-9000 commented Aug 17, 2026

Uh oh!

litbot-9000 commented Aug 24, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

hsjoberg commented Sep 4, 2020 •

edited

Loading

halseth commented Oct 9, 2020 •

edited

Loading

hsjoberg commented Oct 9, 2020 •

edited

Loading

djkazic commented Jul 23, 2023 •

edited

Loading

hsjoberg commented Feb 19, 2026 •

edited

Loading

hsjoberg commented Feb 19, 2026 •

edited

Loading

hsjoberg Feb 19, 2026 •

edited

Loading