Request for system-files: micro-ros-agent-arnatious

snap: https://snapcraft.io/micro-ros-agent-arnatious

Snap is a mirror of micro-ros-agent in order to produce an arm64 release, needed for a Core demo by the Ubuntu robotics team.

@arnatious can you please detail what files are needed to be accessed via system-files and for what purpose? Thanks.

Per upstream - it seems to have to do with netplug: https://github.com/micro-ROS/micro-ROS-Agent/blob/foxy/snap/snapcraft.yaml#L150.

I can’t find the original request for https://snapcraft.io/micro-ros-agent where the vendor originally sought approval to verify.

Ok. For future reference, what I was hoping was that you would say something like:

Request system-files access for write access to /dev/shm named micro-ros-agent-shm-netplug as the micro-ros agent request access to this for …

So the bit I don’t understand is the … - can you elaborate on why?

Also I notice that the micro-ros-agent snap in the store does not have this granted for it currently. Are you certain this is definitely needed?

Gotcha:

Request system-files access for write access to /dev/shm named micro-ros-agent-shm-netplug as the snap requires access to shared memory for the copy-less DDS implementation.

Attempting to run without access to shm produces the following error

2021-05-27 16:35:39.477 [RTPS_TRANSPORT_SHM Error] Failed to create segment 2fa1addd5b3223e0: Permission denied -> Function compute_per_allocation_extra_size

This is part of a recent ROS 2 update moving to a shared memory DDS(RTPS) implementation.

Thanks, so after looking at things a bit more I see the base policy for snaps allows the use of /dev/shm/snap.$SNAP_NAME.* - so would it be possible to adjust your snap to use a path such as /dev/shm/micro-ros-agent-arnatious.whatever instead? See Shared memory in /dev/shm rewriting for more details.

Since I’d rather not deviate from upstream (nor am I familiar with the package’s codebase enough to modify it), I looked into Help creating a strict snap that uses shared memory and Bashtop Linux resource monitor. That didn’t seem to change anything, however.

I opened an issue to track this https://github.com/micro-ROS/micro-ROS-Agent/issues/65.

@arnatious Just wondering if you were able to get this working?

@alexmurray no I could not, unfortunately. There appears to be a new snapcraft-preloads repo that is actively developed, but it does not advertise any fixes for shared memory. I’ve left an issue upstream and hopefully they’ll get around to investigating it themselves.