Extract the six independent concerns of GlancesMain.init_plugins into
focused helpers (config-driven disabling, command-line enable/disable,
exporter activation, display defaults, processcount/processlist
coupling, default export process filter). No behavior change.
Cyclomatic complexity of init_plugins drops from 19 to 1 (radon); the
largest helper is at 9. Part of #3460.
The connections plugin gives up on a probe that fails: psutil.net_connections
raising, or the nf_conntrack files not being there. It records that by
writing net_connections_enabled / nf_conntrack_enabled into stats, but
update() starts every refresh with
stats = self.get_init_value()
which is a copy of stats_init_value, where both flags are True. The flag is
therefore forgotten as soon as it is written, and update() calls the failing
probe again on the next refresh. Measured with the conntrack path pointing at
a missing file and three refreshes: three reads and three
"Can not get network connections track" warnings, instead of one.
That also defeats the guard around psutil.net_connections, which is the
expensive call the plugin's own comment is about ("because it consumes lots
of CPU"), on a host where it raises, such as macOS without root.
Keep the two flags on the plugin, the way mem keeps zfs_enabled and sensors
keeps its probe state, and copy them into stats each refresh so the views and
the REST API still see them.
GlancesWebList takes web_x_ssl_verify through config.get_value(), which
returns the raw string, and hands it to requests.head(verify=...).
Requests reads a string verify as the path to a CA bundle, so the value
from the configuration file is looked up as a file name:
verify='false' -> OSError: Could not find a suitable TLS CA
verify='true' -> OSError: ... invalid path: true
verify=False / verify=True -> the request is actually made
ThreadScanner._web_scan catches everything and sets status='Error', so the
URL sits permanently red in the curses view and the WebUI, with only a
debug-level log line to explain it. Setting the key to true, which is what
a user does to turn verification back on explicitly, breaks the scan the
same way as false.
Read it with config.get_bool_value(), the helper the network and diskio
plugins already use for their switches, and keep a non-boolean value as a
string: a path to a CA bundle is a valid value for requests' verify, and
that is the one form that worked before.
The key was undocumented, which is probably how this survived; document it
next to the other web_x_ options in conf/glances.conf and docs/aoa/ports.rst.
_GlancesCurses.load_config read [outputs] separator and disable_bg with the
command-line value passed in as the default, so any value present in the
file won: with separator=True in glances.conf, `glances --disable-separator`
still drew the separator, and so did --disable-unicode, undoing main.py's
"Unicode => No separator". With disable_bg=False in the file, --disable-bg
was ignored. docs/config.rst says options given on the command line
override the configuration files.
Both flags only move one way -- --disable-separator can only turn the
separator off and --disable-bg can only turn the background off -- so keep
the value when the flag is set and let the file decide otherwise. With no
flag, or with the key absent, the result is unchanged.
get_conf_value(convert_bool=True) returned bool(ret[0]). load_limits stores
a non-numeric value as a one-item list of strings, so the documented
off switch
[processlist]
disable_virtual_memory=False
came back as bool('False') == True and hid the VIRT column in the curses
UI -- while the WebUI, reading the same key, compares the text to "true"
and shows it. A value that parses as a number is stored as a float
instead, so disable_virtual_memory=0 or =1 raised TypeError on ret[0].
Read the text the way the *_log check a few lines above and the WebUI
already do, and take bool() of a float.
GlancesFilterList.filter appended to the existing list, so the property
never described the current filter: every assignment added to whatever was
already there. Its sibling in the same file, GlancesFilter.filter, replaces.
Both process_focus and export_process_filter are written twice in a normal
startup. The processlist plugin reads glances.conf when it loads
(plugins/processlist/__init__.py), and the command line is applied just
after -- set_args() for the focus filter, standalone.py for the export one.
Appending left both live, and is_filtered() ORs them, so
focus=.*firefox.* in glances.conf
glances --process-focus .*python.*
focused on firefox and python together. The command line could widen the
list from the configuration file but never narrow it, while config.rst
states that "options given on the command line overrides both".
Assigning the whole list restores that precedence: the configuration file
is read first, the command line replaces it.
hide_zero is decided per field but applied per row, and the two front ends
read that per-field verdict in opposite directions.
msg_curse drops a disk only when *all* of its hide_zero_fields are hidden:
if all(self.get_views(item=..., key=f, option='hidden') for f in self.hide_zero_fields):
continue
plugin-diskio.vue and plugin-network.vue keep a row only when *all* of them
are visible:
return (
(!readBytesRate || readBytesRate.hidden === false) &&
(!writeBytesRate || writeBytesRate.hidden === false)
);
Those agree while both fields say the same thing, and disagree the moment
one moves and the other does not -- a disk that has only ever been read, an
interface that has only ever received. Curses shows it; the browser drops
it entirely.
Use the same rule as msg_curse in both components.
Both the reference configuration and docs/aoa/network.rst offer the option
under [network]:
[network]
hide_zero=True
hide_threshold_bytes=0
but NetworkPlugin never read it, so it stayed at the base class default of
0 whatever the user wrote. diskio has read it since the option was added;
network was left out.
Nothing reports an option a plugin ignores: hide_zero keeps working, it
just never applies the threshold, so an interface carrying a trickle of
background traffic is shown when the user asked for it to be hidden.
Read it beside hide_zero, exactly as diskio does.
The reference configuration documents the boundary for both plugins that
use the feature:
# Set hide_threshold_bytes to an integer value to automatically hide
# interface with traffic less or equal than this value
#hide_threshold_bytes=0
"less or equal than this value", with a documented default of 0, means a
rate of exactly 0 is hidden. The comparison un-hid on `>=` instead, so at
the default threshold every zero rate satisfied `0 >= 0` and the row came
straight back.
The first refresh still hides, because it has no previous view to carry
forward and falls into the `else` branch. From the second refresh on,
nothing was ever hidden again -- which is why `hide_zero=True` looked like
it worked for one frame and then stopped.
This restores the behaviour that `i[field] != 0` had before the threshold
option was introduced, and honours a non-zero threshold the way the
configuration file describes it.
Tests pin the boundary rather than any rendered message: the views dict
keeps every key either way, only `hidden` moves.
The containers plugin decorates each container's cpu and mem against that
container's own threshold from the config file, falling back to the global
one. The curses view reads both. plugin-containers.vue did not: it rendered
the two cells as plain text in both its narrow and wide tables, so a
container over its limit was red in the terminal and black in the browser.
The component already exposes the views it needs -- it uses them for
show_engine_name and show_pod_name -- so this only adds the reader and the
two class bindings, defensive the same way plugin-diskio.vue is for a
container present in stats but not yet in views.
The added test pins the server half of the pair: without it, removing the
decoration upstream would take the colour out of both front ends silently,
since get_views() answers DEFAULT for a key it cannot find.
The VM table asks for a decoration on four columns:
self.get_views(item=vm['name'], key='cpu_count', option='decoration')
self.get_views(item=vm['name'], key='cpu_time_rate_per_sec', ...)
self.get_views(item=vm['name'], key='memory_usage', ...)
self.get_views(item=vm['name'], key='load_1min', ...)
Nothing ever set one. No vms field declares `alert` or `log`, so the base
`_build_field_decoration` returns 'DEFAULT' for all of them, and
`update_views` only computed `show_engine_name`. Every one of those four
reads has always come back 'DEFAULT', which makes the VM table the one
table that never changes colour -- the sibling containers plugin has done
this since it was written.
Three of the four get thresholds, with the per-VM override and DEFAULT
fallback containers already uses. `cpu_count` keeps its read and no
colour: a core count is not a threshold.
Decorations are written onto the views the base already built rather than
replacing them, so `optional` and `hidden` survive -- containers replaces
the whole per-item view, which is why its curses code reads nested 'cpu'
and 'mem' keys instead of field names.
Thresholds are commented out in the shipped conf, so the table stays
exactly as it is until someone opts in.
Verified with tests/test_vms_decorations.py (9 passed) and by reverting
each claim: measuring memory against a fixed maximum instead of the VM's
own memory_total fails 4 tests, dropping the per-VM override fails 1.
A `value is None` guard was written first and removed: `get_alert` already
answers DEFAULT for a missing value, because the percentage it computes
raises TypeError and is caught, so no test could tell the guard from its
absence. A test pins that behaviour instead.
compute_rate_on_list() looked up each stat's previous sample by key and
skipped the stat entirely when there was none. Interfaces, disks and VMs
appear while Glances is running -- a VPN comes up, a container starts, a
disk is plugged in -- so a stat with no previous sample is not only a
start-up case, and the plugins that carry rate fields on a list are
network, diskio and vms.
A skipped stat kept the raw psutil counter in the delta field and got no
_gauge, no _rate_per_sec and no time_since_update at all. Two consequences:
* That refresh published the whole since-boot total as if it were one
refresh of traffic. On a quiet link the first sample of a new
interface reads in gigabytes.
* NetworkPlugin.update_views() assigns
views/<iface>/bytes_recv_rate_per_sec directly. Views are built only
from the fields a stat actually carries, so there was no view to
decorate and the refresh raised KeyError: 'bytes_recv_rate_per_sec'.
Give compute_rate an empty previous instead of skipping, which is the
path a dict stat already takes on its own first sample: record the gauge,
publish a rate of 0, and measure a real delta on the next sample. The
stat then also reaches its second sample one refresh sooner, because the
gauge it needs is now recorded the moment it appears.
Verified on Windows with the full suite: the set of failing test names is
byte-identical before and after (63 pre-existing environment failures,
xmlrpc and browser-restful servers). Reverting the one changed line turns
4 of the 5 new tests red, including the KeyError one; the fifth is the
guard that the neighbouring stat is undisturbed, so it stays green.
update_views() replaced the base class's per-field views with a dict naming
only load, freq and mem, so views[npu_id]['temperature'] did not exist. Both
readers then fell back to no style: msg_curse's get_views() returns 'DEFAULT'
for a missing key, and the WebUI's getDecoration returns undefined. An Intel
NPU -- the one driver that reports the reading -- was printed plain at any
temperature.
Adds the key and the alert, mirroring the GPU plugin, which has had the same
three alerts (proc/mem/temperature) all along. A card whose driver leaves the
reading None (AMD, Rockchip) keeps a view with no decoration rather than being
alerted on nothing.
conf/glances.conf gains the matching [npu] temperature thresholds, using the
same 60/70/80 ladder as [gpu]: without limits get_alert() returns DEFAULT, so
the code half alone would change nothing.
The Rps cell prints `disk.bitrate.txps` and took the decoration of
`write_bytes_rate_per_sec`; the Wps cell prints `rxps` and took
`read_bytes_rate_per_sec`. `disks()` fills txps from read_bytes_rate_per_sec
and rxps from write_bytes_rate_per_sec, so the two columns wore each other's
alert. The latency pair is crossed the same way.
update_views() gives the two directions separate alerts (`rx`/`tx` headers,
and `rx_latency`/`tx_latency`), so a disk saturated by reads lit up the write
column and left the read one plain. The curses UI already pairs each value
with its own field.
Also names the txps/rxps trap in the one place it is introduced.
Both interfaces drew every per-core bar with the aggregate CPU style:
`_msg_create_line` read `views['cpu']['decoration']` for every row, and
plugin-quicklook.vue called `getDecoration('cpu')` inside the percpu loop.
A core pegged at 100% among idle ones was therefore painted with the colour
of the average, which is the one number that cannot show it.
update_views now publishes `views['percpu_decoration']`: a style per core,
plus 'other' for the row that averages the cores neither interface shows.
Both interfaces read it, so they agree.
The styles are computed from the plugin's own quicklook_cpu_* limits rather
than through get_alert(), because get_alert() also records a threshold that
glances.events_list reads and can run a configured action, and both are keyed
by the stat name alone. Every core shares 'quicklook_cpu' with the aggregate,
so a per-core call would leave the last core as the value those two see.
Also drops a duplicated `msg = msg =` assignment on a line already touched.
TerserWebpackPlugin was instantiated in the `plugins` array while
`optimization.minimizer` was left at its default, so two JS minimizers
were registered on every production build. Whichever tapped first
marked the assets `minimized`, silently disabling the other.
Since webpack 5.110 the default minimizer is minimizer-webpack-plugin,
and getClaimedAssetTypes() only lets a user plugin claim css/html --
never js -- so webpack always races the config for JS assets. The
default minimizer extracts license comments, so had the race flipped on
a future webpack bump, `extractComments: false` would have been lost and
public/*.LICENSE.txt files would have reappeared.
Setting optimization.minimizer replaces webpack's default instead of
competing with it: one minimizer, outcome no longer dependent on tap
order. Verified 2 -> 1 TerserPlugin taps in the build trace.
The `isProd` guard is no longer needed: optimization.minimize already
defaults to `production`, so the minimizer never runs in development
(checked: dev build stays unminified with eval-source-map).
Emitted bundles are byte-identical before and after (same sha256 for
glances.js and browser.js), hence no rebuilt assets in this commit.
webpack.config.js requires terser-webpack-plugin, but the package was
never declared in package.json. It only resolved through npm hoisting,
because webpack itself depended on it up to 5.107.2.
webpack 5.110.3 replaced that internal dependency with
minimizer-webpack-plugin, so the phantom dependency disappeared from
node_modules and `make webui` failed before the build even started:
Cannot find module 'terser-webpack-plugin'
at Object.<anonymous> (glances/outputs/static/webpack.config.js:5:29)
Declare it in devDependencies so the config no longer depends on
another package's transitive dependency tree.
Also includes the JS dependency bumps from `make webui-update` and the
regenerated bundles.
get_ip_address() returned the address of the first up, non-loopback
interface psutil happened to enumerate. On hosts running Docker, VMware,
libvirt or similar, a virtual bridge (docker0, vmnet8, br-*...) can occupy
that position and silently win, so the IP plugin reports a bridge address
as the primary IP. Which interface wins depends on interface creation
order, so the symptom can appear after something as routine as a
NetworkManager restart recreating a bond.
Instead, ask the OS routing table which source address it would use for
default-route traffic: connect() on a SOCK_DGRAM socket resolves the route
without sending any packet, honouring metrics, policy routing and
per-route source hints, and works on every platform Glances supports. The
probe address is from the documentation range (RFC 5737 / RFC 3849) and is
never contacted. A loopback or unspecified probe result (hosts that
locally blackhole bogon ranges) is rejected. The previous interface scan
is kept as the fallback, and the existing tests now pin exactly that
fallback behaviour.
This also improves servers_list_dynamic.py, which uses get_ip_address()
for the zeroconf bind address and could previously announce a virtual
bridge address to LAN peers.
Verified on a host with 22 interfaces (bond, 3 docker bridges, 2 vmware
vmnets, 10 veths): returns the bond address for IPv4 and the global
address for IPv6, independent of enumeration order.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
nicolargo