With Nix we have very longs paths like this:

htop normal

htop after pressing the 'p' key

Would something similar be possible with zenith?

What happens

Zenith launches to a blank screen and appears to hang. No information is shown. No response to ^C or ^D.

I tried using --disable-history, but it didn't change anything.

System Info

Version: 0.7.7
Distro: Arch Linux 5.5.13-zen2-1-zen
Terminals: Kitty, Alacritty, Konsole

$ hwinfo --short
cpu:
                       AMD Ryzen 7 1700X Eight-Core Processor, 2770 MHz
graphics card:
                       ATI RX Vega64
storage:
                       Samsung Electronics NVMe SSD Controller SM961/PM961
                       ASRock In Fatal1ty X370 Professional Gaming
                       AMD FCH SATA Controller [AHCI mode]
network:
  enp37s0              Intel I211 Gigabit Network Connection
  wlp36s0              Intel Dual Band Wireless-AC 7265

When using zenith like I use bottom and let it run 24/7, I noticed that every morning the program seems to have aborted (without removing the lock).

That alone I was willing to ignore, but recently zenith didn't seem to startup anymore while using a lot of CPU and disk input.

When looking at the ~/.zenith folder, I saw this:

This looks very familiar to me - it's a sled database. It will take a long time to open big databases, and depending on the way data is accessed, this included quite a sizeable amount of RAM usage.

Starting it with zenith --disable-history resolved the startup problem

Meta

$ zenith --version
zenith 0.7.5

Tested on MacOS 10.15.3

On newer Linux kernels PIDs can have more than five digits:

$ ps ax -o pid | sort -n | tail -n 3
 671590
 671591
 671592
$ uname -sr
Linux 5.5.10-arch1-1

When they do, the PID and USER columns are no longer separated by a space in zenith.

Paths are not shown for processes launched with zero arguments.

My system has an NVMe system disk and a ZFS pool of 3 SSDs that is mounted as /home. Only the partitions from the NVMe drive appear:

┌Disks───────────────────────┐
│9.52%(!): /                 │
│84.71%: /boot               │
│                            │
│                            │
│                            │
│                            │
│                            │
│                            │
└────────────────────────────┘

Other tools detect it, for example ytop:

┌ Disk Usage ────────────────────────────┐
│Partiti Mount   Used  Free     R/s      │
│nvme0n1 /boot    15%  254 MiB  0 bytes  │
│nvme0n1 /        90%  43.3 GiB 2 bytes  │
│zhome   /home    66%  151 GiB  0 bytes  │
│                                        │
│                                        │
│                                        │
│                                        │
│                                        │
│                                        │
│                                        │
└────────────────────────────────────────┘

Sled was originally being used to store the chart data between zenith sessions. However, there were some issues with amount of space the database used. Right now it exists only to migrate existing databases. However, I want to remove it for 0.9.0 release.

htop has a very useful feature: when the process list is ordered by a column, the list is re-sorted at every tick. However, this can make selecting a process surprising, since in the small window between deciding to hit enter and the keypress coming thru, a list reorder may happen, and the process that is actually selected is not the one the user had highlighted with the intent to do so.

What htop does is add a grace period after any selection input in the process list (up/down arrow for zenith). For a period of time after the user has changed selection (a few seconds, but at least one or two ticks in wall-clock time), the values for processes are updated, but the list does not get reshuffled. This ensures that when a user hits enter shortly after selecting a process, the process actually selected is the one they expected.

I've started work on a PoC to add this feature. The actual grace period duration can be debated, but should be at minimum one tick in wall-clock time. I would propose to set it at at least 2 seconds, rounding up to the next interface tick.

When I run zenith on PowerPC64LE-based Linux, I got following error:

From my understanding, the error belongs to heim lib. Because I am not 100% confident, I create this ticket to double-check if it might be zenith's issue or not before lodging a new ticket with heim project.

Many thanks

It would be handy to have a way to view the historical data for free space of the various file systems. One idea is to select a file system from the list and toggle the IO chart to show the historical free/used graph for that file system.

Sections are treated as invisible (described here) instead of non-existent. This leads to strange problems such as TABing between sections can lead you to an invisible section.

In addition, there should be a UI way to hide and restore previously hidden sections.

Luks mounted file systems don't show on the left pane of Zenith's disk metrics section.

Hi!
This is a project that I would like to get behind, however my first stumbling block is the barcharts do not render properly with a console font (font used by a non-windowing environment on a server)

Does this require patched fonts in order to work?

.zenith.lock seems to work well for preventing 2 copies of zenith from clobbering the same copy of history.

However, I frequently spawn zenith from a remote connection, and when that connection is cut off due to unrelated issues, the running zenith is also killed.

This results in having to manually delete .zenith.lock almost on every login to the remote machine.

This does not have to be the case, as the lockfile can be used as a pidfile. That is, it can store identifying information about the running zenith instance, and at startup, zenith can check that indeed the previous instance has been killed without a chance for cleanup, and it can automatically rewrite the lockfile.

This will continue to prevent multiple copies clobbering the history file, while also addressing a common use case for remote work via ssh.

When a user arranges the section sizes to what they want, it would be nice to be able to save this size in a configuration. In addition, perhaps we could add support for customizing the colors of various charts.

zenith seems to use a lot of RAM compared to similar tools:

zenith -d0 -n0 is using 127.35Mb compared to 5.82Mb for ytop and 4Mb for top

It seems to be related to the history feature. If I pass --disable-history it uses ~18Mb.

It would seem that I ned to run clear prior to running Zenith, otherwise the formatting seems to become messed up. This appears to be an issue with it rendering over the text that was there before.

I'm unable to build zenith on Windows 10. Is this supported? I'm seeing these issues.

PS C:\Users\jimi\rust\zenith> cargo build --release
   Compiling socket2 v0.3.12
   Compiling ntapi v0.3.4
   Compiling atty v0.2.14
   Compiling time v0.1.43
   Compiling termion v1.5.5
error[E0433]: failed to resolve: maybe a missing crate `sys`?
  --> C:\Users\jimi\.cargo\registry\src\github.com-1ecc6299db9ec823\termion-1.5.5\src\lib.rs:24:9
   |
24 | pub use sys::size::terminal_size;
   |         ^^^ maybe a missing crate `sys`?

error[E0433]: failed to resolve: maybe a missing crate `sys`?
  --> C:\Users\jimi\.cargo\registry\src\github.com-1ecc6299db9ec823\termion-1.5.5\src\lib.rs:27:9
   |
27 | pub use sys::tty::{is_tty, get_tty};
   |         ^^^ maybe a missing crate `sys`?

error[E0433]: failed to resolve: maybe a missing crate `sys`?
 --> C:\Users\jimi\.cargo\registry\src\github.com-1ecc6299db9ec823\termion-1.5.5\src\async.rs:5:5
  |
5 | use sys::tty::get_tty;
  |     ^^^ maybe a missing crate `sys`?

error[E0433]: failed to resolve: maybe a missing crate `sys`?
  --> C:\Users\jimi\.cargo\registry\src\github.com-1ecc6299db9ec823\termion-1.5.5\src\raw.rs:29:5
   |
29 | use sys::attr::{get_terminal_attr, raw_terminal_attr, set_terminal_attr};
   |     ^^^ maybe a missing crate `sys`?

error[E0432]: unresolved import `sys`
  --> C:\Users\jimi\.cargo\registry\src\github.com-1ecc6299db9ec823\termion-1.5.5\src\raw.rs:28:5
   |
28 | use sys::Termios;
   |     ^^^ maybe a missing crate `sys`?

error[E0425]: cannot find function `get_tty` in this scope
  --> C:\Users\jimi\.cargo\registry\src\github.com-1ecc6299db9ec823\termion-1.5.5\src\async.rs:14:36
   |
14 |     thread::spawn(move || for i in get_tty().unwrap().bytes() {
   |                                    ^^^^^^^ not found in this scope

error[E0425]: cannot find function `get_tty` in this scope
  --> C:\Users\jimi\.cargo\registry\src\github.com-1ecc6299db9ec823\termion-1.5.5\src\async.rs:43:36
   |
43 |     thread::spawn(move || for i in get_tty().unwrap().bytes() {
   |                                    ^^^^^^^ not found in this scope

error[E0425]: cannot find function `set_terminal_attr` in this scope
  --> C:\Users\jimi\.cargo\registry\src\github.com-1ecc6299db9ec823\termion-1.5.5\src\raw.rs:45:9
   |
45 |         set_terminal_attr(&self.prev_ios).unwrap();
   |         ^^^^^^^^^^^^^^^^^ not found in this scope

error[E0425]: cannot find function `get_terminal_attr` in this scope
  --> C:\Users\jimi\.cargo\registry\src\github.com-1ecc6299db9ec823\termion-1.5.5\src\raw.rs:90:23
   |
90 |         let mut ios = get_terminal_attr()?;
   |                       ^^^^^^^^^^^^^^^^^ not found in this scope

error[E0425]: cannot find function `raw_terminal_attr` in this scope
  --> C:\Users\jimi\.cargo\registry\src\github.com-1ecc6299db9ec823\termion-1.5.5\src\raw.rs:93:9
   |
93 |         raw_terminal_attr(&mut ios);
   |         ^^^^^^^^^^^^^^^^^ not found in this scope

error[E0425]: cannot find function `set_terminal_attr` in this scope
  --> C:\Users\jimi\.cargo\registry\src\github.com-1ecc6299db9ec823\termion-1.5.5\src\raw.rs:95:9
   |
95 |         set_terminal_attr(&ios)?;
   |         ^^^^^^^^^^^^^^^^^ not found in this scope

error[E0425]: cannot find function `set_terminal_attr` in this scope
   --> C:\Users\jimi\.cargo\registry\src\github.com-1ecc6299db9ec823\termion-1.5.5\src\raw.rs:107:9
    |
107 |         set_terminal_attr(&self.prev_ios)?;
    |         ^^^^^^^^^^^^^^^^^ not found in this scope

error[E0425]: cannot find function `get_terminal_attr` in this scope
   --> C:\Users\jimi\.cargo\registry\src\github.com-1ecc6299db9ec823\termion-1.5.5\src\raw.rs:113:23
    |
113 |         let mut ios = get_terminal_attr()?;
    |                       ^^^^^^^^^^^^^^^^^ not found in this scope

error[E0425]: cannot find function `raw_terminal_attr` in this scope
   --> C:\Users\jimi\.cargo\registry\src\github.com-1ecc6299db9ec823\termion-1.5.5\src\raw.rs:114:9
    |
114 |         raw_terminal_attr(&mut ios);
    |         ^^^^^^^^^^^^^^^^^ not found in this scope

error[E0425]: cannot find function `set_terminal_attr` in this scope
   --> C:\Users\jimi\.cargo\registry\src\github.com-1ecc6299db9ec823\termion-1.5.5\src\raw.rs:115:9
    |
115 |         set_terminal_attr(&ios)?;
    |         ^^^^^^^^^^^^^^^^^ not found in this scope

error: aborting due to 15 previous errors

Some errors have detailed explanations: E0425, E0432, E0433.
For more information about an error, try `rustc --explain E0425`.
error: could not compile `termion`.

To learn more, run the command again with --verbose.
warning: build failed, waiting for other jobs to finish...
error: build failed

The README notes, "Other BSD systems may work, I have not tested". I tried building on FreeBSD 12.1 and it failed as follows.

error: failed to run custom build command for `sys-info v0.5.10`

Caused by:
  process didn't exit successfully: `/usr/home/wmoore/zenith/target/debug/build/sys-info-19beb9d719b282f9/build-script-build` (exit code: 101)
--- stderr
thread 'main' panicked at 'unsupported system: freebsd', /home/wmoore/.cargo/registry/src/github.com-1ecc6299db9ec823/sys-info-0.5.10/build.rs:17:14
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

OS Info

uname -a
Linux pve1 5.4.44-2-pve #1 SMP PVE 5.4.44-2 (Wed, 01 Jul 2020 16:37:57 +0200) x86_64 GNU/Linux

cat debian_version
10.5

I installed zenith via:

curl -s https://api.github.com/repos/bvaisvil/zenith/releases/latest | grep browser_download_url | grep linux | cut -d '"' -f 4 | wget -qi -
tar xvf zenith.x86_64-unknown-linux-musl.tgz
chmod +x zenith
sudo mv zenith /usr/local/bin

When I try to start zenith it panics with

thread '<unnamed>' panicked at 'Couldn't Create DB dir.: Os { code: 2, kind: NotFound, message: "No such file or directory" }', src/main.rs:115:17

I lost the error message but zenith didn't build for aarch64 while packaging it for NixOS.

Hi @bvaisvil,

I've tried zenith 0.10.0 on the ARMv7 Linux board.
It is custom yocto-based Linux build:

# uname -a
Linux msm8909 3.18.71 #1 SMP PREEMPT Wed Aug 12 17:26:02 UTC 2020 armv7l armv7l armv7l GNU/Linux

I've cross-compiled zenith on Ubuntu 18.04 for the armv7-unknown-linux-gnueabihf target.
I always get crush at the startup.

# RUST_LOG=debug zenith --db=/tmp/zenith
[DEBUG zenith::render] Setup Constraints
[DEBUG zenith::render] Create Metrics App
[DEBUG zenith::metrics] Create Histogram Map
[DEBUG zenith::histogram] Opening DB
[DEBUG zenith::histogram] Starting a new database.

thread 'main' has overflowed its stack
fatal runtime error: stack overflow
Aborted (core dumped)

Db path need to be changed because home folder is read-only.

It would be useful to see which worker processes belong to which parent ones for instance.
As a related idea, maybe there could be an option for displaying the parent's PID for each process.

I propose that the tree view be a togglable alternative to the current list view, independently of filter.

That is, the user could press, for example t to switch between tree and list view, and even enable filtering while the tree view is still in effect. Similarly, it should be possible to switch between list and tree after the user is done entering the filter text.

If the machine zenith is running on has a battery, show additional information that is most vital to the users of portable computers, namely:

1. charge status in percent
2. time till full or empty, depending on whether the machine is connected to power
3. current amount of power consumption watts

Right now I have to use battop for this usecase, which comes with a 'big' TUI with a lot of additional information that is not that useful in practice. It's more of a demo for the underlying library displaying all the information there is about batteries.

Here is the information I usually look at in battop:

Technical Notes

• it looks like on MacOS at least, the OS only provides new battery information every half a minute or so. I usually launch battop with -d 10, to refresh only every 10 seconds.
• related to the same request in bottom

Frequently, after using zenith for more than 24-28h memory usage follows a steady trend, reaching over 200MiB (used, not virtual) memory, as reported by zenith itself. This is not a sudden recent behavior, it has been there for at least one release.

Even when loading history, zenith starts at a much more reasonable ~18MiB.

Here are 2 memory profiles, that have run for over 24h. They were taken using valgrind's massif, with zenith built locally at d66adc5

For viewing, massif-visualizer is a pretty good tool to explore the profiles.

If you leave zenith running long enough, files in ~/zenith/blobs will continue to multiply until basically you run out of space on the partition (150 gig in this case)

This was with zenith 0.7.5 on ubuntu server.

I am presuming from other issues that this can be worked around with --disable-history.

Reported virtual memory usage seems extremely high in zenith and is different from what normal top reports.
This with zenith compiled from souce on Fedora 31

Hi,
I am trying to build zenith-0.9.0 using copr (https://copr.fedorainfracloud.org/coprs/yellowhat/HPC/build/1401683/) but I get the following error:

   Compiling heim-cpu v0.1.0-alpha.1 (https://github.com/heim-rs/heim#2629efda)
error: expected `,`
   --> /builddir/.cargo/git/checkouts/heim-d134154c5d7f3f0c/2629efd/heim-cpu/src/sys/linux/freq.rs:135:37
    |
135 |     let frequencies = rt::try_join!(current_freq(&root), max_freq(&root), min_freq(&root));
    |                                     ^^^^^^^^^^^^
    |
    = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

error: aborting due to previous error

error: could not compile `heim-cpu`.

Any ideas?

Thanks

Either I'm using zenith wrong, or you are misusing the term histogram. I can get it to display time series bar charts, but I can't find a single histogram.

https://en.wikipedia.org/wiki/Histogram

Histograms are typically bar charts, but not every bar chart is a histogram.

Need alternative for getting the user of a process, since rust-users supports only unix systems (issue #45)

I don't know how to reproduce it, but it looks like the maximum 64 bit value to me.

To me this absolutely non-critical, but maybe it's something that's easy to fix.

Meta

• zenith 0.9.2
• MacOS 10.15.5

I'm getting this error when I try to start Zenith 0.7.4:

❯ zenith
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 20, kind: Other, message: "Not a directory" }', src/libcore/result.rs:1188:5

BTW you may want to start compiling with the latest release of Rust, which will include better source locations for errors thrown by unwrap().

The network and disk speeds shown are scaled by the refresh rate (i.e. 2X for the default of 2000ms). This can be seen easily by starting a large download or disk copy, then starting zenith with refresh rate of 1000, then stopping and restarting with a larger one of say 5000. Both the histogram and the numbers will be seen to be scaled up by 5X.

Briefly looked at the code in CPUTimeApp.update_networks which uses data.get_received() and data.get_transmitted() to update the histogram but these are not rates rather the diff in total bytes since the last call to sysinfo's refresh_all. Similar issue must exist in disk rate updates.

Have not looked at the code very closely but from my quick reading so far, one clean solution to this might be to take care of this in HistogramMap which needs to take note of the metrics passed as rate per sec, and those that are raw values since the last update and need to be converted to rate. This looks a better approach since the histogram abstraction should understand the difference between the two kinds of values and may have its own policies (e.g. simple average for the duration or more elaborate ones in future). Alternatively it can always assume the passed value is rate per sec (like currently) and the callers need to take care of conversions.

I noticed after selecting a process with Enter/Return to view its infos, if I go back to the process list with Esc/b the first process in the list is highlighted instead of the one selected .

This is pretty inconvenient in the case I want to check the information for a list of processes. Thus I suggest to highlight the original selected process.

Anytime I restart zenith I get an error advising me that the dot zenith dot lock file is still active even though I quit zenith or closed window.

And this happens even after reboot. It's not a huge problem rm .zenith.lock But it is a major annoyance and inconvenience.

Thanks. Really like this program.

This is really slick! I spend way too much of my time administering and monitoring machines. I like the UX of this, it gives me the numbers I care about in an intuitive way.

I would like to be able just cargo install zenith on machines.

This means you'll need to work something out with the owner of https://crates.io/crates/zenith or rename this.

20% CPU usage at 800MHz is obviously a somewhat different workload to 20% CPU usage at 4300MHz. It would be nice if the CPU utilisation was scaled so that 20% CPU meant the CPU was working at 20% capacity¹, rather than 20% of whatever the current frequency is.

The existence of boost clocks would mean that this could give numbers in excess of 100%, but that's probably ok?

¹: A really accurate measure of capacity is hard to do (and almost certainly processor-specific), but just scaling based on CPU frequency is probably good enough.

I see it's in your plan, please use this issue to track it.

Migrating from Termion to Crossterm will enable Windows Support (Issue #45).

Last one that's needed.
It's advertised in the description, but not implemented yet.

If I try to run two instances of Zenith at once, I get the message:

/home/jbabcock/.cache/zenith/.zenith.lock exists and history recording is on. Is another copy of zenith open? If not remove the path and open zenith again.

It would be nice to have concurrent instances, so that leaving a long-running instance on some other virtual desktop/tab won't interfere with opening it quickly to check something.

As the title states, how can one search for a specific process in the processes pane? Essentially the equivalent of htop search with / + F3.

Or, to rephrase, is it possible to search for a process at all?

Not having a Cargo.lock file prevent us to update the application automatically on NixOS.

Configuration files are expected to be in ~/.config/zenith/ / $XDG_CONFIG_HOME/zenith/ per XDG Base Directory Specification instead of ~/.zenith/

Summary of the spec is on Arch Wiki:
https://wiki.archlinux.org/index.php/XDG_Base_Directory

The full specification is here:
https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

Relevant crate - dirs

Thanks.

thread '<unnamed>' panicked at 'Couldn't open database.: Io(Custom { kind: Other, error: "Os { code: 38, kind: Other, message: \"Function not implemented\" }" })', src/metrics.rs:248:17 thread '<unnamed>' panicked at 'Couldn't open database.: Io(Custom { kind: Other, error: "Os { code: 38, kind: Other, message: \"Function not implemented\" }" })', src/metrics.rs:248:17 thread panicked while panicking. aborting. Illegal instruction (core dumped)

Seems to happen at the right write in the sled db.

I have a 32-core 64-thread processor and the core count is unreadable no matter how I resize the window.

Perhaps at some core count you should do what the windows task manager start doing: Stop displaying individual bars and start having just a number per core with a differently colored background according to load.