Using /dev/shm directly is (potentially) broken

[jnpkrn]

See https://wiki.debian.org/ReleaseGoals/RunDirectory#Packages_using_.2Fdev.2Fshm

[chrissie-c]

Good catch, I'll look into this.

[jnpkrn]

Few notes:

• using /var/run (aka SOCKETDIR on standard Linux ./configure pass) for a shared memory mapped files location (further: shmdir) would not be very fortunate as this is still disk-backed by default with some (especially older) systems, unlike relatively new /run with clear (matching) intentions, which should be preferred
• there's this long-upcoming change to autoconf that would standardize --runstatedir option to ./configure: http://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=a197431414088a417b407b9b20583b2e8f7363bd (something to keep in mind for future, like being a default for SOCKETDIR)
• ./configure script could have an option for setting shmdir explicitly, otherwise it would default to what SOCKETDIR uses, unless it would start with /var/run in which case it would fallback to /dev/shm on Linux/Cygwin (as is currently the case)
• last but definitely not least (quite the contrary!), library should allow the shared memory backed server sides to specify full path for the handshake files per their choosing if they opt-in to (e.g., so as to utilize /run/<program>/ hierarchy which is encouraged in systemd-enabled environments)

[wferi]

Hi! Thinking about filesystem path choices, I reached a couple of questions:

• The abstract sockets are Linux-specific, and you want to support the portable filesystem sockets as well, so why keep the abstract socket support at all?
• Abstract sockets enable using libqb in unprivileged applications on Linux. Why not set the default socket directory to /tmp (or even create a temporary directory an use that) to enable unprivileged use on BSDs as well?
• Using mmap() on files under /dev/shm is pretty much what the POSIX shared memory API does. Why not use the standard shared memory API and forget about system specific paths?

What do you think? Regards, Feri.

[chrissie-c]

In general I'm very much in favour of keeping abstract sockets on Linux. They have a few good advantages (not having to deal with filesystem variances is one, but automatic clean-up is also quite a major one) and Linux is libqb's primary platform. The main reason that filesystem sockets were added was to overcome a limitation in the way that some container platforms behaved.

As for mmap vs POSIX shared memory - that's a decision that was made before I took over the maintainership. It's a good point though and worth investigating further.

[wferi]

Thanks for sharing your thoughts on the matter! Yeah, I don't deny the appeal of abstract sockets. The alternative code paths require more maintenance, though. And the recent advances (--with-force-sockets-config-file=FILE) aren't particularly pretty (if you forgive). The question is if you want to make the alternative implementation (filesystem sockets) flexible and robust enough to eventually obviate the need for abstract sockets. A plausible first step would be enabling unprivileged use of filesystem sockets, for example by changing the default of --with-socket-dir to a world-writeable directory, or even by letting the user override this via some new API (which would enable application-specific cleanup procedures as well).

Okay, this hasn't got much to do with /dev/shm after all. So let's float the idea of using POSIX shared memory here for a while, collecting opinions. If nobody objects, it may allow retiring some library code eventually.

[wferi]

Most aspects of this are covered in https://stackoverflow.com/questions/24875257/why-use-shm-open.

[chrissie-c]

Thanks for that. I think that should definitely be on the roadmap. I have very little time for libqb at the moment, sadly, but I'll keep this on the list of things to do.

[jnpkrn]

At this time, I can only guess that perhaps the original approach was meant to eventually serve a nice-to-have real-time communication tracing tool, which I perceive could still be useful till today, and would be in-line with the low-level yet interrupt (down-time-free, timeouts friendly) and run-time burden minimizing run-time diagnosing gist of libqb (see tracing level of logging).

(Similarly, it would be nice for qb-blackbox to be able to attach to "live" blackbox file to be observed in real-time, #291 . I am not sure this would be possible with standardized "shared memory" API. We shall not close the door to these opportunities prematurely, which is what happend with dropping the linker section usage for logging callsite storage that effectively kicked #274 out of reach.)