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.
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.