Re: /run and needing a --rundir for configure

[Eric Blake]

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