[systemd-devel] network/openvswitch dependency loop/deadlock

[Ian Pilcher]

On 02/07/2013 06:13 AM, Colin Guthrie wrote:
> 'Twas brillig, and Ian Pilcher at 06/02/13 22:27 did gyre and gimble:
>> * systemd sees "Before=... network.target" in openvswitch.service and
>>   waits for the network service to complete -- which will never happen,
>>   because the network service is waiting for the openvswitch servicr to
>>   start.
>>
>> * DEADLOCK!
> 
> This last step shouldn't (in theory) be a problem as far as I understand
> it. Before=network.target doesn't imply it that has to wait for
> network.service to complete - it should only imply that both
> network.service and openvswitch.service are both have to start before
> network.target is considered reached. If it said After=network.target
> then I would see an obvious deadlock, but with both saying Before= they
> should be able to work fine.

Well it would help if my brain worked a bit better.  openvswitch.service
does, in fact, contain:

  After=syslog.target network.target

So there's the "obvious deadlock".

>> Assuming that the answer is yes, what is the best way to work around
>> this?
>>
>> * Removing network.target from the Before=... line in
>>   openvswitch.service is not an option.  See comment #1 of that bug.
>>
>> * Changing the network startup script (ifup-ovs) to use "systemctl
>>   --ignore-dependencies start openvswitch.service" appears to work, but
>>   the man page discourages its use for anything but debugging.
> 
> Depending on how the daemon is used, it might make more sense to use
> --no-block. This will return control to the command line straight away,
> but obviously the daemon may not be "ready" for communications yet and
> the script may fail.

--no-block is not going to be an option.  The script is trying to bring
up an Open vSwitch bridge, and it can't do so without a running daemon.

> I'm not familiar with the daemon or what it does and how any IPC may
> work (i.e. how you talk to the daemon).

The script uses ovs-vsctl to talk to ovs-vswitchd.

> I get the feeling I'm perhaps misinterpreting something. I think the
> real reason for the deadlock would be good to track down. It could be
> that it is being artificially held back from completing or some other
> dep is causing the problem.

You made the mistake of believing what I wrote.

> Also re the initscripts tweaks and the if statement proposed in the bug,
> there is a SYSTEMCTL_IGNORE_DEPENDENCIES=1 env var you can export that
> will make "service openvswitch start" pass the --ignore-dependencies
> argument if it redirects to systemctl. That's likely cleaner than the if
> [ -x /usr/bin/systemctl ] check. Obviously as this is arguably not the
> right fix anyway, it's perhaps a moot point.

Cool.

So given that it is in fact "After=... network.target" (in
openvswitch.service) that is causing the problem, do you see a better
solution than using SYSTEMCTL_IGNORE_DEPENDENCIES?

Is there any chance that this would work?

  After=syslog.target
  Requires=network.target

(While not breaking the use case in comment #34 of the bug.)

I'm very unclear on what Requires=network.target would actually mean.

Thanks for your help, and sorry about the brain-cramp!

-- 
========================================================================
Ian Pilcher                                         arequipeno at gmail.com
Sometimes there's nothing left to do but crash and burn...or die trying.
========================================================================