[bug] htop display issues after broadcast message

[Fade78]

Yeah, so this is maybe niche but when htop is running for a long time, sooner or later, a broadcast message like "this server will reboot in two days" will destroy the display and btop will not recover.

How to test:

• open four terminals on the same server
• start in the first three terminals: htop, btop, top
• in the fourth terminal type the following (maybe use sudo if it doesn't work)

wall this is a test message

Compare the display of btop, htop and top. You'll see that htop can't recover from the broadcasted message.

[natoscott]

If I'm reading this correctly, you seem to have opened a(nother) btop bug in the htop repo here?

[Fade78]

If I'm reading this correctly, you seem to have opened a(nother) btop bug in the htop repo here?

No I messed up my message. I corrected it. It's really a htop issue.

Also my previous one was in fact a htop issue too.

[natoscott]

I'm not certain, but guessing a signal is being sent to htop that it doesn't handle (or perhaps mishandles) - you may be able to run htop under gdb and it should let you know if a signal is causing the unexpected termination (and which signal).

[Fade78]

From what I see it seems like a terminal display issue. The broadcasted message is persistent. Some parts of the screen are not refreshed correctly and maybe the root cause is because lines seems to be shifted from their original place.

For reference, here is my terminal setting.

# echo $TERM
xterm-256color

[fasterit]

Press Ctrl-L. htop is just not updating all of the display all the time as the other tools do.

[Fade78]

CTRL-L actually works. Thanks.

Is it possible to have an option to actually refresh all the terminal at each turn so, if it's on a team big screen, someone doesn't have to run to a keyboard and do CTRL-L ?

[fasterit]

You could just mesg n the terminal where htop is running.

Or do

while : ; do htop -n 300; done

I'll leave it as an exercise to you on how to exit that loop 😄

[Explorer09]

Is it just I that consider htop not cleaning the broadcast message a feature and not a bug?

[natoscott]

Yeah, I misinterpreted "htop can't recover" as meaning htop failed and exited. I don't think there's any code changes in htop needed here.

[BenBE]

Actually not refreshing the whole display is a feature of ncurses as ncurses was written for very slow (serial) terminals at 300 baud where even refreshing the screen as we usually see it on an old 80x25 display would take several seconds. Sending the least amount of data to such a display was a feature back then and ncurses still optimizes for this. Not clearing the display at each pass also avoids flickering issues with some displays.

FWIW: I've actually seen htop being run on a hard-type tty (with actual paper in it); and yes this takes ages (was mostly for fun and seeing what happens).

I see little sense in changing the current behaviour as htop already ensures blanking out areas where previously data was written (e.g. the text and bar meters). The process list also receives the full line in the internal RichString implementation, thus will refresh the process table too. There are only small regions, where only occational refreshes are done like the table header and the status bar and these areas are of little importance, when you use htop regularly for monitoring.

[Fade78]

The displays never recover and is worst for each new message because the lines are shifted upward.

Here is the progression. This screen capture is at the same position for each images and is the top of the terminal display.

Top of the terminal, in the normal case.

Top of the terminal, after one wall message received.

Top of the terminal, after two wall messages received.

[Explorer09]

@Fade78 Interesting. This means htop tried to update the display with all cursor positions wrong. But on the other hand this shows that ncurses is good at determining the "deltas" of the terminal display and only re-paint those when things need updated.