btop
btop copied to clipboard
[BUG] Btop showing blank screen on Ubuntu 20.04 LTS
Describe the bug
When I launch btop
from my Ubuntu 20.04 it simply shows a blank black screen and nothing happens. I am using zsh with oh-my-zsh but it also does the same on bash. Please see the attached screenshots and screencast video. Is there a way I can fix this issue on my machine?
I also tested with older versions and I am seeing the same problem.
EDIT: After restarting my computer it started working for a while. Then it froze and now I am getting again the same result.
Screenshots
Info (please complete the following information):
- btop++ version:
1.2.8
- Binary: Installed using: I tried both from binary and from snap - same results
- Architecture:
x86_64
- Platform:
Ubuntu 20.04.4 LTS
- (Linux) Kernel:
5.15.0-41-generic
- Terminal used:
zsh
andbash
(both have the same result)
contents of ~/.config/btop/btop.log
$ cat ~/.config/btop/btop.log
1 │
2 │ 2022/07/16 (10:57:09) | ===> btop++ v.1.2.8
3 │ 2022/07/16 (10:57:09) | DEBUG: Starting in DEBUG mode!
4 │ 2022/07/16 (10:57:09) | INFO: Logger set to DEBUG
5 │ 2022/07/16 (10:57:09) | DEBUG: Using locale en_US.UTF-8
6 │ 2022/07/16 (10:57:09) | INFO: Running on /dev/pts/3
After restarting my computer it started working for a while. Then it froze and now I am getting again the same result.
Does adding force_tty = True
to the btop.conf file change anything? (~/.config/btop/btop.conf)
Facing the same issue, it was working fine but after update today, it stopped working. Tried to install older version like 1.2.7 but still the same. Using ArchLinux.
Gah - encountered for the first time today. A reboot fixed the issue - but it's disconcerting. Adding this detail as another data point.
Had the same issue. Ran strace, found out that statvfs was blocking due to some automount magic I had setup a long time ago. I solved my issue by removing the said automount magic. But statvfs blocks for network devices as well. Maybe a better long term solution would be wrapping the call in a function that would support timeouts. Something like this could work. @aristocratos what are your thoughts on this?
@crestfallnatwork What version are you on?
@nobounce I am on version 1.2.13
@crestfallnatwork
Good catch, wrapping stavfs
sounds like a good idea.
I believe one approach could be to run all statvfs
calls asynchronously in a static vector of futures, any future that doesn't finish in time gets "left behind". And only if the statvfs
call for a particular disk has finished does it trigger again.
That way "slow" statvfs
calls will still report statistics but maybe only once every couple of cycles.
Any completely "stuck" threads would get cleaned up at program exit.
Will take a look at it when I've got some time.
@martinszeltins @KamilKleina @jamesawebb Please try with latest commits, #633 was just merged and will hopefully fix this issue.
I've got the same blank screen on MacOS Sonoma 14.2.1 after few sleep/awake cycles on my Macbook. Using the latest version 1.2.13
I just want to say that I found this same bug where statvfs hangs when trying to check an automount point I have, in which the drive is not always available, and updating to the latest 1.3.0 fixes the problem.