17 thoughts on - Systemd Spends 6 Min. To Startup A Host

• Please, any idea how to fix this??

• Sound like your modifications messed something with network configuration?

• I think you misunderstand: systemd has a dependency management between services, that could make the boot faster. Speeding up the boot was not the goal, it’s an effect.

• This looks like modifications broke network configuration and it may affect startup speed.

  Please try standard network configuration first.

• Are you referring to use NetworkManager?? I can’t. I need to use openvswitches in this host …

• What’s the output of “systemd-analyze blame”?

• Em 03-10-2015 13:47, C.L. Martinez escreveu:

  While booting it, if you get out of the plymouth screen (press esc), you should be able to see a message like
  ‘Waiting for …’
  that should give you a direction already.

  Marcelo

• just to see if thats the problem, remove openvswitches from your config, and if it boots fast, then you know the delay is related to that.

• https://www.google.com/search?q=systemd+lsb+raise+network&ie=utf-8&oe=utf-8

  If your problem is similar to the first few google hits, then some part of your configuration is probably calling “service something restart” or
  “systemctl restart something”. The service being restarted requires network.target to be available, which only happens after the interfaces are all up, which is a deadlock condition.

  If you provide all of the configuration files you edited to enable openvswitch, we might be able to give you more specific advice. Your original question was quite vague.

• Nop, there is no errors … Only the delay message …

• Uhmm … but I need to startup openvswitches at boot … I only see one option: start openvswitches when libvirtd starts …

• Yes, my problem is very similar as described in Debian’s bugtracker. Ok, here is my openvswitches config:

  DEVICE=dmzprif DEVICETYPE=ovs TYPE=OVSBridge STP=off ONBOOT=yes

  DEVICE=encif DEVICETYPE=ovs TYPE=OVSBridge STP=off ONBOOT=yes

  DEVICE=prodif DEVICETYPE=ovs TYPE=OVSBridge STP=off IPADDR2.22.55.1
  NETMASK%5.255.255.240
  GATEWAY2.22.55.14
  ONBOOT=yes

  DEVICE=vpnif DEVICETYPE=ovs TYPE=OVSBridge STP=off ONBOOT=yes

  … and nics attached to some of these openvswitches:

  DEVICE=eth0
  OVS_BRIDGE=pubif DEVICETYPE=ovs TYPE=OVSPort ONBOOT=yes

  DEVICE=eth1
  OVS_BRIDGE=prodif DEVICETYPE=ovs TYPE=OVSPort ONBOOT=yes

  …

• my suggestion was to help isolate the cause of this boot delay. if removing the openvswitch from your network configuration took out the delay, then you’d KNOW thats the problem, and you could work to further isolate why. if that didn’t take out the delay, then the delay is somewhere else. telling me you need openvswitch isn’t helping.

• Ok, removed all openvswitches and it boots more fast, but message about LSB tasks continues …

  Arrived to this point, I am pretty sure I have a problem using old nic config … If I disable all nics configs, voila!! … Server boots ok.

  Ok, all problems are reduced to nic settings.

  The only option I see is to start openvswitches from libvirtd, but what about ethX configs??

• The problem might be a bug. Ask the openvswitch people.

  It looks like the problem is probably:
  /etc/sysconfig/network-scripts/ifup-ovs calls “systemctl start openvswitch-nonetwork.service”
  openvswitch-nonetwork.service “Wants” openvswitch.service openvswitch.service is “After” network.target network.target is the one that called ifup-ovs

  So there’s a deadlock.

  At least, that’s the best I can figure from looking at it briefly.

• Thanks Gordon. I think the same: it is a bug (another one with systemd).

  I will do what I am thinking previously: I will start openvswitches from libvirtd and I will see how it goes.

  Thanks.

• It’s not a systemd bug. If I’m correct, it’s a bug in the openvswitch init scripts. It’s simply wrong for a component of the network startup to tell systemd that it needs to start after the network service is up.