The default total summar was the opposite of the table below,
and confusing.
Ideally the layout of the topmost bar should be:
LibreQos 'NOT CONNECTED' 'OTHER STATUS' 'down bps' 'up bps' 'pps' 'pps'
But my table-fu failed me.
By using the handy fmt macros this is feasible if the cell width
is known, via "{:>11}" for example.
However my intuitive thought that this was a "Constraint",
that you could apply to a Cell or Span, and it isn't. There are
multiple calls on the github for this. Until such a day, fmt
goes to 11.
Modern linuxes add fields all the time. On a kernel upgrade we
shouldn't crash just because there's a new json field.
Also there are some further optimizations to represent the kernel
structures themselves. Some fields can overflow which would lead
to some surprizing behaviors in polling the json over time.
FIXME - always check for overflow elsewhere, in packets, overlimits
etc. Could that be a trait?
On systems that support it, `jemallocator` will replace the default
allocator for `lqosd` and `lqos_node_manager`. The Jem allocator
is a LOT more friendly to Rust's preferred vector allocation patterns,
and actually cares about your cache.
Enable "fat" Link-Time Optimization. This slows down compilation a lot,
but results in smaller binaries and permits the LLVM optimizer to
cross crate boundaries when inlining, optimizing tail calls and a
few other optimizations.
FIXME: We need, in general, to check for wrapping in long term runs
* FIXME: Need a test to ensure fq_codel is still parsing
* Still want a size before and after test.
Lastly...
Newer versions of the kernel now have newer options for fq_codel
such as ce_threshold. The present implementation will spam the log
on encountering a newer kernel and tc.
Added a note for where `n_rows` gains the current terminal size.
`tui` turns out to consume the `Event::Resize` event, so it's
never received - instead, we have to calculate it from the
creation of the UI "chunks".
The rendering length turned out to be an artefact of forgetting
to remove a height constraint from a UI chunk that was tested
and never used. (It briefly contained some graph data).
* At any time, you can ask a BusClient if it is connected.
* If `lqtop` loses connectivity while running, it displays NOT
CONNECTED in red on the title bar.
* If `lqtop` can't reach the daemon on start, it bails out with
an error message.
The file locking is "smart": it checks to see if a lock is
valid before refusing to run (and updates the lock if
it can run anyway).
The locking mechanism will fail if you manually create
the lock file and dump random data into it that doesn't
readily convert to an i32.
Affects issue #54 and issue #52
* Add a new structure `FileLock` to `lqosd`.
* FileLock first checks /run/lqos/lqosd.lock. If it exists,
it opens it and attempts to read a PID from it. If that PID
is running and the associated name includes "lqosd", the
FileLock returns an error.
* If no lock exists, then a file is created in
/run/lqos/lqosd.lock containing the running PID.
* Includes Drop and signal termination support.
Since guarantying the execution of Drop traits on process
termination from signals is now "unsound" in the Rust specs,
provide an explicit clean-up path for `lqosd`, called when
a termination signal is processed. This removes the Unix
stream socket on termination.
* BusClient will survive creation without a successful connection.
* Attempting to use the BusClient without a connection will try to
connect.
* Attempts to use the BusClient are gated by timeouts and error
checking. Failures result in returning the client stream to
"None" - triggering a reconnect attempt on the next use.
* Client programs have added the Tokio "time" feature, needed for
timeout support.
* lqtop and lqos_node_manager have been tested to run without
lqosd started, and with stop/start cycles triggering resumption.
My largest desire in the data collection work so far is to be able
to compare "Saturday to Saturday, 8PM". There are always details
about given events that show up in the data, and the data gives
you details you might not have had at the time.
That "Replay" facility I started to describe is a means of doing that
from the historical data, although I kind of intended it to go up
against the bus. Also sampling rapidly some subset of devices all the
time, to compare against the longer period data, seems potentially useful.
Secondly, what is happening that we are *not* observing? When did it
start or end?
* Patch Tuesday
* DDOS attack
* Routing loop or broadcast storm
* Weather - a tower falls, how do you get in touch with the customer?
* New Counter Strike release (roughly the same as a DDOS)
So I added a filter for "Odd" - which is kind of fungible, and
"Log" to pull up a logbook from "somewhere" around that event.
An Odd filter could include "Silence" from week to week - why is this
device not online?
This is a draft attempt at working out what keystrokes and
functionality lqtop could gain for the beleaguered BOFH.
Presently functionality is stuck on:
* Capturing a screen resize event doesn't work
* Needing to be able to send a starting row to the bus
* More bus messages in general
* BOFH ignorance has to how to message the other thread
Refactor the get_nic_list function to use iterators with a collect
at the end, ensuring that the result vector is allocated at exactly
the needed size.
Dummy interfaces are commonly used to test stuff like this.
Most Linuxes do support them. A more advanced approach
Linux interfaces have a 15 character limit.
This implementation presently does not remove the created interface
and is a sterling example of how "side effects" in the OS itself
often need to be accounted for.
