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

[Keith Packard]

Michael Biebl <biebl at debian.org> writes:

> Hi Keith,
>
> 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?
> Can you elaborate?

I had built it locally on my machine under sysvinit (before there was a
package) and it selected /run/shm.

> The configure.ac auto-detection logic should be updated and use
> /dev/shm. Only this directory is pretty much guaranteed to exist
> cross-disto. Will file a bug against libxshmfence later.

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.

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.

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"

	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.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 810 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20140501/9341a148/attachment-0002.sig>