Snapcraft-preload and /dev/shm access

I have a few precompiled dynamic lib plugins that fail to load in my snap due to failure to shm_open due to the well-documented sandboxing of /dev/shm. Most of the threads about this topic have ended with browsers getting an exception or adding the snapcraft-preload part to the snapcraft.yaml and putting it after desktop-launch in the app command.

I’ve tried adding snapcraft-preload part (just copy/pasted from its github repo’s README) and the resulting snap always fails to launch with “snapcraft-preload: no such file or directory”, which I think is a result of that part failing to install properly for some reason.

Is this still the preferred way to handle this in core20? Is there something obvious I’m missing, like needing to specify a different prefix? (I recall reading something about default prefix changing from /usr to /usr/local with the transition to core20?)

I also read that layout binding could be a solution, but I read elsewhere that /dev/shm is off-limits for that.

So, I’m just a little lost on how I should handle this, and it seems like most of the action for this problem was back in 2017 :stuck_out_tongue:

Replying to myself because I’m past the editing window:

It looks like this recent thread has all of the info I needed (I had read through it but it didn’t really sink in, apparently): Help creating a strict snap that uses shared memory

The important thing is that core20 does indeed install everything in /usr/local instead of /usr or /, so if you use the snapcraft-preload part, you need to add another line to set the prefix to match the older standard:

    plugin: cmake

well, it seems I spoke too soon. My application still can’t shm_open. When I run it, I get:

ERROR: object '/snap/retroarch/1140/usr/lib/' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.

And then my plugins that use shared memory (namely, dolphin, swanstation, and citra libretro cores) still fail with (example from dolphin):

[libretro ERROR] 38:54:336 Common/MemArena.cpp:88 E[MI]: shm_open failed: Permission denied

I’ve tried adding export LD_PRELOAD=$SNAP/usr/lib/ to my snapcraft.yaml recipe’s environment block, I’ve tried adding it to my launcher script. Nothing seems to help. Does anyone have any suggestions? Here’s my snapcraft.yaml if that helps for reference.

there seems to be a slight name discrepancy, did you check $SNAP/usr/lib which is the correct name for the .so ?

oh, sorry, it actually tries both:

ERROR: object '/snap/retroarch/1140/lib/' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
ERROR: object '/snap/retroarch/1140/usr/lib/' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.

but when I run snap run --shell retroarch and look in $SNAP/usr/lib, I see:

$ ls $SNAP/usr/lib | grep preload

so, it looks like at least one of them should be found :confused:

it does not look for in $SNAP/usr/lib, only in $SNAP/lib …

ah, yeah, you’re right. clearly my brain has melted lol

So, I guess my real question is: what is snapcraft-preload doing? Exporting the proper path doesn’t seem to stop the errors–unless I’m just not doing it in the right place; is there a specific place where this should work?–and in any event, I still can’t shm_open anything. Should I be able to at this point? Is there something else I should have done to make this work with core20 aside from just setting the prefix to /usr instead of /usr/local?

i’d assume you want to fix the path in $SNAP/bin/snapcraft-preload to contain usr/ …

eyy, success :slight_smile:

I needed to export the (correct) path in my launcher script and set a compile flag in snapcraft-preload.

Here’s the full snapcraft-preload part if anyone needs:

    plugin: cmake
      - on amd64:
        - gcc-multilib
        - g++-multilib
      - on amd64:
        - lib32stdc++6

It still coughs up an error, but shm_open actually works, so problem solved. Thanks for the help.

1 Like