Why are some program basenames highlighted in red?

[cobrafast]

I just got 3.0.3-1 via my distros package manager and noticed that some processes have their command basename highlighted in red instead of cyan. What does that mean? I can't find any distinction in Process.c, as I understand it they should all be cyan.

[BenBE]

This red markup happens, when the executable used to execute the command, has been replaced by another version (e.g. by a package update) since the program was started.

[milosivanovic]

That's super useful, but is that configurable in the F2 -> Display Options for those who prefer a consistent colour? Not every binary needs to be reloaded from disk when it's changed, and so htop can start looking messy for systems where there's a large number of both.

[BenBE]

Currently this is linked with the basename highlighting.

@milosivanovic Can you open a feature request for this? I'm currently rewriting some related code in that area, so adding this setting isn't too hard.

FWIW the information shown is mostly a side-product of some other information that is determined anyway, thus there's no real performance impact.

[eworm-de]

Is this re-evaluated at runtime?

On some servers I have running htop in a tmux session. Wondering if htop shows replaced executables in red that were replaced after its start.

[BenBE]

It's re-evaluated whenever the EXE/COMM/CMDLINE fields are refreshed. So if you have refresh thread names activated in configuration you might also see the exe+color updated at runtime.

[eworm-de]

Ah, you reference Update process names on every refresh here, no?
IMHO this is kind of misleading. If I uncheck... Does it refresh at longer intervals or does it not refresh at all?

Perhaps adding parenthesis makes it clearer: Update process names (on every refresh)

On the other hand... Wondering if it makes sense to update process names anyway with longer interval?

[fasterit]

That's super useful, but is that configurable in the F2 -> Display Options for those who prefer a consistent colour? Not every binary needs to be reloaded from disk when it's changed, and so htop can start looking messy for systems where there's a large number of both.

You should probably not prefer a "consistent color" because that means you likely ignore that you should have updated the running binary after it was replaced on disk. Typically due to a security update as stable distros don't really update executables much for other reasons.

[milosivanovic]

@fasterit it's certainly a very useful feature, but it's a visually jarring change for a 16-year-old UNIX program. You're right that ideally, the binary wouldn't be left running after an update, but one of the great things about UNIX systems is that you have the choice. So to follow that tradition, it would be nice to have the choice to use this new but very useful feature.

As a more direct response: It shouldn't be assumed that the user isn't already aware of outdated binaries, and that they don't have legitimate reasons for not immediately restarting them. In your comment you already assumed running a stable distribution with updates typically being security updates, and while this is true, is that htop's only target audience?

It's also assumed that stale binaries are even the ones worth highlighting. You're much more likely to run into serious issues when updating system libraries like libpam and then not restarting every binary that references it, even though the binaries themselves are not stale:

>>> Messages generated by process 11719 on 2020-12-22 16:02:08 NZDT for package sys-libs/pam-1.5.1:

WARN: postinst
Some software with pre-loaded PAM libraries might experience
warnings or failures related to missing symbols and/or versions
after any update. While unfortunate this is a limit of the
implementation of PAM and the software, and it requires you to
restart the software manually after the update.

You can get a list of such software running a command like
  lsof / | egrep -i 'del.*libpam\.so'

Alternatively, simply reboot your system.

When you update your system, a lot of packages might get updated, some of those might be actively in use and not ready to be restarted. Some of them simply don't need to be restarted at all until they naturally end up requiring it. Those were not specifically chosen to be updated; they were selected as part of the standard system update. You could certainly argue that a build-up of these running stale binaries puts the system in a more inconsistent state, but again why punish the user when there is no reason to.

The red colour distracts from the original intent the user might have of using htop, which may be the point, but I think giving users a choice is generally the preferred way to introduce changes such as this.

[BenBE]

I'm closing this discussion, as the initial question should be addressed.

If anyone feels like some point has yet been missed please feel free to open up appropriate tickets.