On 09/09/2013 06:58 AM, Paul Smith wrote: > 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.
Indeed - sticking a pid file in /tmp is dangerous, if /tmp can be periodically cleaned; while /var is guaranteed not to be cleaned externally except on reboot. > >> 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. Indeed, since systemd likes to use /var as a tmpfs file system, there are other methods used to inform systemd which subdirectories a package would like created each time the tmpfs is instantiated. But that's an orthogonal issue for distros - one that the autotools need not solve. > > 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. Correct - see also gnulib's "configmake.h" file, which allows easy conversion from autoconf's configure --FOOdir options into a C header for easy reference to the locations specified at configure time. Being able to refer to a C macro that expands to "/run" (or to "/var/run", or whatever else was specified for --rundir) is much nicer than hard-coding it. Again, this proposal is useful even if it doesn't completely solve the issues that a distro faces by using tmpfs - it is an incremental improvement that is worthwhile in its own right. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
