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.
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 - #3 by ijohnson. That didn’t seem to change anything, however.
I opened an issue to track this Snap access to shared memory not allowed · Issue #65 · micro-ROS/micro-ROS-Agent · GitHub.
@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.
I am closing this request for now. If we get news from upstream, we can re open it if needed. Thanks!