ufw upstart job is stopped on runlevel 1 but not started back up on transition from 1 to 2

[Clint Byrum]

The ufw.conf job specifically stops on runlevel [!062345] meaning it will be killed on the runlevel 1 transition. However, the start on condition does not happen again when transitioning from 1 to 2.

[Jamie Strandboge (jdstrand)]

Currently ufw.conf has:
# Make sure we start before an interface receives traffic
start on (starting network-interface
          or starting network-manager
          or starting networking)

stop on runlevel [!023456]

Are you saying this should be changed to:
# Make sure we start before an interface receives traffic
start on (starting network-interface
          or starting network-manager
          or starting networking
          or runlevel [023456])

stop on runlevel [!023456]

Is this expected to work correctly? It is important that ufw start before any network interfaces come up in normal booting.

[Clint Byrum (clint-fewbar)]

Yes, that should work fine since all of those things will emit their "starting" even before runlevel [2345]. Note that 0 and 6 wouldn't make sense, so I wouldn't include them.

If you want to make absolutely sure it only happens on a resurrection from runlevel 1, you can do it as

start on (starting network-interface
          or starting network-manager
          or starting networking
          or runlevel RUNLEVEL=[2345] PREVLEVEL=1)

I have not tested that syntax, but it should work.

Note that eventually we will need to fix runlevel 1 to actually stop networking and all the network interfaces as well... so when we do that we'll have to revisit both the stop on and the start on.

[Jamie Strandboge (jdstrand)]

Hmmm, this doesn't actually work if I telinit to 1 then back to 2. Presumably because one of the previous conditions is met. If I just use 'or runlevel RUNLEVEL=[2345]' it seems to go into some sort of a loop as the machine hangs when I use 'telinit 1'. I have not debugged this further.

[Clint Byrum (clint-fewbar)]

Perhaps the right thing to do in this case (I think you're hitting the bug where complex start on conditions deadlock) is to change the stop-on to 'stop on deconfiguring-networking', which happens later in the shutdown and does not happen on transition to runlevel 1. That event is used to stop things that need to be around until networking goes down for good, one of which is dbus.

[Jamie Strandboge (jdstrand)]

Ubuntu (and ufw) now use systemd. Marking as Won't Fix.