Bug #10589

NetworkManager hooks are unreliable vs network interruptions

Added by anonym 2015-11-19 14:16:54 . Updated 2015-11-19 14:16:54 .

Status:
Confirmed
Priority:
Normal
Assignee:
Category:
Target version:
Start date:
2015-11-19
Due date:
% Done:

0%

Feature Branch:
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

Sorry for the bad ticket subject — feel free to come up with a better one and remove this sentence from the description!

The gist of the problem is that the NM hooks are put in the dispatcher’s queue upon the events it reacts to (up, down etc) and never removed except if the script exits. Hence NetworkManager can have stray hooks from previous connections: let’s say we have NM hooks X, Y, Z on “interface up”. We connect to some network and hook X runs and exits, and Y is running, and it runs for a “semi-long” time; we suddenly disconnect before Y exits. Then we connect again. Because of the strictly queue-like behaviour of the NM hook dispatcher the hooks that it wants to run are, in order Y (still waiting for it to finish), Z, X, Y, Z.

This can be problematic (e.g. due to 10-tor.sh Tor will start, and then *re*start) and probably extremely racy.

Converting all the hooks to systemd unit files is the proper solution.


Subtasks


Related issues

Blocked by Tails - Feature #7545: Convert manually ordered system initialization bits to native systemd unit files Confirmed 2014-11-27

History

#1 Updated by anonym 2015-11-19 14:17:20

  • blocked by Feature #7545: Convert manually ordered system initialization bits to native systemd unit files added