Failing gracefully on errors

[tohojo]

Currently we mostly don't check commands for errors. We probably should,
and then fail gracefully if something critical fails...

This includes in particular insmod, (see #3), but also other things like
iptables setup and chains of tc commands...

[moeller0]

I would say there is no real graceful way of failing, except maybe tearing down everything, but then we risk touching stuff set-up independent of sqm-scripts (not nice).

[moeller0]

Hi Toke,

I am thinking about taking inspiration from luci's diagnostics page and display the output of "logread | grep -e SQM" (as first approximation, we can also modify sqm_logger to dump all messages into a temporarily file and just display that) in an output pane somewhere on the first sqm tab (details might contain traces of devil, as always). That way we can pipe a lot of information and diagnostics back to the user, if we just end with a noticeable "THIS SQM INVOCATION WORKED LIKE A CHARME" or so we can even signal success back to the user (and probably also the lack of success by other means).
If that works we can also signal back information about errors and potential remedies to the user, which is a first step in failing moire gracefully ;)

[tohojo]

I am thinking about taking inspiration from luci's diagnostics page and display the output of "logread | grep -e SQM" (as first approximation, we can also modify sqm_logger to dump all messages into a temporarily file and just display that) in an output pane somewhere on the first sqm tab (details might contain traces of devil, as always). That way we can pipe a lot of information and diagnostics back to the user, if we just end with a noticeable "THIS SQM INVOCATION WORKED LIKE A CHARME" or so we can even signal success back to the user (and probably also the lack of success by other means). If that works we can also signal back information about errors and potential remedies to the user, which is a first step in failing moire gracefully ;)

This sound reasonable; let's see how it turns out in practice :)

…

-Toke

[moeller0]

Hi Toke,

On Aug 26, 2015, at 18:53 , Toke H�iland-J�rgensen notifications@github.com wrote:

I am thinking about taking inspiration from luci's diagnostics page and display
the output of "logread | grep -e SQM" (as first approximation, we can also
modify sqm_logger to dump all messages into a temporarily file and just display
that) in an output pane somewhere on the first sqm tab (details might contain
traces of devil, as always). That way we can pipe a lot of information and
diagnostics back to the user, if we just end with a noticeable "THIS SQM
INVOCATION WORKED LIKE A CHARME" or so we can even signal success back to the
user (and probably also the lack of success by other means).
If that works we can also signal back information about errors and potential
remedies to the user, which is a first step in failing moire gracefully ;)

This sound reasonable; let's see how it turns out in practice :)

Yeah the proof is in the pudding ;) I will play with this, but first I need to do a bit more research into offloads and how to disable them; so the better diagnostics is a mor along term project from my perspective� (I wanted your opinion, since if you had something better/else planned no need to spend time)

Best Regards
Sebastian

-Toke
�
Reply to this email directly or view it on GitHub.

[EricLuehrsen]

What if you exported the interface or pseudo-interface that you will build the shaper and qdisc on? Write to two tmpfs files /var/lib/sqm/iface.default and /var/lib/sqm/iface.state to allow complete rewind. In boot() delete both files. Before the first time you actually work on an interface write ~~.default and later write/rewrite ~~.state as you go. Then if SQM is ever restarted out of context or fails in the middle, a cleanup() routine can be called to rewind the changes.