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

[Paul Smith]

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!