Skip to content

fix(webui): colour the process MEM% cell by memory_percent, not cpu_percent - #3699

Merged
nicolargo merged 1 commit into
nicolargo:developfrom
ntdatt812:fix/processlist-mem-alert-wrong-field
Aug 29, 2026
Merged

fix(webui): colour the process MEM% cell by memory_percent, not cpu_percent#3699
nicolargo merged 1 commit into
nicolargo:developfrom
ntdatt812:fix/processlist-mem-alert-wrong-field

Conversation

@ntdatt812

@ntdatt812 ntdatt812 commented Aug 27, 2026

Copy link
Copy Markdown
Contributor

The bug

plugin-processlist.vue decorates the MEM% column using the CPU% value:

getMemoryPercentAlert(process) {
    return GlancesHelper.getAlert("processlist", "processlist_mem_", process.cpu_percent);
}

The cell right next to it renders process.memory_percent, so in the most-looked-at table in Glances the number and its colour come from different fields. Both render paths — the flat list and the tree view — go through this one helper.

The curses UI gets it right:

def _get_process_curses_memory_percent(self, p, selected, args):
    msg = self.layout_stat['mem'].format(p['memory_percent'])
    alert = self.get_alert(p['memory_percent'], ..., header="mem")

What a user sees, with the shipped defaults

conf/glances.conf ships mem_careful/warning/critical = 50/70/90. Running the real getAlert from services.js against them:

a memory hog, idle CPU (cpu 0.3%, mem 94.2%)
   MEM% cell BEFORE: ok           <- 94% of RAM, no alert
   MEM% cell AFTER : critical

a busy loop, tiny RSS (cpu 99%, mem 0.4%)
   MEM% cell BEFORE: critical     <- red on a 0.4% footprint
   MEM% cell AFTER : ok

The process you'd open Glances to find — the one eating memory — is exactly the one that stays green, while a CPU-busy process with a negligible footprint is flagged instead.

Bundle

public/glances.js is rebuilt. A byte-offset diff is useless here because memory_percent is 3 bytes longer than cpu_percent, so everything after it shifts. Instead, undoing just that identifier in the rebuilt bundle:

const normalized = rebuilt.replace('processlist_mem_",t.memory_percent',
                                   'processlist_mem_",t.cpu_percent');
normalized === committed   // true

Byte-identical. So the rebuild carried nothing but this change, and the size delta is exactly +3.

Related

Same class of defect as #3698, which I opened for plugin-percpu.vue (the iowait cell coloured by system). They're independent files, so I kept them as separate PRs — merge order doesn't matter.

I checked every other GlancesHelper.getAlert call site in js/components/; these two were the only mismatches. plugin-raid.vue already mirrors RaidPlugin.raid_alert correctly.

@nicolargo

nicolargo commented Aug 29, 2026

Copy link
Copy Markdown
Owner

Hi @ntdatt812

all the lastest WebUI PR generate conflict on the glances.js file.

This file is generate dynamically during release. It should not be committed in PR.

Can you rework all previous PR ? You can also put all the PR in one big PR.

Nicolas

@ntdatt812
fix(webui): colour the process MEM% cell by memory_percent, not cpu_p…
8561516 
…ercent

getMemoryPercentAlert passed process.cpu_percent to the memory threshold
lookup, so the MEM% column in the process list was decorated from CPU
usage. The curses UI colours it correctly, from p['memory_percent'] with
header="mem", so the two UIs disagreed about the same process table.

With the shipped defaults (mem 50/70/90) a process holding 94% of RAM
while idle shows no alert, and a busy loop with a 0.4% footprint paints
its MEM% cell red. Both the list and the tree render path go through this
one helper.

Bundle rebuilt. Undoing just this identifier in the rebuilt public/glances.js
makes it byte-identical to the committed one, so nothing else rode along.
@ntdatt812
ntdatt812 force-pushed the fix/processlist-mem-alert-wrong-field branch from 4507109 to 8561516 Compare August 29, 2026 08:12
@ntdatt812

ntdatt812 commented Aug 29, 2026

Copy link
Copy Markdown
Contributor Author

Done, and thanks for saying it plainly. All five open WebUI PRs are rebased onto current develop and no longer touch glances/outputs/static/public/ at all:

PR file diff
#3695 plugin-ports.vue +7 / -7
#3696 plugin-amps.vue +10 / -12
#3697 plugin-vms.vue +15 / -1
#3698 plugin-percpu.vue +2 / -2
#3699 plugin-processlist.vue +1 / -1

One source file each, nothing generated. I rebuilt each branch from develop and re-applied only the .vue change, then checked the source diff hashes against the old tips to be sure the rework did not quietly alter a fix: all five are byte-identical to what you already reviewed. The bundle conflicts are gone with it, since that file is the only thing they collided on.

I saw 076469f land while I was doing this. Understood, and I have git checkout -- glances/outputs/static/public/ in my loop now. Sorry for the noise: I had been committing the rebuild so the change was testable straight from the branch, which was the wrong trade.

On merging them into one PR: happy either way. They are five unrelated one-line-class fixes in five different plugins, all of the same shape, each reading the wrong field for a colour, so as separate PRs you can drop any one of them without touching the rest. But if one PR is less work for you, say so and I will fold them into a single branch today.

This was referenced Aug 29, 2026
Merged
Merged
Merged
Merged
@nicolargo

nicolargo commented Aug 29, 2026

Copy link
Copy Markdown
Owner

Perfect @ntdatt812

Merged into develop, i will make some smoke tests on my side before generating the glances.js file.

Thanks for your work !

@nicolargo nicolargo added this to the Glances 4.5.7 milestone Aug 29, 2026
@nicolargo
nicolargo merged commit 10d5d5c into nicolargo:develop Aug 29, 2026
18 of 19 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

@ntdatt812 ntdatt812

Labels

webui

Projects

None yet

Milestone

Glances 4.5.7

Development

Successfully merging this pull request may close these issues.

2 participants

@ntdatt812 @nicolargo