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)
signature.asc
Description: Digital signature