Jouno - a different way of tracking system activity.

English Applications
1

I’ve written a tool to filter and bundle journal entries for forwarding via DBUS to raise desktop notifications. I use it in two ways:

  1. I have various timer jobs that I like to say aware of. For example, my desktop backup timer-jobs.
  2. I want to be more aware of things that are happening in my desktop system. For example, a little while ago an application’s background task was constantly dumping core due to a library mismatch, the only outward sign was my desktop bogged down.

In the past I’ve used email to keep me informed about my own timer jobs, but that was always too reliant on my taking the time to read the emails. Last year I wrote notify-desktop script that allows root jobs to raise DBUS notifications for the currently desktop user:

https://gist.github.com/digitaltrails/26aad3282d8739db1de8bc2e59c812eb

My notify-desktop script is OK for jobs I’ve written, but not helpful for anything else, such as the offending application mentioned above.

Recently it occured to me that I could filter the journal and forward notifications to the desktop via DBUS. So I wrote a python Qt application, here’s a screenshot:

https://raw.githubusercontent.com/digitaltrails/jouno/master/screen-shots/Screenshot_Small.png

I’ve pretty much added all the features I need. Jouno is not a historical-view backward-searching tool, it’s more a tool for staying aware of what’s going on right now or staying current with recent events. It can optionally be used more like GUIfied journalctl -f, notifications can be turned off, and it does feature incremental and regular-expression search. It could be used quite narrowly by filtering down to the exact task or more widely by leaving the filtering open and just filtering to ignore the noise (most of the KDE logging is annoying noise).

If it’s something that might be of interest, there is a full rundown of features at github:

https://github.com/digitaltrails/jouno

The application is a single python script, so there’s not much to install, but as detailed on github I have also used the OpenSUSE build service to make community RPM’s:

https://software.opensuse.org/package/jouno?search_term=jounohttps://software.opensuse.org/package/jouno?search_term=jouno

But it’s just as easy to grab the script and run it (providing a user already has journal access, no additional permissions are required).

Cheers,
Michael

2

That is awesome. Thanks for sharing. :slight_smile:

3

:good:

Thanks, it’s great to get some feedback, much appreciated.

4

I’ve released a collection of minor fixes and enhancements:

v1.0.5:

  • Escape any HTML in journal messages before forwarding them to Desktop-Notifications. Desktop-notifications allow limited HTML for markup (bold/italics). Angle brackets in journal-entries can cause the notifications system to try an interpret/validate forwarded entries as HTML, leading to extra notifications if the HTML appears to be invalid.
  • A better tooltip for notifications_seconds.
  • Fix detection of whether the configuration has actually changed for Apply/Save, plus better messaging on Apply/Save.
  • Mention KDE Connect as a way of further forwarding desktop-notifications to phones.

Both github and the RPM’s have been updated. If I make any further releases, I’ll most likely just append further messages here.

As noted, I added a mention of KDE Connect. Adding KDE Connect into the mix takes the concept of journal-entry forwarding to the next step: forwarding from the desktop to the phone.

The only potential enhancements I’m considering relate to the desktop notification spec. The spec allows three urgency levels and also allows sounds. I’m not sure if any desktop actually supports those options, I can’t seem to get any “standard” sounds to work with the notifications system, I don’t know if the sound naming spec is commonly used.

Cheers,
Michael

5

I’ve recently used some of the code from jouno to create procno, an application that can raise notifications when any process excessively consumes CPU or memory. Similar to journo, it monitors the system, this time /proc, and raises DBUS/FreeDesktop notifications if a process crosses configurable thresholds, hence procno (proc notifications).

I wrote procno because google chrome sometimes chews CPU endlessly for no reason. I often don’t notice until it occurs to me that my PC fans are noisier than usual (perhaps hours later). Whatever the cause, closing tabs does not resolve the issue, only restarting the browser returns things to normal. So I got annoyed and decided that I would like an alert raised whenever any process burns a CPU for more than a few minutes.

I added memory consumption as another kind of alert because that’s also sometimes an issue. Procno is not much help for super rapid consumers of RAM, such as stress-ng --brk 1, where one might only have thirty seconds or so to take action, but it can help notify of slower consumers.

Screenshot follows:

https://github.com/digitaltrails/procno/raw/master/screen-shots/Screenshot_Large.png

What’s with all the dots? As well as generating notifications, I’ve experimented with an overview of process activity. Each dot represents a process, the dots are colored for each user. Particularly hot processes turn a shade of pink-red. Slight active processes blink in darker-blue. Dotted circles represent Resident Set Size.

The display is optional, you can leave procno minimised in the system tray, it will still raise notifications, but the display will suspend drawing. I tried to maintain a reasonable low level of CPU consumption, the drawing code is quite basic (but it is python-Qt). There’s a video of the blinking lights embedded in the github README.md:

https://github.com/digitaltrails/procno

There are other options to show Unique Set Size and Shared Size. USS seems to be very expensive (CPU-wise) to collect, and cannot be examined for other user’s processes, so I cannot recommend that option. On my desktop, the RSS and USS are almost the same for top five memory hogs, so USS is not worth the expense of gathering it.

Read/write activity can optionally be reported by mini blinking dots (not indication of magnitude). Perhaps excessive I/O notification could be a future feature. Unfortunately read/write counts are only available for one’s own processes.

I’ve attempted to minimise repeat DBUS desktop notifications for the same incident. Existing notifications are updated rather than repeated. If a notification is dismissed, procno will raise no further notifications for the continuing incident. For example, if a process consumes more than the set CPU amount for the set time, a notification will be raised; as long as it’s not dismissed the desktop notification will continue to be updated with CPU consumption figures; if notification is dismissed, no further notifications will be issued while the process remains above the thresholds; falling below the thresholds resets/closes the incident.

In addition to the github link above, I’ve also built OpenSUSE community packages for Tumbleweed, Leap 15.3, and Fedora:

https://software.opensuse.org/package/procno?search_term=procno

The colors are mostly configurable, if you don’t have time to decorate a tree this Xmas, you could just customise procno.

(I’ll continue to update this thread should I make any further changes to either jouno or proco.)

6

Added a capability to showing past messages. Limited by Options-tab settings: journal_history_max and from_boot_enabled:

  • journal_history_max
    by itself could be used to start journo from an arbitrary number of entries into the past (including prior to the current boot). - from_boot_enabled
    will begin the display of past entries from the last boot time, but these may be pruned by journal_history_max.

[FONT=arial]This feature is only intended for looking back a reasonable number of entries, perhaps a days worth or so on a desktop.

[/FONT]Note that journal_history_max defaults to 500, which is probably too small if you’re going to use from_boot_enabled.[FONT=arial]

There is no constraint on RAM usage, so it would be bad to set from_boot_enabled=yes for a machine that has been up 400 days. In such cases set from_boot_enabled to no and rely on a sensible number for journal_history_max. That said, the memory footprint is not particularly large by modern standards, much smaller than plasmashell, kwin_x11 or chrome, but this also depends on what’s in the journal.

Tumbleweed, Leap 15.3, Fedora 34 community RPM’s: https://software.opensuse.org/package/jouno?search_term=jouno
Github: https://github.com/digitaltrails/jouno

[/FONT]

7

Added a capability to show past messages. This is limited by the Options-tab settings journal_history_max and from_boot_enabled:

  • journal_history_max
    by itself could be used to start journo from an arbitrary number of entries into the past (including prior to the current boot). - from_boot_enabled
    will begin the display of past entries from the last boot time, but these may be pruned by journal_history_max.

[FONT=arial]This feature is only intended for looking back a reasonable number of entries, perhaps a days worth or so on a desktop.

[/FONT]Note that journal_history_max defaults to 500, which is probably too small if you’re going to use from_boot_enabled.[FONT=arial]

There is no constraint on RAM usage, so it would be bad to set from_boot_enabled=yes for a machine that has been up 400 days. In such cases set from_boot_enabled to no and rely on a sensible number for journal_history_max. That said, the memory footprint is not particularly large by modern standards, much smaller than plasmashell, kwin_x11 or chrome, but this also depends on what’s in the journal.

Tumbleweed, Leap 15.3, Fedora 34 community RPM’s: https://software.opensuse.org/package/jouno?search_term=jouno
Github: https://github.com/digitaltrails/jouno[/FONT]

8

Jouno 1.2.0 introduces a Journal-Query interface designed for exploring past journal entries. The new query interface is primarily focused on looking back at past boots via a calendar timeline.

These new additions are quite functional, but they remain a work in progress and will change as further features and refinements are added. I’m happy to consider suggestions for additional features.

A screenshot of the Journal-Query interface:

https://raw.githubusercontent.com/digitaltrails/jouno/master/screen-shots/query_interface-small.png

The year-calendar includes indicators for boots (green dots), shutdowns (grey-dots), and shutdowns with incomplete journals (red-dots). There’s a boot-count on days when there was more than one boot. Clicking on a day in the calendar toggles that’s days boots for retrieval, the selection can be further refined by checking/unchecking additional boots in the table below, or by using the tabs to add more criteria.

In the above example, the desktop is booted and shutdown every day, there have been uncontrolled shutdowns (with incomplete journals) on 26 November and 4 December. The journal entries for UID 500 for a boot on 4 December has been retrieved.

The search criteria are sd-journal (3) searchable fields. Sd-journal provides for fast value matching, but it’s exact match only. After an sd-journal query, Jouno adds it’s own post-search filter which is applied to the entire text of each journal entry.

The supported journal fields are configurable, but at the moment they must be fields with a reasonably sized small set of fixed values. This is because jouno provides a preview of the possible values. For example, under the _COREDUMP_COMM tab there will a checkbox for every command that has dumped core over the history of the journal. (The sensible choice of fields isn’t currently policed, so don’t add MESSAGE or any date fields to the configured fields or there will be trouble).

The next feature to add would probably be the ability to load or save queries (but I’m not in any hurry at this point).

Links:
https://software.opensuse.org/package/jouno
https://github.com/digitaltrails/jouno

9

Version 1.2.5 released.

The procno individual process-view/control dialogs now lists a rolling display of the open files and connections. Access to this info is restricted, this means files and connections will only be shown for your own processes. Screen shot:

https://raw.githubusercontent.com/digitaltrails/procno/master/screen-shots/Screenshot_proc_fd_small.jpg

Links:
https://software.opensuse.org/package/procno?search_term=procno
https://github.com/digitaltrails/procno

10

Installed package and got some messages:

**erlangen:~ #** zypper install https://download.opensuse.org/repositories/home:/mchnz/openSUSE_Tumbleweed/noarch/jouno-1.3.0-4.1.noarch.rpm 
Loading repository data... 
Reading installed packages... 
Resolving package dependencies... 

The following 2 NEW packages are going to be installed:
  jouno python38-systemd 

2 new packages to install. 
Overall download size: 129.7 KiB. Already cached: 0 B. After the operation, additional 473.5 KiB will be used. 
**Continue? [y/n/v/...? shows all options] (y): **
Retrieving package python38-systemd-234-5.13.x86_64                                                                                                                                                                                        (1/2),  74.6 KiB (276.9 KiB unpacked) 
Retrieving: python38-systemd-234-5.13.x86_64.rpm .........................................................................................................................................................................................................................[done] 
Retrieving package jouno-1.3.0-4.1.noarch                                                                                                                                                                                                  (2/2),  55.1 KiB (196.6 KiB unpacked) 
jouno-1.3.0-4.1.noarch.rpm: 
    Header V3 RSA/SHA256 Signature, key ID f767118e91ea68ad: NOKEY
    V3 RSA/SHA256 Signature, key ID f767118e91ea68ad: NOKEY

warning: /var/tmp/zypp.WMyQtQ/zypper/_tmpRPMcache_/%CLI%/jouno-1.3.0-4.1.noarch.rpm: Header V3 RSA/SHA256 Signature, key ID 91ea68ad: NOKEY 
Looking for gpg key ID 91EA68AD in cache /var/cache/zypp/pubkeys. 
Repository Plain RPM files cache does not define additional 'gpgkey=' URLs. 
jouno-1.3.0-4.1.noarch (Plain RPM files cache): Signature verification failed [4-Signatures public key is not available]
**Abort, retry, ignore? [a/r/i] (a): **i 

Checking for file conflicts: .............................................................................................................................................................................................................................................[done] 
(1/2) Installing: python38-systemd-234-5.13.x86_64 .......................................................................................................................................................................................................................[done] 
(2/2) Installing: jouno-1.3.0-4.1.noarch .................................................................................................................................................................................................................................[done] 
Additional rpm output:
warning: /var/cache/zypper/RPMS/jouno-1.3.0-4.1.noarch.rpm: Header V3 RSA/SHA256 Signature, key ID 91ea68ad: NOKEY


**erlangen:~ #**
11

Thanks for the feedback. I get the same messages. I think it’s because I’ve used the OpenSUSE Build Service to create the packages as a “community” build. Because it’s only a “community” build package, the OBS doesn’t apply any signatures to the RPM’s.

This message doesn’t affect the result of the install, it just means that the installables cannot be authenticated against a signature. The zypper --no-gpg-checks option can be used to suppress the abort/retry/ignore prompt, but not the messages.

 zypper --no-gpg-checks install https://download.opensuse.org/repositories/home:/mchnz/openSUSE_Tumbleweed/noarch/jouno-1.3.0-4.1.noarch.rpm

The executable is just python code, so /usr/bin/jouno can be inspected or compared to the github version.

Perhaps I could generate my own keys and sign the package. But even if I did so, it’s not clear to me how an install would access the public verification key, the person doing the install might have to manually import the key from somewhere.

I did originally intend to submit jouno (and procno, and vdu_controls) for official inclusion in OpenSUSE. In which case I suppose it would be signed with the official repo keys. But it seems to me that making a submission is not straight forward, if I understand the process correctly I have to find some existing “official” contributor to support my application.

12

Subsequent to releasing jouno 1.2.0, I have also released v1.3 and today v1.3.1:

v1.3.0 added the following capabilities:

  • Added an option to forward the xorg-session.log or wayland-session.log to the journal (with elapsed-time heuristics to group multiple lines of logging into one journal entry). Session log files are looked for in $HOME/.local/share/sddm and $HOME/.local/share/gdm and /var/log/gdm (this needs to be made configurable). At the moment the heuristic for picking which session log is current is based on the most recent modified time.
  • Following normal UI conventions by added a settings item to the toolbar, hamburger menu, and tray context-menu.
  • Some Wayland compatibility tweaks.

v1.3.1 adds the following capabilities:

  • Handle DBUS notification errors in case DBUS is unavailable (improves the experience on non-DBUS desktops by allowing jouno to start without having to change the config to disable notifications).
  • On a new message, only maintain position at the end of the message list if the current position is already at the end of the list. This change prevents the UI from countermanding the user’s scrolling when new messages arrive. From now on if you have manually scrolled or searched and want to revert to auto-scrolling as messages are appended, manually scroll back to the bottom of the list.
  • More Wayland prep (it’s perfectly functional on wayland, but it still makes some Qt calls that result in journald warnings on Wayland).

Links:
https://software.opensuse.org/package/jouno?search_term=jouno
https://github.com/digitaltrails/jouno

13

These look slick!Thank you!

14

v1.3.2 some small additions and fixes:

  • Automatically allocate names to rules based on the currently selected journal entry’s message.
  • HiDPI icons enabled for desktops scaled greater than 100%.
  • Wayland Plasma system tray fix. If the system tray is not available at login, wait for a while and see if it becomes available.
  • Query no longer crashes when gathering info on truncated log files.

Links:
https://software.opensuse.org/package/jouno
https://github.com/digitaltrails/jouno