(missing) pre-up and pre-down

[Marc Herbert <Marc Herbert gmail com>]

Dan Williams a écrit :
> 
> There are two reasons I've not yet added pre-up and pre-down.  They are:
> 
> 2) appropriateness

Hmmm, the good old "just do not do this" answer... the best answer to
any feature request ever ;-) Especially to people having using this
feature for ages and being suddendly deprived of it.


>     b) by the time any pre-down script will run, often the connection
> has already gone away (the AP is out of range, the cable has been
> unplugged already, etc) so any operation a pre-down script does *cannot*
> depend on the interface being up; it must gracefully fail.  Common
> things people wanted to do here were unmount network shares;
> but since the script must always handle unexpected disconnects (which
> not all network file systems do well), you might as well just run this
> from post-down anyway.

I think "pre-down" cleanup scripts could (should?) simply NOT be run on
unexpected disconnects (as opposed to explicit disconnection
requests). Simply because they are called PRE-down, not AT-down.



> Basically, allowing arbitrary "pre-up" and "pre-down" scripts opens the
> door to more bug reports and requires more diagnostics when stuff goes
> wrong.  Thus, the requirement to *do it right* and ensure that when
> somebody writes these scripts incorrectly, that the user does not suffer
> the consequences, and that the guilty party (the script) is correctly
> identified.
> 
> And, as always happens with timeouts, somebody will inevitably ask for
> the timeout to be extended because "my use-case just takes a second
> longer" without thinking about the actual impact of their request for
> everyone else (ex DHCP timeouts), and without fixing the actual root
> cause why they need a longer timeout.  That means yet more time spent
> writing mails and replying to bug reports.

This looks like a storm in a teacup... there is an infinitely simpler
solution: just blame the actual culprit. Implement pre-up and pre-down without
any parallel execution nor timeouts, not anything complicated. Dead
simple, except for this: when any script hangs for more than one
seconds, just hang with it, and print its name prefixed with "ERROR
FROM:" capital letters all over the place: in the logs, in pop-ups,
etc. Then trust me, not you but the author of this script will receive
the bug reports and the angry emails.

And to even further reduce the chance to receive bug reports you can
also make this "pre-" feature disabled by default and flag it (again) as
"experimental" in the logs every time NM starts with it explicitely
enabled.

Then you can always plan to implement fancy parallel execution and
configurable timeouts later in the long term, but at least knowledgeable
people recently deprived of pre-up and pre-down have another solution
than dumping NetworkManager and using something else (which admittedly
does reduce the amount of feedback you get...)


By the way, speaking of reducing the flow of bug reports and angry
emails, the current approach of not providing the full set of features
and transparency of the tools NM is meant to replace does not seem to
work very well either :-) The distributions are probably more to blame
than NM on this (by rushing things through the door as they usually do),
but well, it seems the angriness unfortunately trickles down here,
doesn't it?


Cheers,

Marc