Request for 18 track for libc-shm-shim snap

libc-shm-shim is snap intended to be used when building snap which is likely to use multi threading trough Python, which eventually ends up denied because of wrong syntax of file created under /dev/shm used by libc semaphore.
Solution is to tweak libpthread library, which this snaps delivers.
There can be indeed part in snap which does recompile libc, but this is often unnecessary and time consuming, so having snap with ready to use library is convenient way.
Library takes env variable SNAP_SHM_PREFIX or SNAP_SHM_SUB_DIR to use sub-dir or add prefix to file names. So it can be reused in any snap and controlled by env variable.

Reason for track request is to have this available for UC16 as well as UC18 environment.

1 Like

I assume you need a different build/binary/snap for 16 vs. 18, correct?

If that’s true, then this sounds consistent with track usage to me, so +1 as reviewer.

We need a waiting period of 7 days (per Process for aliases, auto-connections and tracks) to collect votes from other reviewers. Once the 7 days have elapsed, we can tally the votes and if we have enough, I’ll proceed to create the tracks.


  • Daniel
1 Like

Correct, different version of glibc in core 16 and core 18

Unrelated to the track request, are you aware of Python multiprocessing sem_open blocked in strict mode ? I’m a little concerned about the maintenance burden and stability of a snap of this nature.

1 Like

hmm interesting, last time I check, there was not update on that thread so I prepared this library, but it seems to be addressing same problem.
I was able to get around python multiprocessing denials by recompiling libpthread and simply adding snap subdirectory when path to /dev/shm is determined. Optionally I just append “snap.<snap_name>” to /dev/shm/ otherwise returned by the function.
Reason for having it in separate snap is that it makes snap build quite long, as one has to recompile whole libc, though only using one library then.
I guess it’s unrealistic to fix this in archive glibc, but it’s unfortunate that with what we have in core snap, sem_init will always fail.


The 7-day waiting period has elapsed and we don’t have enough votes (so far a +1 only). Could other @reviewers, particularly @jdstrand, chime in?

As reviewer, I’m requesting/starting an extended voting period for this request to try to get more votes either way. We’ll tally again in 7 days.

  • Daniel

the snapcraft-preload can be used for semaphore compatibility without rebuilding the world once @sergiusens merges PR #29