aristocratos / btop Goto Github PK
View Code? Open in Web Editor NEWA monitor of resources
License: Apache License 2.0
A monitor of resources
License: Apache License 2.0
Amazing work, very nice system monitor!
I would love to see btop being distributed as a package on the Arch User Repository (AUR). Writing the PKGBUILD should be quite straight forward. The setuid
step of the installation could be a question to ask during that install.
I might even go ahead and submit a PR for this if I find some time to check out how the best practices for C++ apps are.
Describe the bug
When a process uses over 999% with proc per core = true (more than 10 cores), btop prints the usage on 3 digits and truncate last numbers.
To Reproduce
nproc
runExpected behavior
btop prints cpu usage on more than 3 digits (e.g. 1400%)
Screenshots
Info (please complete the following information):
Describe the bug
[A clear and concise description of what the bug is.]
To Reproduce
randomly scroll process list.
Expected behavior
[A clear and concise description of what you expected to happen.]
Screenshots
[If applicable, add screenshots to help explain your problem.]
Info (please complete the following information):
Additional context
contents of ~/.config/btop/btop.log
(try running btop with --debug
flag if error.log is empty)
GDB Backtrace
Thread 2 (LWP 2749 "btop"):
#0 0x00007f2bc7bd0a9d in syscall () from /usr/lib/libc.so.6
#1 0x0000563a794fda5e in void std::__detail::__platform_wait(int const*, int) ()
#2 0x0000563a795516c7 in Runner::_runner(void*) ()
#3 0x00007f2bc7cad299 in start_thread () from /usr/lib/libpthread.so.0
#4 0x00007f2bc7bd6053 in clone () from /usr/lib/libc.so.6
Thread 1 (LWP 2748 "btop"):
#0 0x00007f2bc7cb687c in read () from /usr/lib/libpthread.so.0
#1 0x00007f2bc7eed662 in std::__basic_file::xsgetn (this=this@entry=0x7f2bc8037b08 <__gnu_internal::buf_cin+104>, __s=0x563a7996ddd0 "\033[A0;122;33m\033[<0;114;34m\033[<65;97;45M\033[<65;97;45M\033[<65;97;45M\033[<65;97;45M\033[<65;97;45M\033[<65;97;45M\033[<65;97;45M\033[<65;97;45M\033[<65;97;45M\033[<65;97;45M\033[<65;97;45M\033[<65;97;45M\033[<65;97;45M", __n=__n@entry=8191) at basic_file.cc:331
#2 0x00007f2bc7f2eb61 in std::basic_filebuf<char, std::char_traits >::underflow (this=0x7f2bc8037aa0 <__gnu_internal::buf_cin>) at /build/gcc/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/streambuf:487
#3 0x00007f2bc7ec7ee1 in std::basic_streambuf<char, std::char_traits >::sgetc (this=0x7f2bc8037aa0 <__gnu_internal::buf_cin>) at /build/gcc/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/streambuf:343
#4 std::basic_streambuf<char, std::char_traits >::sgetc (this=) at /build/gcc/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/streambuf:343
#5 std::basic_streambuf<char, std::char_traits >::snextc (this=) at /build/gcc/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/streambuf:308
#6 std::istream::ignoreXX (this=0x7f2bc80385a0 std::cin, __n=9223372036854775807) at /build/gcc/src/gcc/libstdc++-v3/src/c++98/compatibility.cc:96
#7 0x0000563a7951fa67 in Input::getabi:cxx11 ()
#8 0x0000563a794e2abd in main ()
Describe the solution you'd like
include a night-owl.theme
file in the default options
Describe alternatives you've considered
i've already implemented it for myself and wanted to share it
Additional context
this theme is inspired by the original VS Code version by sdras
Describe the bug
The installer script installs btop++ to /usr/local/bin/btop. On Centos this does not appear to be in path for 7 and 8. When I symlink it to /usr/local/sbin/btop it is found and executed.
Expected behavior
as btop runs with super user requirements will it not make sense to install it to /usr/local/sbin/ instead?
Hello,
Awesome update of htop so far, thanks for your work.
Only thing I've noted so far is that download and upload values are the same :
Logs :
2021/09/24 (09:40:25) | ===> btop++ v.1.0.6
2021/09/24 (09:40:25) | DEBUG: Starting in DEBUG mode!
2021/09/24 (09:40:25) | INFO: Logger set to DEBUG
2021/09/24 (09:40:25) | DEBUG: Setting LC_ALL=fr_FR.UTF-8
2021/09/24 (09:40:25) | INFO: Running on /dev/pts/0
2021/09/24 (09:40:32) | INFO: Quitting! Runtime: 00:00:07
Describe the bug
After install, the terminal keeps the text setting of white/bold
To Reproduce
I downloaded the linux x86-64 tbz file -
mkdir btop
wget https://github.com/aristocratos/btop/releases/download/v1.0.4/btop-1.0.4-linux-x86-64.tbz
PREFIX=test make install
My term is still bold white.
Expected behavior
I expect my term to reset.
I looked in the makefile and it's missing a \033[0m
on the last printf statement in the install.
Screenshots
First run is before makefile modification, second is after.
Is your feature request related to a problem? Please describe.
Keeping track of drive temps in my storage array is useful for tuning fan configuration, and this would be particularly in newer builds as ambient temps tend to change throughout the year. As my array sits a rack beside my desk keeping it both cool and quiet is important to me. Having temps available at a glance would be very useful in determining if x hotswap bay really needs a fan or not, or if y fan could be run at lower rpm. Additionally, Kernel 5.5+ is expected expose nvme drive temperatures to hwmon, and that should be extremely useful for keeping watch of their thermals in newer builds. Additionally drives running too hot or too cold can lead to more earlier than expected failure. The ability to keep track of their temps through btop would be of notable utility in this regard.
Describe the solution you'd like
Add hard drive temperatures to data collected and displayed.
I think current temperature alone would be sufficient for my uses- optionally a small graph would be great too.
I suggest the use of hwmon as it doesn't require additional packages. Furthermore, as you've already used hwmon as a collector method for CPU Temp in btop_collect.cpp - using a similar method to get temp1_input for each drive using hwmon's drivetemp module shouldn't be too much of a stretch.
Describe alternatives you've considered
hddtemp and smartctrl are both common solutions to retrieving this data but are are both dependent on installing additional packages. You could well check for them much as you did with various options like coretemp for the cpu temperature.
Additional context
With hwmon's drivetemp module loaded (which it may or may not be by default- sudo modprobe drivetemp should load it on supporting kernel versions if it isn't already) you can grab current temperature in Milli-degrees Celsius from /sys/class/hwmon/hwmon*/temp1_input obviously the value returned would need to be multiplied accordingly (value*0.001) before being displayed.
with the drivetemp module loaded:
Describe the bug
Tried to run on pop OS 21.04. Crashes on startup with the following log:
/usr/include/c++/11/ranges:540: constexpr std::ranges::iota_view<_Winc, _Bound>::iota_view(std::type_identity_t<_Winc>, st
3 d::type_identity_t<_Bound>) [with _Winc = int; _Bound = int; std::type_identity_t<_Winc> = int; std::type_identity_t<_Boun
2 d> = int]: Assertion 'bool(__value <= __bound)' failed.
1 fish: “btop” terminated by signal SIGABRT (Abort)
It seems that it doesn't like the kitty terminal, but sometimes it seemed random. Unfortunately I wasn't taking note of everything before but I think it happens on kitty but not eg. on gnome terminal.
To Reproduce
Run the executable on the kitty terminal.
Info (please complete the following information):
Additional context
contents of ~/.config/btop/btop.log
(try running btop with --debug
flag if error.log is empty)
2021/09/20 (19:15:41) | ===> btop++ v.1.0.2
2021/09/20 (19:15:41) | DEBUG: Starting in DEBUG mode!
2021/09/20 (19:15:41) | INFO: Logger set to DEBUG
2021/09/20 (19:15:41) | DEBUG: Setting LC_ALL=en_US.UTF-8
2021/09/20 (19:15:41) | INFO: Running on /dev/pts/1
I know you already added hjkl navigation to bpytop. Is it missing or am i just too stupid to find out how to configure?
As an idea you may be able to get away with less requests like these if users could add their keybindings to the config file. Not sure how much time would go into implementing that but just a suggestion.
Have to say that i really like this version. As much as i love python this kind of thing is better written in a lower level language.
It would be useful to pick the orientation of the windows. the default works well for "landscape" windows, but not for "portrait" type windows. for instance, i might want procs and network stacked one on top of the other.
i guess the orientation options as they are are too restrictive: maybe let the user pick left/right/top/bottom for any panel.
Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
I notice two issues:
~/.config/btop/btop.conf
file will changeThe btop.conf file should only be modified when you manually modify it.
Describe the solution you'd like
A clear and concise description of what you want to happen.
Put those parts that are easy to change into another file such as ~/.cache/btop/btop.conf
, since I sync my btop.conf with git in dotfiles, every time the btop changes, it is annoying that I got a new modification in my dotfiles.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.
Ubuntu 18.04 after running btop
command it immediately quits with message:
ERROR: Exception in runner thread -> Net:: -> stoul
I've tried to set net_iface
to wlo1
but no luck, I can confirm files like /sys/class/net/wlo1/statistics/tx_bytes
and /sys/class/net/wlo1/statistics/rx_bytes
are present
Info (please complete the following information):
Additional context
contents of ~/.config/btop/btop.log
2021/09/30 (19:58:49) | ===> btop++ v.1.0.11
2021/09/30 (19:58:49) | DEBUG: Starting in DEBUG mode!
2021/09/30 (19:58:49) | INFO: Logger set to DEBUG
2021/09/30 (19:58:49) | DEBUG: Setting LC_ALL=en_US.UTF-8
2021/09/30 (19:58:49) | INFO: Running on /dev/pts/2
2021/09/30 (19:58:49) | ERROR: Exception in runner thread -> Net:: -> stoul
2021/09/30 (19:58:49) | INFO: Quitting! Runtime: 00:00:00
GDB Backtrace
If btop++ is crashing at start the following steps could be helpful:
run gdb btop
r
to run, wait for crash and press enter
bt
to get backtrace
Copy and paste the backtrace here:
Starting program: /usr/local/bin/btop
ERROR: Exception in runner thread -> Net:: -> stoul
[Inferior 1 (process 26102) exited with code 01]
(gdb) bt
No stack.
My 4 TB RAID-0 array doesn't show up. Also, my 4 TB RAID-1 array shows up as 2.41 GiB.
Info (please complete the following information):
btop-1.0.6-linux-i686.tbz
Which character(s) are used for the blank space in the CPU, network and memory graphs?
At the moment I'm using the font Cozette and btop looks like this:
My guess is one of the “Geometric Shapes”, which are not all supported by Cozette.
Before opening an issue at https://github.com/slavfox/Cozette, I wanted to confirm this suspicion.
Describe the bug
When I close a branch in the process tree view, the processes under that branch are moved to the bottom of the list.
To Reproduce
Close a branch and scroll down to the end of the list.
Expected behavior
The processes should disappear.
Screenshots
Info (please complete the following information):
Describe the bug
For some reason btop randomly hangs (after a couple of mins or hours), CPU jumps to 100% for btop process.
To Reproduce
Not sure since it's random. Installed from snap edge though.
Expected behavior
Screenshots
[If applicable, add screenshots to help explain your problem.]
Info (please complete the following information):
bpytop -v
: 1.0.9uname -m
uname -r
: 5.11.0.0-36-genericAdditional context
contents of ~/.config/btop/btop.log
: doesn't exist, only btop.conf
(try running btop with --debug
flag if error.log is empty): OK
Describe the bug
When I choose to only display CPU temperatures in pane 1, they end up being pushed to the right and only the first digit is visible.
To Reproduce
Only show the CPU pane (no 1)
Expected behavior
CPU temps should remain visible.
After a few seconds:
Info (please complete the following information):
PS: It's doesn't do it on xterm but xterm doesn't show the dots.
Describe the bug
When attempting to run on a Raspberry Pi 2, btop crashes immediately.
To Reproduce
Expected behavior
The program starts properly with no errors.
Screenshots
Terminal output:
pi@raspberrypi:~/btop $ sudo make install
██████╗ ████████╗ ██████╗ ██████╗
██╔══██╗╚══██╔══╝██╔═══██╗██╔══██╗ ██╗ ██╗
██████╔╝ ██║ ██║ ██║██████╔╝ ██████╗██████╗
██╔══██╗ ██║ ██║ ██║██╔═══╝ ╚═██╔═╝╚═██╔═╝
██████╔╝ ██║ ╚██████╔╝██║ ╚═╝ ╚═╝
╚═════╝ ╚═╝ ╚═════╝ ╚═╝ Installer
Installing binary to: /usr/local/bin/btop
Installing doc to: /usr/local/share/btop
Installing themes to: /usr/local/share/btop/themes
pi@raspberrypi:~/btop $ sudo make setuid
File: /usr/local/bin/btop
Setting owner root:root
Setting SUID bit
pi@raspberrypi:~/btop $ btop
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_M_construct null not valid
Aborted
Info (please complete the following information):
Additional context
Logs are very unhelpful:
2021/09/21 (01:24:34) | ===> btop++ v.1.0.2
2021/09/21 (01:24:34) | DEBUG: Starting in DEBUG mode!
2021/09/21 (01:24:34) | INFO: Logger set to DEBUG
[end of log file]
Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
There are many benefits from using Cmake. Check out the documentation. Biggest one is portability. On platforms where Make
isn't available, Cmake can still be made use of.
Describe the solution you'd like
A clear and concise description of what you want to happen.
I'd like to see this project built with llvm, which requires Cmake support. Compiler optimizations are much better using llvm.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Do nothing.
Additional context
Add any other context or screenshots about the feature request here.
Describe the bug
Running on RHEL 7.7 at work, using the statically compiled binary 1.0.9, it complains of no UTF-8 locale detected. While locale is:
[jdehaes@berx771 Snape]$ locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
When using the --utf-force flag, btop works perfectly. We have the same on other RHEL 7.x boxes.
I can not compile/debug btop on this machine (as its compilers are too old - even with gcc 8.3 -std=c++20 is not available). On a RHEL 8 system this just works. I can compile/debug there (after installing gcc 10 toolchain), but useless as the problem doesn't occur there. The locale settings are identical on that system.
To Reproduce
Get a RHEL 7.7 (probably any 7.x will do) system (via docker?) and copy the btop binary. It will complain although locale is UTF-8.
Expected behavior
btop can run with the --utf-force flag.
[jdehaes@berx771 Snape]$ btop
ERROR: No UTF-8 locale detected!
Use --utf-force argument to force start if you're sure your terminal can handle it.
[If applicable, add screenshots to help explain your problem.]
Info (please complete the following information):
Additional context
contents of ~/.config/btop/btop.log
-> nothing there other than no UTF-8 locale detected.
Hi, I think that the program needs just one more FINAL rewrite but this time in the powerful HolyC Rust. It would be the final solution to all of our problems. Could you explain why did you rewrote the entire thing for the 2nd time?
PS. Don't take it too seriously. I just couldn't stop laughing on that announcement and couldn't stop myself from writing it. I really appreciate your hard work. Just the situation is a great meme. :D
gdb, ps and htop can display custom thread names, the 16 char name of the thread explicitly written in by a developer. it would be useful to have either a column with this, or the option to add the column.
Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Add support for Sixel, Kitty, and Iterm2's graphic protocols. Take a look at https://github.com/hackerb9/lsix for example (which just does Sixel).
Describe the solution you'd like
A clear and concise description of what you want to happen.
Add support for the graphic protocols in order to improve graphics further, and in some cases potentially boost performance as well. On Linux, start with detecting Kitty support. Kitty and Wezterm both support the Kitty protocol and notcurses favors this support when available, otherwise detect Sixel. Otherwise ignore altogether. On Mac, look for Iterm2 graphics protocol support (assuming you're not running on the aforementioned terminals), if it's not there, then search for Sixel and if that's not available, ignore there too.
Notcurses also has a fall-back layer where graphics protocols aren't supported, it will display things as best it can, which is still pretty well, if not quite as good which can make notcurses an optional dependency of this feature request (you may need to do very little as notcurses does detection for all 3 protocols).
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Do nothing.
Additional context
Add any other context or screenshots about the feature request here.
I often use Linux in a Hyper-V VM for development which has dynamic memory allocation enabled. btop never changes the total memory after it is launched. That means when Hyper-V allocates more or less memory to the VM all memory stats become incorrect. I have to use htop instead since it updates the total memory while running. Othewise I love it.
Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Provide a better TUI experience than what ncurses
provides along with allowing Windows support eventually.
https://github.com/dankamongmen/notcurses
Describe the solution you'd like
A clear and concise description of what you want to happen.
I want to see better performance and graphics that notcurses provides that ncurses does not.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Do nothing.
Additional context
Add any other context or screenshots about the feature request here.
It's a cross-platform Apache2 licensed library that's available in many Linux distribution package managers as well as Brew/Macports. It also provides C++ wrappers so that you don't need to use C code (which would be sub-optimal in a C++ project) with extensive documentation and discussion threads to help answer any questions you may have on how to use it.
Hi @aristocratos ,
Hope you are all well !
I was wondering if it would be possible to create an homebrew formula for your great project :-)
Ps. apt package also ^^
Cheers,
Luc Michalski
For some reason, default btop display doesn't show properly cores temperature
First of all: Nice work! I'm looking forward to using btop++ on my machines.
Describe the bug
When $LANG
has a non-UTF-8 locale set (or a locale without the exact suffix UTF-8
, e.g. ´de_DE.utf8`), the program terminates with a segfault.
To Reproduce
$ LANG=de_DE.utf8 ./bin/btop # for a build inside the repo
Expected behavior
The program should accept the locale and start as expected or don't accept the locale and exit with an error message.
Screenshots
No screenshots, but see this gdb output:
$ gdb --args ./bin/btop --debug ✔ 183
GNU gdb (Gentoo 10.2 vanilla) 10.2
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://bugs.gentoo.org/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./bin/btop...
(gdb) r
Starting program: /home/nex/build/btop/bin/btop --debug
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7c5b15e in __pthread_clockjoin_ex () from /lib64/libpthread.so.0
(gdb) bt
#0 0x00007ffff7c5b15e in __pthread_clockjoin_ex () from /lib64/libpthread.so.0
#1 0x0000555555561c74 in clean_quit (sig=-1) at src/btop.cpp:187
#2 0x0000555555561f40 in _exit_handler () at src/btop.cpp:232
#3 0x00007ffff7ad2f67 in ?? () from /lib64/libc.so.6
#4 0x00007ffff7ad310a in exit () from /lib64/libc.so.6
#5 0x00005555555673b2 in main (argc=2, argv=0x7fffffffd908) at src/btop.cpp:728
(gdb) q
A debugging session is active.
Inferior 1 [process 47362] will be killed.
Quit anyway? (y or n) y
Info (please complete the following information):
5.4.80-gentoo-x86_64
Additional context
contents of ~/.config/btop/error.log
: file non-existent since the program couldn't start properly
Since I have LANG=de_DE.utf8
set and thus a UTF-8-capable locale, starting btop with --utf-force
helped as a workaround. However, the proper behavior should be that LANG=de_DE.utf8
should be recognized as UTF-8-capable locale and thus the program shouldn't even get to the point of trying to generate an error message.
I've already found the offending line:
Line 728 in 480b421
with a bit of context:
Lines 705 to 728 in 480b421
So one issue is that the locale didn't get recognized as UTF-8 properly.
The more important issue here is that btop probably tries to join a pthread which it never created–more or less a use-before-malloc:
Lines 705 to 728 in 480b421
So the proper fix for the second issue is probably just checking if Runner::runner_id
is a valid thread (i.e. has been created).
But on that notice, why bother using pthread directly and not std::thread
?
If it's because an std::thread
on the stack automatically starts a thread, just wrap it inside a std::unique_ptr
.
A check using std::unique_ptr::operator bool
then is a very convenient method to check if there is a thread possibly running.
Also, you don't have to take care of cleaning up after the thread since std::unique_ptr
does that for you.
But that's just an idea.
I suppose you had a valid reason to use pthread directly.
A lot of users across various Linux Distros would have convenient access to this application if it were distributed as Flatpak and/or Snap. It would also greatly help discoverability of this application if it was published there.
Have you considered publishing this as a Flatpak on Flathub and/or as a Snap on the Snap store? Flatpak is the more popular universal app format out of the two (because it's more open by design), so if you had to choose only one, I'd go with Flatpak.
Hello,
Thank you for this resource monitoring utility, but may I recommend that you consider package it as an AppImage for easy of use and wider adoption, please.
AppImages are very easy to create and can easily be automated for new releases.
Describe the bug
btop crashes quite a few times while attempting to launch it via sxhkd
2021/09/21 (08:49:04) | ===> btop++ v.1.0.2
2021/09/21 (08:49:04) | ERROR: Runner thread died unexpectedly!
It works just fine when I manually launch my terminal and type btop
My sxhkd config:
# btop++ process viewer
super + b
alacritty -e btop
To Reproduce
Attempt to launch btop via sxhkd
Info (please complete the following information):
Describe the bug
Building failing on Alpine linux 3.14.2 x86_64
To Reproduce
Linux alpine 4.9.65-1-hardened #2-Alpine SMP Mon Nov 27 15:36:10 GMT 2017 x86_64 GNU/Linux
alpine:~$ more /etc/alpine-release
3.14.2
alpine:~$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-alpine-linux-musl/10.3.1/lto-wrapper
Target: x86_64-alpine-linux-musl
Configured with: /home/buildozer/aports/main/gcc/src/gcc-10.3.1_git20210424/configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --build=x86_64-alpine-linux-musl --host=x86_64-alpine-linux-musl --target=x86_64-alpine-linux-musl --with-pkgversion='Alpine 10.3.1_git20210424' --enable-checking=release --disable-fixed-point --disable-libstdcxx-pch --disable-multilib --disable-nls --disable-werror --disable-symvers --enable-__cxa_atexit --enable-default-pie --enable-default-ssp --enable-cloog-backend --enable-languages=c,c++,d,objc,go,fortran,ada --disable-libssp --disable-libmpx --disable-libmudflap --disable-libsanitizer --enable-shared --enable-threads --enable-tls --with-system-zlib --with-linker-hash-style=gnu
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.3.1 20210424 (Alpine 10.3.1_git20210424)
alpine:~$
Expected behavior
building without errors
Screenshots
alpine:~/btop-1.0.2$ make
██████╗ ████████╗ ██████╗ ██████╗
██╔══██╗╚══██╔══╝██╔═══██╗██╔══██╗ ██╗ ██╗
██████╔╝ ██║ ██║ ██║██████╔╝ ██████╗██████╗
██╔══██╗ ██║ ██║ ██║██╔═══╝ ╚═██╔═╝╚═██╔═╝
██████╔╝ ██║ ╚██████╔╝██║ ╚═╝ ╚═╝
╚═════╝ ╚═╝ ╚═════╝ ╚═╝ Makefile v1.2
PLATFORM ?| Linux
ARCH ?| x86_64
CXX ?| g++ (10.3.1)
THREADS :| auto
REQFLAGS !| -std=c++20
WARNFLAGS :| -Wall -Wextra -pedantic
OPTFLAGS :| -O2 -ftree-loop-vectorize -flto=auto
LDCXXFLAGS :| -pthread -D_FORTIFY_SOURCE=2 -D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector -fstack-clash-protection -fcf-protection
CXXFLAGS +| $(REQFLAGS) $(LDCXXFLAGS) $(OPTFLAGS) $(WARNFLAGS)
LDFLAGS +| $(LDCXXFLAGS) $(OPTFLAGS) $(WARNFLAGS)
Building btop++ (v1.0.2)
<...>
Linking and optimizing binary...
/usr/include/c++/10.3.1/ext/string_conversions.h: In function '__to_xstring.constprop':
/usr/include/fortify/stdio.h:70:28: error: inlining failed in call to 'always_inline' 'vsnprintf': function body can be overwritten at link time
70 | _FORTIFY_FN(vsnprintf) int vsnprintf(char *__s, size_t __n, const char *__f,
| ^
/usr/include/c++/10.3.1/ext/string_conversions.h:111:32: note: called from here
111 | const int __len = __convf(__s, __n, __fmt, __args);
| ^
make[1]: *** [/tmp/ccLbJlLP.mk:56: /tmp/btop.OglgLe.ltrans18.ltrans.o] Error 1
lto-wrapper: fatal error: make returned 2 exit status
compilation terminated.
/usr/lib/gcc/x86_64-alpine-linux-musl/10.3.1/../../../../x86_64-alpine-linux-musl/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
make: *** [Makefile:167: btop] Error 1
Describe the bug
While compiling something my CPU spikes over 100% well into the 300% area in the proc tree
It might be interesting to note that it only occured when a single process was going ham at the cpu, if i compile clang++ over multiple processes i have no problem anymore
To Reproduce
Compile unreal engine from source
Expected behavior
CPU Should be maxed at 100% with all proc combined
Screenshots
Info (please complete the following information):
btop version: 1.0.4
static binary from release
x86_64
Linux
5.13.0-7614-generic
Pop!_OS 21.04
Alacritty
MesloLGS
2021/09/22 (09:29:34) | ===> btop++ v.1.0.4 2021/09/22 (09:29:34) | ERROR: Terminal size to small for current config. (WxH) Current: 94x22 | Needed: 80x24 Resize terminal or disable some boxes in config file to fix this.
When the number of CPU cores/threads is high (>99), there are two graphical issues:
Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Add safer math than <cmath>
. https://github.com/chromium/chromium/tree/master/base/numerics
Your response in the C++ suggestion discussion thread in bpytop:
dynamic_bitset and libpopcnt looks interesting though, I'm currently trying to optimize out some unnecessary string parsing in loops using std::bitset.
Also lastly, add https://github.com/microsoft/mimalloc to your build steps to improve allocation performance significantly. This will require #28 as it's extremely easy to add to Cmake file.
Describe the solution you'd like
A clear and concise description of what you want to happen.
Improved safety of the C++ code, better performance and other optimizations.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Do nothing.
Additional context
Add any other context or screenshots about the feature request here.
Describe the bug
The documentation (README.md) and --help output both reference an option --utf-foce
("force start even if no UTF-8 locale was detected").
But this option doesn't exist. The actual option is --utf-force
.
To Reproduce
Run btop --utf-foce
and notice you get
kde@midna ~/tmp/btop $ btop --utf-foce
Unknown argument: --utf-foce
Use -h or --help for help.
Expected behavior
I expected btop to start up without issue (as it did when using --utf-force
). I didn't not test on a non-UTF-8 locale yet but I would expect the option to work even in that case.
Info (please complete the following information):
btop -v
not bpytop -v
)Additional context
Let me know if you actually need this
Dear community:
I have tried to install the latest version of btop inside of WSL 1.0 and encountered some issue. After the installation process has finished successfully, I tried to launch btop, but there is only an error message showing up:
-bash: /usr/local/bin/btop: cannot execute binary file: Exec format error
Did someone encounter this problem before, or know the solution for this problem?
regards:
Benedikt
Describe the bug
[A clear and concise description of what the bug is.]
To Reproduce
[Steps to reproduce the behavior:]
Expected behavior
[A clear and concise description of what you expected to happen.]
Screenshots
Just missing the 5 at the end: Pentium Silver J5005
Info (please complete the following information):
btop -v
1.0.13In btop
, processes run by LDAP users show up with their UIDs instead of usernames in the processes table. I am using OpenLDAP and SSSD for user management, configured according to the ArchWiki. This bug does not occur when using bpytop
or htop
.
To Reproduce
Run btop
on a machine with processes that are being run by LDAP users.
Expected behavior
The LDAP users' usernames should show up in the processes table instead of their UIDs.
Screenshots
Info (please complete the following information):
1.0.10
Is your feature request related to a problem? Please describe.
No.
Describe the solution you'd like
All statistics already present in btop, but filtered in a per-cgroup basis.
Describe alternatives you've considered
top and htop are tools that can show which cgroup container a process is running on, but that's about it.
Additional context
In a context where containers (Docker, LXC, podman, containerd, etc.) are commonly used, I believe having the ability to filter statistics for each container for debugging purposes is a 'must' feature to have.
It is often useful when monitoring the system to see if affinities are set as expected. the PROCESSOR column in htop, corresponding to the last processor that a process/thread was scheduled on would be a great addition as an optional column
Describe the solution you'd like
Any chance there's already a built in way to change the banner colors to the theme selected?
Or maybe just print it out as text instead of ASCII art. The banner doesn't match the theme that i'm using at all right now (nord), cheers
Describe the bug
ERROR: Exception in runner thread -> Proc:: -> array::at: __n (which is 18446744071562068066) >= _Nm (which is 101)
To Reproduce
Run btop
and wait
Expected behavior
Handling an exception with code
Screenshots
Info (please complete the following information):
Additional context
contents of ~/.config/btop/error.log
: empty
contents of ~/.config/btop/btop.log
:
2021/09/20 (11:20:41) | ===> btop++ v.1.0.1
2021/09/20 (11:20:41) | ERROR: Exception in runner thread -> Proc:: -> array::at: __n (which is 18446744071562068063) >= _Nm (which is 101)
2021/09/20 (11:39:42) | ===> btop++ v.1.0.1
2021/09/20 (11:39:42) | ERROR: Exception in runner thread -> Proc:: -> array::at: __n (which is 18446744071562068063) >= _Nm (which is 101)
2021/09/20 (12:29:13) | ===> btop++ v.1.0.1
2021/09/20 (12:29:13) | ERROR: Exception in runner thread -> Proc:: -> array::at: __n (which is 18446744071562068066) >= _Nm (which is 101)
2021/09/20 (15:19:59) | ===> btop++ v.1.0.1
2021/09/20 (15:19:59) | ERROR: Exception in runner thread -> Proc:: -> array::at: __n (which is 18446744071562068066) >= _Nm (which is 101)
2021/09/20 (15:32:25) | ===> btop++ v.1.0.1
2021/09/20 (15:32:25) | DEBUG: Starting in DEBUG mode!
2021/09/20 (15:32:25) | INFO: Logger set to DEBUG
2021/09/20 (15:32:25) | DEBUG: Setting LC_ALL=ru_RU.utf8
2021/09/20 (15:32:25) | INFO: Running on /dev/pts/4
2021/09/20 (17:36:35) | ERROR: Exception in runner thread -> Proc:: -> array::at: __n (which is 18446744071562068068) >= _Nm (which is 101)
2021/09/20 (17:36:35) | INFO: Quitting! Runtime: 02:04:10
Is it not possible to make the CPU box a bit bigger when there are only 2 or 4 cores? On AMD it looks a bit squashed.
Describe the solution you'd like
As there are only 2 cores on my VM the AMD CPU Model name is not displayed optimally.
Can the box not be sized on the core count ( > 4 ) , and if Temperature is being displayed, to dynamically size it? I see that the box is already sized on the height of the terminal window. Maybe make it configurable that if the temperature is not displayed to allow that space to be used for displaying the CPU core load using that space? Making the Core graph a bit wider and a bit taller.
Or scroll the text when you click the CPU model?
Describe the bug
displays incorrectly (see screenshots)
To Reproduce
git clone --depth 1 https://github.com/hlissner/doom-emacs ~/.emacs.d
~/.emacs.d/bin/doom install
# open ~/.doom.d/init.el, uncomment line with `vterm` by deleting leading semicolons
~/.emacs.d/bin/doom sync
Expected behavior
render similarly to bpytop
Screenshots
Info (please complete the following information):
Additional context
❯ cat ~/.config/btop/btop.log
2021/10/02 (12:42:00) | ===> btop++ v.1.0.12
2021/10/02 (12:42:00) | DEBUG: Starting in DEBUG mode!
2021/10/02 (12:42:00) | INFO: Logger set to DEBUG
2021/10/02 (12:42:00) | DEBUG: Using locale en_US.UTF-8
2021/10/02 (12:42:00) | INFO: Running on /dev/pts/1
2021/10/02 (12:42:00) | INFO: Forcing tty mode: setting 16 color mode and using tty friendly graph symbols
2021/10/02 (12:42:06) | INFO: Quitting! Runtime: 00:00:06
I also tried flipping all setting in general
tab, but it didn't help
In the current version of README.md, 2 images have centered text: options-menu.png & help-menu.png
Centered text may look prettier, but is harder to read and scan down than left-aligned text. =)
Under 170 words more: https://practicaltypography.com/centered-text.html
(And remember right-aligned in case of i18n for RTL-languages)
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.