On Mon, 2013-09-09 at 06:36 -0600, Eric Blake wrote: > As I see it, the key difference is that MOST of /var must persist across > reboots, but /var/run is a special subdirectory that need persist only > as long as the process is running (pid files are a perfect example of > common /var/run contents). With the recent addition of systemd into the > GNU/Linux world, distros have moved to naming the two directories /var > and /run, rather than /var and /var/run, so that there is no instance of > a top-level directory whose subdirectories have different lifetimes on > their contents.
In my opinion the key differentiator for /var/run (/run) is that it is guaranteed to be cleaned on system reboot, and should not be cleaned during the lifetime of the system. /tmp, on the other hand, may or may not be cleaned ever. > While 'make install' will generally never stick files into /run (as such > files make no sense until the program is running), it is common to have > programs that stick empty subdirectories under /run (so that they are > labeled correctly during distribution, rather than having to create and > relabel them on the fly). Hence having --rundir available as an option > to specify /run/pkg via $(rundir)/pkg (rather than hard-coding to > $(localstate)/run/pkg) is desirable for installation of these directories. I'm not sure this can be relied upon. Some distributions, such as Debian (I believe) and Ubuntu (I'm sure) use a tmpfs for /run. This means that not only will all files be deleted on reboot (as Red Hat does), but everything including subdirectories will be deleted. So, adding subdirectories here as part of an install step is not reliable. Admittedly this is very frustrating because /run is owned by root/root and 755, which means only processes started as root (or setuid) can make use of /run reliably. I've modified my init scripts to create and chown subdirectories but this is still not ideal since I'd like to be able to start services even when I'm not root (if I am logged in as the appropriate user account). More thought needs to go into this aspect of /run IMO. In any event, having an option in autoconf is appropriate so that the program itself can be configured to create and/or look for run files in the proper place, even if the installer doesn't need it. Cheers!
