search

clearpathrobotics / robot_upstart

ROS package of helper functions related to bringing up roslaunch on system startup.
BSD 3-Clause "New" or "Revised" License
196 stars 96 forks source link

Add a dependency onto network-online.target #67

Closed mhosmar-cpr closed 6 years ago

mhosmar-cpr commented 6 years ago

I Believe there should be a depend on networking. I think in all cases networking should be up before ROS. I added a After= and Wants= with networking-online.target to the systemd template. This has been tested on a few of our robots and it seems to be working well. While avoiding any awkward timer delays which I've seen in the past.

Downside to waiting on network-online.target is possibly delaying the service if networking is misconfigured (even if this is true there is a 90 second timeout). Waiting for network.taget may be safer.

NetworkTarget info

my systemd critical path:

ros.service @15.748s
`-network-online.target @15.747s
  `-network.target @15.735s
    `-ifup@br0.service @584ms
      `-apparmor.service @423ms +44ms
        `-local-fs.target @418ms
          `-boot-efi.mount @411ms +5ms
            `-systemd-fsck@dev-disk-by\x2duuid-EC37\x2dF774.service @382ms +27ms
              `-dev-disk-by\x2duuid-EC37\x2dF774.device @368ms
mikepurvis commented 6 years ago

Per systemd docs:

network-online.target is a target that actively waits until the nework is "up", where the definition of "up" is defined by the network management software. Usually it indicates a configured, routable IP address of some kind.

On the outdoor robots for which robot_upstart was originally conceived (Husky, Kingfisher/Heron), blocking ROS startup on network availability was not realistic— it needed to be possible for ROS to react to changing network conditions, for example recognizing dropped wifi and autonomously heading back toward shore until connection is reestablished.

In the Upstart days, we dealt with this by setting a static IP on the "service" network port, and tying the ROS startup to the bringup of that one port. It's not clear to me how a systemd-based system specifies the conditions which contribute to network-online.target.

mhosmar-cpr commented 6 years ago

I agree that network-online.target is ambiguous. I've changed to After=network.target. A more defined target. In the future we could depend on a specific interface using systemd-networkd-wait-online if systemd-networkd is used.

mikepurvis commented 6 years ago

Great, thanks!