Messed background colors for logfiles when running lnav in a container

[OJarrisonn]

lnav version
v0.12.3

Describe the bug

I'm trying to run lnav inside an alpine container and the background colors are not right as you can see

To Reproduce

I'm using the following dockerfile:

FROM alpine:3.16

RUN wget https://github.com/tstack/lnav/releases/download/v0.12.3/lnav-0.12.3-linux-musl-x86_64.zip && \
	unzip lnav-0.12.3-linux-musl-x86_64.zip && \
	cp lnav-0.12.3/lnav /bin/ && \
	rm -rf lnav-0.12.3-linux-musl-x86_64.zip lnav-0.12.3-linux-musl-x86_64

VOLUME [ "/logs" ]
WORKDIR /logs

ENTRYPOINT ["lnav", "/logs"]

Trying to read the following file:

172.22.0.1 - - [09/Jan/2025:13:01:56 +0000] "POST /api/checaSess/ HTTP/1.1" 403 43 "-" "okhttp/4.10.0"
172.22.0.1 - - [09/Jan/2025:13:02:41 +0000] "POST /api/cadastrar/ HTTP/1.1" 200 37 "-" "okhttp/4.10.0"
172.22.0.1 - - [09/Jan/2025:13:02:41 +0000] "POST /api/login/ HTTP/1.1" 200 601 "-" "okhttp/4.10.0"
172.22.0.1 - - [09/Jan/2025:13:02:42 +0000] "GET / HTTP/1.1" 200 56 "-" "okhttp/4.10.0"
172.22.0.1 - - [09/Jan/2025:13:02:42 +0000] "POST /api/sincronizaViagens/ HTTP/1.1" 200 35 "-" "okhttp/4.10.0"
172.22.0.1 - - [09/Jan/2025:13:02:43 +0000] "POST /api/geraExtrato/ HTTP/1.1" 200 109 "-" "okhttp/4.10.0"
172.22.0.1 - - [09/Jan/2025:13:02:43 +0000] "POST /api/viagensFaltantes/ HTTP/1.1" 200 44 "-" "okhttp/4.10.0"
172.22.0.1 - - [09/Jan/2025:13:02:43 +0000] "POST /api/geraExtrato/ HTTP/1.1" 200 109 "-" "okhttp/4.10.0"
172.22.0.1 - - [09/Jan/2025:13:02:43 +0000] "POST /api/exibeBonus/ HTTP/1.1" 200 20 "-" "okhttp/4.10.0"
172.22.0.1 - - [09/Jan/2025:13:02:43 +0000] "POST /api/exibeContestacoes/ HTTP/1.1" 200 20 "-" "okhttp/4.10.0"
172.22.0.1 - - [09/Jan/2025:13:02:43 +0000] "POST /api/sincronizaLocs/ HTTP/1.1" 200 186 "-" "okhttp/4.10.0"
172.22.0.1 - - [09/Jan/2025:13:02:43 +0000] "POST /api/recebeParesValidos/ HTTP/1.1" 200 4481 "-" "okhttp/4.10.0"
172.22.0.1 - - [09/Jan/2025:13:02:44 +0000] "POST /api/notificacoes/regToken/ HTTP/1.1" 200 160 "-" "okhttp/4.10.0"
172.22.0.1 - - [09/Jan/2025:13:04:26 +0000] "POST /api/regViagem/ HTTP/1.1" 200 196 "-" "okhttp/4.10.0"
172.22.0.1 - - [09/Jan/2025:13:04:26 +0000] "POST /api/geraExtrato/ HTTP/1.1" 200 109 "-" "okhttp/4.10.0"

The image is being used as a service:

  logs:
    build:
      context: ./deploy
      dockerfile: logs.Dockerfile
    stdin_open: true
    tty: true
    attach: false
    volumes:
      - "logs:/logs:ro"
    restart: "no"

Finally, i'm running the service with:

docker compose up logs -d --build
docker compose exec logs lnav .

And this results in the above screenshot. The same result persists when I'm using different shells (nushell and bash), different terminal emulators (ghostty and gnome terminal) and as a standalone docker container. But different formats (markdown and text) are working well

Edit: lnav works well when running it on my host machine with the same log file (installed it from nixpkgs using home-manager)

[OJarrisonn]

Fix

Just change the TERM environment variable to xterm-256color (if your terminal emulator do support this standard)

[ba-didi]

I experianced somthing similar in docker.
In my case, it just showed a black screen. When i pushed one of the arrows buttons - lnav crashed.
Changing TERM to xterm-256color helped le as well
but i prefer this issue to be repoened as changing the TERM enviroment variable is not fixing the actual problem and you still had to search in the github issues this "hack".
If lnav can 't support xterm, It should at least print a message and exit gracefully.

[OJarrisonn]

Indeed lnav should do something about it. At least documenting this hack somewhere

[tstack]

If there is a log file generated when it crashes, can you attach it please? Could I also bother you to try one of the nightly builds and see if the problem persists

[ba-didi]

I'm currently from my phone so I'l do it tomorrow.
About the nightly builds - where i can find it?
Note that in my case, it built from cloned source about 2 weeks ago

[tstack]

About the nightly builds - where i can find it?

There's a beta release here:

https://github.com/tstack/lnav/releases/tag/v0.12.4-beta2

The "bins" action that runs on a commit will have binaries attached:

https://github.com/tstack/lnav/actions/workflows/bins.yml

[ba-didi]

I did some more experiments with the "bins" executable and seems this is a sporadic problem. sometimes i managed to open lnav correctly (when "TERM=xterm" - with visualization problems), sometimes it crashed immediatly (with the crash message) and sometimes it showed a black console where pushing the latters buttons did nothing but the arrow buttons make it crash completly (with the crash message).

The crashing problem could reproduced with:

• the docker default "TERM=xterm"
• in docker after i changed "TERM=xterm-256color"
• directly on the system (WSL ubuntu) with the default "TERM=xterm-256color"

so it seems it is not an issue of neither docker nor TERM

With the version i'm using from "snap" (lnav 0.11.2), i don't have such problems

Attached the crash logs for each type of crash (from the docker trial):

crash-2025-02-04-09-45-43.756.log
crash-2025-02-04-09-41-05.73.log

How to reproduce:

1. download the musl zip from the "bins" action.
2. unzip it to "directory"
3. put a log file in the folder "file.log"
4. execute the following with the right path to the "diretory" docker run -it --rm -v ./directory:/test --workdir /test ubuntu
5. execute lnav-0.12.4-beta2/lnav file.log
6. repeat the last step many time as needed (few in my case)

[tstack]

@ba-didi what terminal are you using?

In the beta build, the ncurses library was swapped out for a newer library called notcurses. I thought I had fixed these startup issues, but I guess not. Thanks for being a guinea pig

[tstack]

I thought I had fixed these startup issues, but I guess not

Er, I applied a fix after the beta2 build. The following run of the "bins" action contains that change:

https://github.com/tstack/lnav/actions/runs/13107982834

The assert() in the crash logs is one I experienced when using WSL with the Windows Terminal. Hopefully, that fix will work for you as well. Thanks!

[ba-didi]

I'm using WSL with windows Terminal too and seems that the crashing problem is not occuring with this commit! Thanks!

There is still the issue with with executing in docker. the default $TERM when i executed the docker was xterm and the visualization was wierd.
The line at the top saying "The following is a rendered view of the content. Use :set-text-view-mode..." appears in white background and i couldn't see the letters.
When i passed through the logs using the arrows, the colors of the logs words changes and kept changed even after i passed them.

when i run the docker with --env TERM="xterm-256color", it seems to work just fine (same visualization as WSL)

Attached examples for:

• xterm at startup:

• xterm after passing through the logs using the up-down arrows (Note the missing "PATH" and the different colors for the PATHs):

• xterm-256color:

[tstack]

When i passed through the logs using the arrows, the colors of the logs words changes and kept changed even after i passed them.

I think I've fixed this issue with change e28fd9d

Thanks!