This introduces the "dockerized" watchdog and monitored process example introduced in the Autoware workshop at IV 2020.
The choice of Docker for this example is because it facilitates use of cgroups (kernel control groups for resource allocation and isolation), and kernel namespaces for process isolation. The monitored entity can crash or be otherwise stopped/stalled and the Watchdog will respawn the entity.
This command brings up both the watchdog and the monitored application in two separate containers. See watchdog_in_docker.launch.py for details. Expect terminal output as follows after startup:
Manually interfere with the monitored application, for example via:
docker kill --signal=SIGINT talker
This will kill the monitored entity (called talker) and force the watchdog to restart it shortly after. In the original terminal, this restart activity will be reflected as follows:
This introduces the "dockerized" watchdog and monitored process example introduced in the Autoware workshop at IV 2020.
The choice of Docker for this example is because it facilitates use of cgroups (kernel control groups for resource allocation and isolation), and kernel namespaces for process isolation. The monitored entity can crash or be otherwise stopped/stalled and the Watchdog will respawn the entity.
To test the functionality in this PR:
Check out this branch and edit the included Dockerfile as follows:
This will make sure that the correct branch is used in the next step (as long as this PR is not merged to master yet).
watchdog_in_docker.launch.py
) via:This command brings up both the watchdog and the monitored application in two separate containers. See
watchdog_in_docker.launch.py
for details. Expect terminal output as follows after startup:This will kill the monitored entity (called
talker
) and force the watchdog to restart it shortly after. In the original terminal, this restart activity will be reflected as follows: