crashes on start

[tcurdt]

Describe the bug

I am starting k9s and get a crash with exit 1

k9s
Error: exit status 1
Usage:
  k9s [flags]
  k9s [command]

Available Commands:
  completion  Generate the autocompletion script for the specified shell
  help        Help about any command
  info        List K9s configurations info
  version     Print version/build info

Flags:
  -A, --all-namespaces                 Launch K9s in all namespaces
      --as string                      Username to impersonate for the operation
      --as-group stringArray           Group to impersonate for the operation
      --certificate-authority string   Path to a cert file for the certificate authority
      --client-certificate string      Path to a client certificate file for TLS
      --client-key string              Path to a client key file for TLS
      --cluster string                 The name of the kubeconfig cluster to use
  -c, --command string                 Overrides the default resource to load when the application launches
      --context string                 The name of the kubeconfig context to use
      --crumbsless                     Turn K9s crumbs off
      --headless                       Turn K9s header off
  -h, --help                           help for k9s
      --insecure-skip-tls-verify       If true, the server's caCertFile will not be checked for validity
      --kubeconfig string              Path to the kubeconfig file to use for CLI requests
      --logFile string                 Specify the log file (default "/home/ops/.local/state/k9s/k9s.log")
  -l, --logLevel string                Specify a log level (info, warn, debug, trace, error) (default "info")
      --logoless                       Turn K9s logo off
  -n, --namespace string               If present, the namespace scope for this CLI request
      --readonly                       Sets readOnly mode by overriding readOnly configuration setting
  -r, --refresh int                    Specify the default refresh rate as an integer (sec) (default 2)
      --request-timeout string         The length of time to wait before giving up on a single server request
      --screen-dump-dir string         Sets a path to a dir for a screen dumps
      --token string                   Bearer token for authentication to the API server
      --user string                    The name of the kubeconfig user to use
      --write                          Sets write mode by overriding the readOnly configuration setting

Use "k9s [command] --help" for more information about a command.

panic: exit status 1

goroutine 1 [running]:
github.com/derailed/k9s/cmd.Execute()
        github.com/derailed/k9s/cmd/root.go:72 +0x77
main.main()
        github.com/derailed/k9s/main.go:32 +0xf

To Reproduce
Steps to reproduce the behavior:

1. install via nix stable
2. run k9s

Expected behavior
It should not crash. (Used to work fine before)

Versions (please complete the following information):

• OS: nixOS
• K9s: 0.32.5
• K8s: k3s version v1.30.4+k3s1 (98262b5d)

[tcurdt]

I found the issue. It's related the to TERM variable.
I recently switched to ghostty. When I switch ssh over to

  SetEnv TERM=xterm-256color

for the ssh connection k9s works again.

But it should not panic like this with a "wrong" TERM setting.

[jasperjanuar]

I'm experiencing the same with
Versions (please complete the following information):

• OS: Ubuntu 22.04.4 LTS (GNU/Linux 6.5.0-1022-azure x86_64)
• K9s: 0.31.9
• K8s: v1.30.5

[KevinGimbel]

@jasperjanuar @tcurdt Please update k9s to the latest version and try again, it's working for me with Ghostty 1.0.1 and k9s 0.32.7 on MacOS.

If it works for you, please close this issue. Thanks! :)

[tcurdt]

I am still seeing these crashes with

Version:    0.32.7
Commit:     v0.32.7

on nixOS. Only setting SetEnv TERM=xterm-256color fixes them.

[KevinGimbel]

@tcurdt interesting, thank you! You're also on the latest Ghostty? I'll see if I can spin up a NixOS VM for debugging further.

[jasperjanuar]

Experiencing the same as @tcurdt. Updated ghostty to 1.0.1 and k9s to 0.32.7. Only after setting set TERM xterm-256color(using fish v. 3.3.1) k9s will run

[KevinGimbel]

That's odd. I'm using Ghostty 1.0.1 with zsh and this is my env

printenv |grep TERM
TERM_PROGRAM=ghostty
TERM=xterm-ghostty
TERM_PROGRAM_VERSION=1.0.1
TERMINFO=/Applications/Ghostty.app/Contents/Resources/terminfo
COLORTERM=truecolor

[jasperjanuar]

I think the crux is that the VM I'm trying to use ghostty on doesn't support it as a terminal - yet. There is a section on ghostty's documentation here:

https://ghostty.org/docs/help/terminfo#configure-ssh-to-fall-back-to-a-known-terminfo-entry

Most likely not an issue with k9s

If I run it locally on MacOS 15.1.1

printenv |grep TERM
TERM_PROGRAM=ghostty
TERM=xterm-ghostty
TERM_PROGRAM_VERSION=1.0.1
TERMINFO=/Applications/Ghostty.app/Contents/Resources/terminfo
COLORTERM=truecolor

it works just fine.

[tcurdt]

I am also on ghosty 1.0.1.

Most likely not an issue with k9s

If k9s crashes, it is an issue with k9s.

I think the crux is that the VM I'm trying to use ghostty on doesn't support it as a terminal - yet. There is a section on ghostty's documentation here:
...
If I run it locally on MacOS

I am a little puzzled what you mean.

I am connecting from macOS to a nixOS host.
Not matter the terminfo - k9s should not crash.

[tcurdt]

@tcurdt interesting, thank you! You're also on the latest Ghostty? I'll see if I can spin up a NixOS VM for debugging further.

Before you do that work - do other linux distros work with TERM=xterm-ghostty k9s?

[tcurdt]

This is the breaking env on nixOS:

$ printenv | grep TERM
TERM=xterm-ghostty
TERMINFO_DIRS=/home/ops/.nix-profile/share/terminfo:/nix/profile/share/terminfo:/home/ops/.local/state/nix/profile/share/terminfo:/etc/profiles/per-user/ops/share/terminfo:/nix/var/nix/profiles/default/share/terminfo:/run/current-system/sw/share/terminfo

[KevinGimbel]

According to the README you should set TERM=xterm-256color

[tcurdt]

As I said, setting TERM=xterm-256color makes it work. But k9s should not crash without it.

Even just an exit(1) with "Your TERM env var is FOO but k9s requires xterm-256color" would be OKish.

[KevinGimbel]

As I said, setting TERM=xterm-256color makes it work. But k9s should not crash without it.

Sorry, I forgot/didn't see.

Even just an exit(1) with "Your TERM env var is FOO but k9s requires xterm-256color" would be OKish.

I agree. I do wonder from where the problem comes as I've seen other CLIs "struggle" with the xterm-ghostty value. I'll see if we can at least have a cleaner exit.