TL;DR Why can't my Docker container read host topics? And why is sourcing behaving in strange ways?

I am trying to launch a Docker container on a host running ROS2 Foxy on Ubuntu 20.04 with the default-shipped DDS. The host has ROS nodes running that publish to topics and define services (duh). I want to subscribe to some of the topics and interact with some of the services. I ran into an issue with using host networking and shared memory, and it seemed to expose some oddities with the initial source /opt/ros/foxy/setup.bash command when I was troubleshooting. I want to be able to launch a simple docker container to read these topics over shared memory (so not UDP if possible as the containers are on the same host) and not break anything running on the host, and upgrading ROS to a newer distro is not feasible. Some non-breaking upgrades are possible if needed, but I don't know what I might need there. I'm looking for guidance which might help others too. Sorry if this gets long-winded, but I tried to make sure I looked under every rock I know before asking the community.

I ended up launching a vanilla ROS2 Foxy deployment on an EC2 instance to test the issues I am seeing, with the following permutations. I am using the unmodified osrf/ros:foxy-desktop docker image and the host is running the latest ROS2 foxy-desktop distro (installed yesterday when I was testing). All host publishers are the following:

# in a host terminal
source /opt/ros/foxy/setup.bash
ros2 topic pub /chatter std_msgs/String "data: Hello ROS Developers"

In each example, I start with fresh terminals and/or container runs, and sometimes I noticed I had to reboot the host.

Example 1: publishing a standard msg on /chatter from a host terminal, reading message from a subscriber on another host terminal

This works as expected, sourcing the secondary host terminal, then ros2 topic list and ros2 topic echo /chatter work as expected.

Example 2: publishing a standard msg on /chatter from a host terminal, reading message from a subscriber on a docker container terminal with network=host

My host terminal publishes messages, but I can't list the topics nor subscribe to them

Example 3: publishing a standard msg on /chatter from a host terminal, reading message from a subscriber on a docker container terminal with network=host after listing the topics from another host terminal

# in a second host terminal
source /opt/ros/foxy/setup.bash
ros2 topic list

If i execute this on a second host terminal before doing so on the container's terminal, I can then list ros topics on the container's terminal. I can event see all the topic metadata in the container with ros2 topic info /chatter --verbose, but I can't subscribe to the topic. It just waits for messages indefinitely though the second host terminal prints out the messages.

A secondary host terminal can read the messages just fine though.

Example 4: publishing a standard msg on /chatter from a host terminal, reading message from a subscriber on a docker container terminal with network=host and using shared memory by mapping --v /dev/shm:/dev/shm with the container launch

This doesn't work at all just like example 2.

Example 5: publishing a standard msg on /chatter from a host terminal, listing topic on a second host terminal, reading message from a subscriber on a docker container terminal with network=host and using shared memory as /dev/shm

In this case, I can list the topic and metadata, but I cannot read the topic once subscribed. Similar, if I go back to the second host terminal, it will list the topic but stall on subscribing. Weird! So now I have a primary host terminal publishing and a secondary host terminal and a container terminal that can both see the topic but cannot subscribe.

Example 6: publishing a standard msg on /chatter from a host terminal, listing topic on a second host terminal, reading message from a subscriber on a docker container terminal with network=host and using ipc=host

First, I had to reboot the machine because, event though all the terminals are newly created, I cannot list any topics in the subscriber terminals. It looks like source with shm lasts longer than the terminal session, which I didn't expect.

Once rebooted, then this behaves the same as mounting /dev/shm in examples 4 and 5

Example 7: publishing a standard msg on /chatter from a host terminal, reading message from a subscriber on a docker container terminal with network=host and using ipc=host without sourcing on the container terminal

Without rebooting, launching everything in brand new terminals, I can see the executable for ROS in the container terminal without executing source /opt/ros/foxy/setup.bash. which ros2 yields /opt/ros/foxy/bin/ros2 but I cannot see the topic when I execute ros2 topic list.

Similarly, in a secondary host terminal (brand new), I don't not have to source ros to see the executable, but I cannot list the topic.

Example 8: publishing a standard msg on /chatter from a host terminal, reading message from a subscriber on a secondary host terminal, then trying to read on a docker container terminal with network=host and using ipc=host without sourcing

In this example, my secondary host terminal will echo the messages on the topic, but my container will show the ros2 executable but not list out the topic.

Example 9: publishing a standard msg on /chatter from a host terminal, reading message from a subscriber on a docker container terminal with network=host and using shared memory (either /dev/shm mapping or ipc=host)and seeing RTSP transport errors

The original reason I started testing on a blank EC2 instance is that I was seeing this error with MANY other ports listed too (same as in this eProsima Fast-DDS github issue): [RTPS_TRANSPORT_SHM Error] Failed init_port fastrtps_port7415: open_and_lock_file failed -> Function open_port_internal [13645]

I was (sometimes) able to recreate this on EC2, but I couldn't reliably do that. Rebooting the host didn't seem to matter, and fastdds shm clean throws an AttributeException, even though it says it was fixed in this github issue.