Comments URL: https://news.ycombinator.com/item?id=44002417

Points: 2

# Comments: 0

Cheers.

Thanks for trying it out, and for all the suggestions, very helpful!

Fyi, support for journalctl was added to master, in case you wanted to try it out. I didn't yet add automated tests with the mocked journalctl, but my manual tests show that it's working fine.

If a system doesn't have either `/var/log/messages` or `/var/log/syslog`, nerdlog will now resort to `journalctl` by default.

It can also be selected explicitly by specifying `journalctl` as the file, e.g. `myserver.com:22:journalctl`.

Regardless, journalctl support is the single most requested feature, so yeah I'll at least try to make that happen; hopefully on the upcoming weekend if I'm lucky.

I seriously hope I won't have to deal with it, but thanks for expanding on it and the treatment.

Wish you a speedy recovery!

Good luck with whatever you're going through!

Just posting it in case you want to subscribe to it. Looks like it's a popular demand indeed, so I'll at least poke it and see what kind of performance we can get out of it.

Not sure if that "Thanks" for releasing early is sarcastic, but regardless, I appreciate the feedback.

2025-04-21 12:34:56 myhostname myservice: Something happened

If so, then yeah it's totally doable to make this format supported.

Re: config.yaml, yeah I thought of that, but in the long term I rather wanted it to be nerdlogrc.lua, so a Lua script which nerdlog executes on startup. Similar to vim (or rather, more like neovim in this case since it's Lua). Certainly having config.yaml is easier to implement, but in the longer term it may make things more confusing if we also introduce the Lua scripting.

That's not hard to implement, however to make it persistent requires implementing some config / scriptability, which is a whole other thing and requires more thought.

Re: runit, I never tested it, but after looking around briefly, it sounds like there is no unified log file, and not even unified log format? I mean it's possible to make it work, treating every log file as a separate logstream, but I've no idea what these logs look like and whether supporting the formats would be easy.

However, before we go there, I want to double check that we're on the same page: this `log_files` field specifies only files _in the same logstream_; meaning, these files need to have consecutive logs. So for example, it can be ["/var/log/syslog", "/var/log/syslog.1"], or it can be ["/var/log/auth.log", "/var/log/auth.log.1"], but it can NOT be something like ["/var/log/syslog", "/var/log/auth.log"].

But yes the bypass for localhost can definitely be implemented.

The `go get` one should be easy to solve though, and my bad for not thinking of it before, thanks. I'll look into it.

Yeah it would be great, and I do want to support it, especially if the demand is popular. In fact, even if you ungzip them manually, as of today nerdlog doesn't support more than 2 files in a logstream, which needs to be fixed first.

Specifically about supporting gzipped logs though, the UX I'm thinking about is like this: if the requested time range goes beyond the earliest available ungzipped file, then warn the user that we'll have to ungzip the next file (that warning can be turned off in options though, but by default I don't want to just ungzip it silently, because it can consume a signficant amount of disk space). So if the user agrees, nerdlog ungzips it and places somewhere under tmp. It'll never delete it manually though, relying on the regular OS means of cleaning up /tmp, and will keep using it as long as it's available.

Does it make sense?