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.
DiffServ had a missing (underused) option
AckFilter &
FlowMode now use the nifty dashyenum thing
Bandwidth unlimited is all that we are using cake for today
Only FWmark left to go (which is in hex and I do not know how to
parse with and without the 0x prefix)
the match phase. Enum options have to replace minus with underscore.
E.g. `ack-filter` becomes `ack_filter`.
So you can do:
`string_table_enum!(DashingEnum, option_1, option2);`
And read `DashingEnum::from_str("option-1")`