Idiomatic location for file based sockets on Debian systems

Question

I am writing a daemon process for a Debian system in C that uses a Unix Domain Socket.

If the daemon process's working directory is the root directory, is there an idiomatic directory to place the socket on the file system?

Answer 1

They are commonly found in /tmp or a subdirectory thereof. Note that everything in /tmp is subject to erasure at shutdown -- not that it necessarily is erased, just beware that it can be, so if you use that, check if you have to create your subdirectory each time. You will want to use a subdirectory if you want to restrict access via permissions, since /tmp is world readable.

/run and /var/run (which may be symlinked together) are used in a similar way, but they are generally mounted as tmpfs filesystems -- meaning they are created at boot and reside in memory, not on disk (so do not use that as a place to dump copious amounts of data). For a runtime socket, it is probably a good choice.

Note that /run, and all of the other directories mentioned here except /tmp, are only writable by root. For a system process, this is fine, but if the application may be run by a non-privileged user, you either want to use /tmp or create a permanent directory somewhere and set permissions on that, or use a location in the user's $HOME.

It is possible to create a directory in /usr/share (or /usr/local/share) during installation. Directories and contents there are not potentially reaped across boots as they would be in /tmp or /run. However, as jordanm points out in the comments, /usr may be mounted read-only and the linux filesystem hierarchy guidelines reflect this. Of course, it can't be read-only when your application is installed, so if you are comfortable creating a socket there then, you can leave it and use it later (you will still be able to write to the socket even though the file is read-only).

If you want somewhere persistent across boots that won't get mounted read-only, /etc is a fairly safe bet, since this is often used for system-wide configurations and re-configurations. OTOH, it is possible to have systems where the device underlying the entire root filesystem is read-only (e.g., embedded systems), with /tmp and /run on another device (probably: tmpfs in memory). So the two most robust strategies would seem to be:

• Install the socket to a permanent location when the application is installed.

• Create a directory in /run or /var/run at runtime and put the socket there.

• Do the same thing only in /tmp.

The advantage of the first one is that no matter what, once the app is installed, you'll have a socket to use. The advantage of the second one is that it may be more conducive to sane programming. The advantage of the third is it does not require superuser privileges. It should be easy to switch from one implementation to another if you change your mind later.

Finally, as BatchyX brought up, you should at least offer a configuration option for this, falling back on your choice of default.