Project

General

Profile

Bug #10589

NetworkManager hooks are unreliable vs network interruptions

Added by anonym about 4 years ago.

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

0%

Feature Branch:
Type of work:
Code
Blueprint:
Starter:
Affected tool:

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.


Related issues

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

History

#1 Updated by anonym about 4 years ago

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

Also available in: Atom PDF