Bug#674755: Processed: Missing /run/shm breaks xshmfence

[Martin Pitt]

Keith Packard [2014-05-01 23:02 -0700]:
> > looking at libxshmfence_1.1-2, it's debian/rules use
> > --with-shared-memory-dir=/tmp so I don't see how the package is broken,
> > am I looking at the wrong package?

/tmp is definitively broken. It should be /dev/shm/ or /run/shm/,
nothing else.

> The auto-detection logic looks for /run/shm /var/tmp and /tmp in order,
> as I asked RedHat and SuSE developers for what they wanted. No-one asked
> for /dev/shm, and when I looked through the debian documentation, I
> found /run/shm as the 'preferred' location for tmpfs to be mounted.

For now, eglibc treats /dev/shm/ as the canonical path. /run/shm/ was
a Debianism because it was thought to be "prettier". Arguably it is,
but then again there's lots of paths which are ugly but which we can't
just change (/etc/, /usr/, etc.). codesearch.debian.net indeed doesn't
reveal too much stuff that actually depends on /run/shm/, most hits
seem to be fallback paths to support the Debian specific location. So
I'd recommend using /dev/shm/ as that works everywhere (it's a symlink
under sysvinit).

> I consider any change like this across a sysvinit->systemd transition
> to be a bug in systemd at this point; my system was working, and a
> transition to systemd caused it to stop working.

Yes, agreed. Until all references to /run/shm/ are gone, we should
keep a /run/shm -> /dev/shm/ compat symlink. Even more so as long as
https://wiki.debian.org/ReleaseGoals/RunDirectory is still an official
goal. So I consider the lack of the /run/shm/ symlink a bug, too.

> I'd love it if glibc offered an API to create an anonymous unnamed file
> in shmfs. Right now, I'm using:
> 
> #define SHMDIR "/run/shm"

If you change this to /dev/shm/ this seems reasonably portable to me
to other distros.

> 	fd = open(SHMDIR, O_TMPFILE|O_RDWR|O_CLOEXEC|O_EXCL, 0666);
> 
> I can't see how any application could responsibly use shm_open as that
> API appears to present all of the usual /tmp races which we've worked
> hard to eliminate. glibc doesn't appear to provide any other API for
> creating a temporary anonymous memory file.

As long as you use O_EXCL this should be fine?

Thanks,

Martin

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20140502/fd662f29/attachment-0002.sig>