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 d66adc51291

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

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

zenith is currently failing to build for Homebrew with Rust 1.49 on Apple Silicon: https://github.com/Homebrew/homebrew-core/pull/68089, https://github.com/Homebrew/homebrew-core/pull/68720

It appears this is due to a stale lock file, causing cargo install --locked to pull in dependencies that do not work for zenith on Apple Silicon. Is it possible for the Cargo.lock file to be updated? If this could be done with a new release, that would be especially helpful.

I've already tried to use the updated lock file at https://github.com/bvaisvil/zenith/pull/90, but that, too, still leads to a failed build.

Related: https://github.com/Homebrew/homebrew-core/issues/68301

Initially was playing around with creating a flatpak package but discovered that its sandboxed environment does not allow access to main /proc. The sandbox /proc only lists the flatpak processes, and the filesystems are also virtual ones of the sandbox so dropped the idea. This PR adds deb package creation which will work on a large number of systems. No RPM since I don't use them and it has been a very long time I had last taken a look at RPM spec files. I can also host a PPA on Ubuntu launchpad if required.

• Added debian directory with required build files, as also desktop and icon files to launch it from standard menus. A Makefile at the top encapsulates the various build actions.

• The icon file is a generic one taken from pngkey which is royalty and attribution free. It has been compressed from its initial size.

• Makefile build creates both the normal build and an NVIDIA enabled one. A wrapper shell script then chooses the appropriate binary depending on whether NVIDIA device and library is present.

• Removed build-linux-static.sh which is now covered in "make linux-static". Like above, the new target creates two binaries, and then tarball containing the two with the wrapper script is created by the target (as also the sha256 file).

I'm using the amd64 PPA, and my system shows zenith 0.12.0 is available, but when I try to upgrade, I get this message:

✦ ➜  sudo apt upgrade zenith
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 zenith : Depends: libgcc-s1 (>= 4.2) but it is not installable
E: Broken packages

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.

related: #107

Right now, this only starts without writing to the db.

It adds a warning in the top right on the main screen, and an explanation on the help screen. The wording and formatting of the warnings are subject to bikeshedding :).

I think the original issue could remain open, until a more complete handling for this scenario lands.

To avoid cutting off panels altogether, use percentages for the various panels instead of fixed heights (for all but process panel).

By default the process panel occupies 10% more space than other non-zero ones.

See the comparison in the two attached screenshots for before and after the patch in my default terminal having a size of 140x40.

These screenshots compare maximized terminal windows for before and after where the two are similar.

On a Intel i7-9850H (6 core), zenith is using 1-2% CPU according to itself. On a AMD 3995WX (64 core), it is at a steady 30-35% + has a perceptible lag when starting/stopping. It seems like something scaling badly with the CPU count.

• added "tick" field to CPUTimeApp for the configured refresh rate (note that HistogramMap.tick cannot be used since it may be recovered from previous database having an old tick value)
• likewise added the "tick" field to ZProcess
• use the above to convert the raw value to rate in CPUTimeApp.update_networks and ZProcess get_read_bytes_sec and get_write_bytes_sec

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.

I tried to make a musl build, but get this error:

mkdir -p build/dynamic
rm -f build/dynamic/zenith.nvidia
install -m 755 target/release/zenith build/dynamic/zenith.nvidia
make[1]: Leaving directory '/tmp/zenith'
mkdir -p build/static-bundle
install: cannot stat 'build/static/zenith.base': No such file or directory
make: *** [Makefile:105: linux-static] Error 1

When using ZFS as a file system, the various zvols have a "maximum capacity" of what is free on the root pool. This results in Zenith assuming that over 100% is free when the free capacity exceeds the maximum capacity.

Frequently, when I open a new terminal session to a machine that's already running zenith from somewhere else, it fails to start, and I have to pass --disable-history, which is also a bit long to type.

I suggest we could add some smarter behavior for this situation - if zenith detects another instance running, it should still start, and display metrics. This could either mean it starts independently of the database, and perhaps shows an indicator to this effect in the top right. or automatically start reading history, but not writing it.

For the second case, when the other zenith instance is stopped, the current instance could race with any other instance to take ownership of the history db, and keep recording.

How would you feel about making the keyboard controls more in line with other TUI applications?

/ usually means search/filter, in htop, less, vim, etc. However zenith uses this to reverse the sort order in the process table. I think something like ; (or anything else) would be better for reordering, which frees up / to do the usual free that's already in many muscle memories.

Second, after returning from a per-process view, the filtering mode is not active anymore. So before clearing it, to go back one step further to the unfiltered view, one has to press a key to activate it again. I don't know if this is intended for a usecase, so I would suggest either:

• that filtering stay active if it was active before zooming into a process
• use a sort of background highlight/inverted view to emphasize the input field for filtering when it is actually active

Thoughts?

Hi, I recently discovered your project and found it really cool and well done.

When I've tried the GPU support for Nvidia, it worked perfectly! But when I wanted to see if you had implemented the same for Intel GPU's, I saw nothing in the Graphics Devices part.

It would be nice to implement the support for Intel GPUs along the others that are planned in #27.

For now I'm using intel_gpu_top from the debian/ubuntu package intel-gpu-tools and here is how it looks so far:

I don't know if that's possible in rust, maybe there is no library for that 🤔

BTW, in case you don't find anything useful within the intel-gpu-tools package, you can give a try to the package/command clinfo:

$ clinfo
Number of platforms                               1
  Platform Name                                   Intel Gen OCL Driver
  Platform Vendor                                 Intel
  Platform Version                                OpenCL 2.0 beignet 1.3
  Platform Profile                                FULL_PROFILE
  Platform Extensions                             cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_3d_image_writes cl_khr_image2d_from_buffer cl_khr_depth_images cl_khr_spir cl_khr_icd cl_intel_accelerator cl_intel_subgroups cl_intel_subgroups_short cl_khr_gl_sharing
  Platform Extensions function suffix             Intel

  Platform Name                                   Intel Gen OCL Driver
Number of devices                                 1
  Device Name                                     Intel(R) HD Graphics Kabylake ULT GT3
  Device Vendor                                   Intel
  Device Vendor ID                                0x8086
  Device Version                                  OpenCL 2.0 beignet 1.3
  Driver Version                                  1.3
  Device OpenCL C Version                         OpenCL C 2.0 beignet 1.3
  Device Type                                     GPU
  Device Profile                                  FULL_PROFILE
  Device Available                                Yes
  Compiler Available                              Yes
  Linker Available                                Yes
  Max compute units                               48
  Max clock frequency                             1000MHz
  Device Partition                                (core)
    Max number of sub-devices                     1
    Supported partition types                     None, None, None

I don't know how to code in rust yet but let me know if I can help for testing things. 😉