High
- config: an unreadable or unparsable glances.conf stops Glances (exit 2)
instead of being skipped (v4 parity)
- ip: public API address policy enforced on the connection itself
(redirects, re-resolution), shared address space rejected, credentials
dropped on cross-origin redirects
Medium
- network: per-direction capacity is the full link speed (no /2)
- quicklook: GPU means read the gpu collection envelope
- mcp: top_processes_report accepts the collection envelope
- webserver/routes: password hashing off the event loop
- actions: no relaunch while a run is in flight, dedicated pool,
optional [alerts] action_timeout
- alerts: vanished items resolve through hysteresis and are forgotten
- processlist: NI on 3 columns, integers never truncated
- tui: full-quicklook width leaves room for LOAD, percpu keeps its labels
when the cascade hides quicklook, control characters painted as spaces
- fs: show/hide also match the device name
- webui: memswap/load without stats render dashes, quicklook bars keep a
width without the CPU header, percpu twin of the quicklook rule
Low
- non-ASCII Basic auth username returns 401
- DNS rebinding warning follows --bind
- CSV export realigns reordered columns instead of rotating
- a failed cycle no longer doubles the next rate
- sensors <label>_<type> alias restored
- programs view NI formatting, Windows dpc in TUI and WebUI
- network rates 1000-1023 K/M/G fit their column
- webui footer shows resolutions as resolved, header cascade runs
before text is cropped
- webpack dev server port parsed as a number
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.
nicolargo