Log File Viewer for the Terminal
278 points
13 hours ago
| 22 comments
| lnav.org
| HN
guessmyname
12 hours ago
[-]
Oh yeah! lnav is famous. I remember using it like a decade ago to monitor an array of web servers while at GoDaddy; good ol' times.

First commit is from Sep 13, 2009: https://github.com/tstack/lnav/commit/b4ec432515e95e86ec9d71... . Woah! we’re old.

This is what the UX looked like back in the day: https://github.com/tstack/lnav/commit/bce2caa654160518ec11f6...

reply
packetlost
4 hours ago
[-]
Aside from the bitmap font, this looks pretty much the same as it does now lol

I'll also add I used lnav more recently for viewing logs from many small lab devices centralized via syslog, it was extremely lightweight and effective.

reply
boomskats
11 hours ago
[-]
Wow, the GitHub mobile app doesn't preview PNGs. TIL
reply
stronglikedan
3 hours ago
[-]
I'm not seeing them on Chrome on Windows either, but FF works for me.
reply
ifh-hn
10 hours ago
[-]
GitHub website does on mobile.
reply
port11
5 hours ago
[-]
GitHub mobile requires login, sadly.
reply
mixmastamyk
55 minutes ago
[-]
Kinda neat but I had trouble using it. Not sure what it is doing or what it is even showing me. I'd recommend a more CUA-esque interface like turbo vision, the msedit of old, or micro if it had a menu.

If I have to read the manual, if it isn't blindingly obvious how to use, I'd rather just use journal or tail -f.

Also a nitpick but the colors are quite garish, perhaps 256 colors and muted or monochrome effects if possible. For some reason the colors on the site screenshot are less saturated than the one packaged in my distro, fedora, 0.12.4.

reply
tstack
44 minutes ago
[-]
> Kinda neat but I had trouble using it. Not sure what it is doing or what it is even showing me.

Can you elaborate a little more? lnav behaves like a pager with the conventional hotkeys for basic stuff. I'm not sure what else you are expecting.

> Also a nitpick but the colors are quite garish

I enjoy colors, so there's a lot going on by default. There are several themes builtin. You can configure the "grayscale" theme by running:

    :config /ui/theme grayscale
reply
NoSalt
52 minutes ago
[-]
Just out of curiosity, is there a log file viewer that ISN'T for the terminal?
reply
bdangubic
47 minutes ago
[-]
every editor ever :)
reply
vdm
6 hours ago
[-]
reply
vzaliva
3 hours ago
[-]
So, I started it and was doing something but there is no obvious way to exit. I tried Q,q, Ecc, :q. I tried `man lnav` in separate terminal - but no man page is provided. `ps` shows 3 processes which would not die with SIGTERM, have to `kill -9`. But nice web site :)
reply
tstack
3 hours ago
[-]
Oof, sorry you had such a bad experience.

> but there is no obvious way to exit. I tried Q,q

It's not very responsive during initial indexing, which is something I need to improve. Pressing `q` should work to exit in general, though. Pressing CTRL-C three times in quick succession will force quit it.

It would help to know which version you tried. Things have gotten better over the years.

> I tried `man lnav` in separate terminal - but no man page is provided.

A man page exists, but only contains basic information. The builtin help text is much more extensive and can be viewed by running:

    lnav -H
There is also the documentation website: https://docs.lnav.org/

> `ps` shows 3 processes which would not die with SIGTERM, have to `kill -9`.

Older versions of lnav would use readline for the prompt and had to run it in a separate process because of "reasons". More recent versions have a custom prompt and don't require the extra processes.

reply
tjoff
3 hours ago
[-]
I don't know how you got it but q and Q closes it, and there is a man page on my system at least.
reply
p0w3n3d
13 hours ago
[-]
This is almost the thing I want and need. What I need is some sort of TUI grafana - Json log splitter/organizer/finder
reply
aledevv
9 hours ago
[-]
In my opinion logfile navigator is much better than grafana, I use grafana to view a lot of microservices docker logs, but it's too tedious for me (even if depends on your specific use case).

This one, on the other hand, is cleaner and lets you find what you're looking for quickly. And, last but not least, is much lighter.

reply
makapuf
11 hours ago
[-]
Currently working exactly on that https://gitlab.com/makapuf/treewalker (even if it could always use some love)
reply
dima55
12 hours ago
[-]
I use vnlog and feedgnuplot to massage and plot data on the console all the time. It's even less than a tui, but might be what you want.
reply
dloss
11 hours ago
[-]
If you're fine with CLIs, maybe my Kelora project is worth a look. It's a very flexible log processor with built-in scripting: https://kelora.dev
reply
kiliancs
4 hours ago
[-]
A discussion from 3 years ago. https://news.ycombinator.com/item?id=34243520
reply
elcapitan
10 hours ago
[-]
> ssh playground@demo.lnav.org

Really appreciate this way to demo it quickly, very nice!

reply
rgilton
7 hours ago
[-]
reply
rsafaya
8 hours ago
[-]
I wish I had found this earlier. Nothing like looking at thousands of EV charger logs all day to mak you appreciate something like this.
reply
mitul005
4 hours ago
[-]
Interesting, I want to try this for debugging our AI gateway when you're routing requests across 20+ LLM providers, the logs get noisy fast. Being able to filter by log level, jump between errors, and run SQL-style queries against structured logs in the terminal sounds like a huge time saver. No more grepping through multi-GB log files.
reply
Sammi
9 hours ago
[-]
This looks great.

I've been using klogg and if you're more into GUI's then I think it's the best there is. It opens and searches in log files of many gigabytes with easy. It's a simple and clean multiplatform QT app.

https://github.com/variar/klogg

reply
graemep
9 hours ago
[-]
The problem with GUIs is that AFAIK they need to be installed on the machine the logs you are reading are on so a heavy install on a server.
reply
kevin_thibedeau
4 hours ago
[-]
Qt still runs over X11. You can just have the app and support libs for remote display without a full desktop environment.
reply
asmosoinio
12 hours ago
[-]
Looks very useful, will give it a go.

This resonates with my use of grep+less: https://github.com/tstack/lnav?tab=readme-ov-file#why-not-ju...

reply
brunosutic
11 hours ago
[-]
I tried lnav about 7-8 years ago and as a terminal junkie I really liked the features.

The only breaking thing was a huge (almost bloated) memory consumption. At that time lnav basically just kept everything in memory. Does anyone did that change?

reply
xx_ns
11 hours ago
[-]
According to the linked homepage, the memory usage seems decent (few hundred megs for most use cases when working with a 3.3G logfile). There's a screenshot with various tasks and what the peak memory usage is.

At some point you need to keep quite a large context in memory to have both decent performance and useful features (that aren't unbearably slow to use). lnav seems to land at a reasonable middle ground.

reply
tstack
4 hours ago
[-]
> At that time lnav basically just kept everything in memory.

lnav has never really kept the contents of files in memory. It does build an index of every line in a file. One exception is that it will decompress small gzip files and keep them in memory as a tradeoff from decompressing on the fly.

The memory consumption has never been a problem for me. So, it's not something I've ever focused on.

reply
__bax
10 hours ago
[-]
Must have tool!
reply
SoftTalker
4 hours ago
[-]
I've always just used less(1).
reply
tstack
4 hours ago
[-]
Yep, I would say the stiffest competition for lnav is the old tools[1]. I would just hope folks could have an open mind and give "new" things a chance (although lnav has been on github for 17 years).

[1] - https://lnav.org/2013/09/10/competing-with-tail.html

reply
secureblueprint
2 hours ago
[-]
This is very helpful
reply
steveharing1
11 hours ago
[-]
I was looking for something like this, Appreciate it!
reply
vincentabolarin
9 hours ago
[-]
This looks genuinely useful.
reply
yagelar
9 hours ago
[-]
very nice, definitely will use it
reply
worksonmine
8 hours ago
[-]
It's a nice tool but I really wish the configuration wasn't done in json and loaded from $XDG_CONFIG_HOME.
reply
Duke64
7 hours ago
[-]
I'm a little disappointed that it's not written in Rust.
reply
tstack
4 hours ago
[-]
Speaking as the author, I too wish it was written in Rust. But, I started it in 2007 when I needed to get practice with C++ for work. At this point, there's so much code in lnav, rewriting would be a long process. There are some sub-components[1] that are written in Rust though.

A new project called logana[2] is written in Rust and is headed in a good direction. Use/contribute to that if you're really interested.

[1] - https://github.com/tstack/lnav/tree/master/src/third-party/l...

[2] - https://github.com/pauloremoli/logana/

reply
kermatt
2 hours ago
[-]
How would this improve the functionality of lnav?
reply
emmelaich
6 hours ago
[-]
I sense an opportunity for you.
reply
teh
7 hours ago
[-]
Super useful tool but need to be aware that this is reading potentially untrusted input (e.g. in the case of http request logs) and written in c++, so a possible attack vector. I use lnav where I trust the logs, but do wish a safe implementation existed.
reply
fireflash38
6 hours ago
[-]
Memory safety doesn't mean it's safe. And C++ doesn't mean it's unsafe.

Browsers are in C++, do you not use them? Curl is in C, do you not use it? Kernel is C...

reply
teh
5 hours ago
[-]
Chrome uses sandboxing and a lot of safe tooling (wuffs, rust) for untrusted data.

curl is heavily fuzzed and you still mostly control what you are downloading unless the target is compromised.

With logs the attacker controls what goes into your logs.

And you don't need to really look very hard, there are a fair number of very recent stack and heap overflows: https://github.com/tstack/lnav/issues?q=is%3Aissue%20heap%20...

reply