I’ve made a journalctl-mode package for viewing and monitoring typical Linux Journald service logs to get a richer experience than basic journalctl execution in async shell buffers.

It’s in a bare-bones state, but I’ve been finding it very useful for almost a year now. I keep wanting to fix/enhance a few more things before I publicise, but … I think others could find it as useful as I do already. It’s not yet published on ELPA etc., but I intend to soon.

The stand out features are:

  • Multiple simultaneous journalctl processes may run simultaneously with the output interleaved. E.g.:
    • simultaneously view a broad query, say at ‘–priority warning’ along with a more narrowly focused ‘–priority debug’ query.
    • Dig into the output within or near a region by requesting additional log records. To facilitate this, if the region is active when you add an additional command, the kill ring is augmented with a --since=... --until=... string generated from the region’s timestamps.
  • The complete JSON log record is processed facilitating richer features
  • The full JSON record for a given log line under point may be summoned and examined
  • Where the record includes file name and line number, you can jump from a message record line to the generating source file/line

Further details and key bindings are included in the Commentary section of journalctl-mode.el and docstrings of the entry functions.

Its usage is somewhat rudimentary, with minimal UI and no cool command-construction GUI like magit or anything, though with bash-completion set up that’s not a big hardship. It also currently is not flexible in output format, but that may come!

If you habitually monitor journald please let me know what you think and give it a try, and let me know what you think should be fixed or enhanced most urgently in the GitHub Issues.

There exists another journalctl-mode package that looks nearly abandoned and more quick-and-dirty, but does look to be aimed at other usage patterns. So I’m creating a naming clash here and possibly a downgrade for some use-cases(?) - let me know what you think about that in the comments.

  • 7890yuiop@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    You have a couple of commands with double-hyphenated names as if they were internal-use functions, but (being commands) they’re a part of the public-facing interface. I suggest renaming those.