Skip to content

CLI login error / panic: runtime error: invalid memory address or nil pointer dereference #7610

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
1 of 6 tasks
Sobczaczek opened this issue Apr 29, 2025 · 3 comments · May be fixed by #7621
Open
1 of 6 tasks

CLI login error / panic: runtime error: invalid memory address or nil pointer dereference #7610

Sobczaczek opened this issue Apr 29, 2025 · 3 comments · May be fixed by #7621
Assignees
Labels
bug Something isn't working
Milestone

Comments

@Sobczaczek
Copy link

Summary

Getting the title error while trying to login using command:
ttn-lw-cli login --api-key $TTS_DEFAULT_CLI_API_KEY

This looks like new bug in release 3.34.1, because I get no error while using 3.33.0 version.

I use TTS as docker contenerized and locally deployed LoRaWAN network.

I follow every step of tutorial: https://www.thethingsindustries.com/docs/enterprise/docker/running-the-stack/

To additional automization I create CLI API key using:
docker compose run --rm stack is-db create-user-api-key ,
then I use that key to login, create default application, application API key etc.

Steps to Reproduce

  1. docker compose pull
  2. docker compose run --rm stack is-db migrate
  3. docker compose run --rm stack is-db create-admin-user
    --id admin
    --email [email protected]
  4. docker compose run --rm stack is-db create-oauth-client
    --id cli
    --name "Command Line Interface"
    --owner admin
    --no-secret
    --redirect-uri "local-callback"
    --redirect-uri "code"
  5. docker compose run --rm stack is-db create-oauth-client
    --id ${ID}
    --name "${NAME}"
    --owner admin
    --secret "${CLIENT_SECRET}"
    --redirect-uri "${REDIRECT_URI}"
    --redirect-uri "${REDIRECT_PATH}"
    --logout-redirect-uri "${LOGOUT_REDIRECT_URI}"
    --logout-redirect-uri "${LOGOUT_REDIRECT_PATH}"
  6. docker compose run --rm stack is-db create-user-api-key
    --user-id admin
    --name "cli default API key"
  7. docker exec stack ttn-lw-cli login
    --api-key <cli_default_API_key>
    --insecure

Current Result

Login fail, further actions with API KEY cannot be done, cause of the lack of the authentication

Expected Result

Login should succed, then command should be corectly authenticted:
INFO (4.8) Creating default API key for application 'default-app'...
INFO Telemetry is enabled. Check the documentation for more information on what is collected and how to disable it {"documentation_url": "https://www.thethingsindustries.com/docs/reference/telemetry/cli"}
WARN Using insecure connection to OAuth server
WARN Using insecure connection to API
INFO API key ID:
INFO API key value:

Relevant Logs

WARN    Using insecure connection to OAuth server
WARN    Using insecure connection to API
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0x2478750]

goroutine 80 [running]:
go.thethings.network/lorawan-stack/v3/pkg/telemetry/exporter/cli.(*cliTask).Run(0xc000f9cbd0, {0x3255988?, 0xc000f85080?})
        /home/runner/work/lorawan-stack/lorawan-stack/pkg/telemetry/exporter/cli/cli.go:171 +0xf0
go.thethings.network/lorawan-stack/v3/cmd/ttn-lw-cli/commands.init.preRun.func239.2({0x3255988, 0xc000f85080})
        /home/runner/work/lorawan-stack/lorawan-stack/cmd/ttn-lw-cli/commands/root.go:184 +0xa2
created by go.thethings.network/lorawan-stack/v3/cmd/ttn-lw-cli/commands.init.preRun.func239 in goroutine 1
        /home/runner/work/lorawan-stack/lorawan-stack/cmd/ttn-lw-cli/commands/root.go:180 +0x559

URL

No response

Deployment

The Things Stack Open Source (self-hosted)

The Things Stack Version

3.34.1

Client Name and Version

$ ttn-lw-cli version
The Things Network Command-line Interface: ttn-lw-cli
Version:             3.34.1
Build date:          2025-04-28T08:37:25Z
Git commit:          e22b9512d
Go version:          go1.23.3
OS/Arch:             linux/amd64

Other Information

No response

Proposed Fix

No response

Contributing

  • I can help by doing more research.
  • I can help by implementing a fix after the proposal above is approved.
  • I can help by testing the fix before it's released.

Validation

Code of Conduct

@Sobczaczek Sobczaczek added the needs/triage We still need to triage this label Apr 29, 2025
@Sobczaczek
Copy link
Author

To clarify, steps to reproduce are with default values from tutorial. Of course I use my own values during deployment.

@KrishnaIyer KrishnaIyer added bug Something isn't working and removed needs/triage We still need to triage this labels Apr 30, 2025
@KrishnaIyer KrishnaIyer added this to the v3.34.2 milestone Apr 30, 2025
@nicholaspcr
Copy link
Contributor

nicholaspcr commented May 7, 2025

Thanks for creating the issue, I did manage to replicate and I'll be opening a PR to fix that behavior in the next release.

I'm not sure as to why it was not happening in the 3.33.0, since the problem stems from a non configured cli telemetry path.
We use the XDG_CACHE_HOME value to create a temporary file for anything telemetry related in the CLI.

There are a few ways to fix this while the next release is not out.

  1. Add the value of XDG_CACHE_HOME:
  stack:
    image: thethingsnetwork/lorawan-stack:latest
    # ...
    volumes:
      - ./blob:/srv/ttn-lorawan/public/blob
      - ./config/stack:/config:ro
      - ./config/stack/cache:/cache # defined a new volume for anything cache or telemetry related
      # If using Let's Encrypt:
      - ./acme:/var/lib/acme
    environment:
      TTN_LW_BLOB_LOCAL_DIRECTORY: /srv/ttn-lorawan/public/blob
      TTN_LW_REDIS_ADDRESS: redis:6379
      TTN_LW_IS_DATABASE_URI: postgres://root:root@postgres:5432/ttn_lorawan?sslmode=disable
      XDG_CACHE_HOME: /cache
    # ...
  1. Disable telemetry by adding the env variable TTN_LW_TELEMETRY_ENABLE and set it to false
  stack:
    image: thethingsnetwork/lorawan-stack:latest
    # ...
    environment:
      TTN_LW_TELEMETRY_ENABLE: false

@Sobczaczek
Copy link
Author

@nicholaspcr the fix you provided seems to be working, deployment was now without errors, thank you very much for that.

Regarding the issue in 3.33.0 version - I think I have managed to have same error that described in this issue, but I think it was somehow related to my own miss-configuration, I can not really tell right now, I have managed to resolve it. If I remember corectly it was that time when I was deploying stack inside closed non-internet LAN enviroment.

@nicholaspcr nicholaspcr linked a pull request May 11, 2025 that will close this issue
7 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants