[fhs-discuss] user-specific directories in /run

[Roger Leigh]

On Tue, May 24, 2011 at 10:08:56PM +0200, Ingo Schwarze wrote:
> Hi Jeff,
> 
> Jeff Licquia wrote on Tue, May 24, 2011 at 01:23:11PM -0400:
> 
> > So, we should specify /run in the FHS and leave /run/user as an 
> > implementation detail for the XDG spec.
> > 
> > Does that sound about right?

I think so.  If systemd wants to create such a directory and grant
users write access to user-specific subdirectories, that's its
perogative.  Evaluating the effect on tmpfs size limits would be
useful (how much additional space per user and/or per session)
given its impact on local DoS and potentially max. users being able
to log in and do stuff.

> As long as /run is specified as optional (as opposed to required),
> that sounds fine.
> 
> There are systems out there being very careful not to start any
> long-running userland processes, and even more so none requiring /run,
> before mounting local file systems, when booting into multi-user mode.
> 
> For example, before mounting /var, OpenBSD does nothing but:
>  - configure concatenated disk devices (if any)
>  - configure RAID devices (if any)
>  - enable swap devices
>  - fsck local file systems
> 
> On such a system, there is no benefit in having /run outside /var,
> and in fact, /run fits the definition of /var ("variable data files")
> very well.

[On Linux, RAID array reconstruction can take place in the initramfs,
prior to mounting /.  mdadm currently stores its state in /dev/.mdadm,
but this will be moving to /run/mdadm.  The same applies to other
processes started in early boot which need a writable place.]  But if
the system can get to the point of having /var mounted without needing
any writable filesystem, then /run is indeed not strictly required.

When considering making /run optional rather than required, I think
we need to think about:

- the differing lifetime guarantees between /var and /run
- if /run replaces /var/run entirely
- if /run may be a symlink to (or bind mount of) /var/run
- if /var/run may be a symlink to (or bind mount of) /run
- if /var/run is going to be deprecated and whether applications should
  switch to using /run in anticipation of its eventual removal, or
  should all applications stick to using /var/run?

If we aim to deprecate /var then having /run symlinking to or
bind mounting /var/run is OK as a short-term fix, but not as a viable
long-term option.  Migrating to /run and then having /var/run a
symlink to or bind mount of /run is preferable if the intention is to
later drop /var/run.  Once we have migrated to /run, it's possible to
keep /var/run as a symlink indefinitely, and I'll certainly be doing
so as long as it's required by the FHS.  But do we want that long
term?

Given that the existing content of /var/run is variable, but ephemeral
(it's cleaned on boot), it already has a different lifetime than the
rest of /var (which is variable, but persistent).  In addition to the
convenience of /run in early boot, having "ephemeral" data in a
separate top-level directory does make sense.

In the FHS, it would be useful to document the situation for /var/run
and /var/lock in addition to their new homes in /run and /run/lock,
once we have consensus on what their future and migration plan (if any)
is.

I think that at least for Linux, it would be preferable to replace
/var/run and /var/lock with /run and /run/lock and put compatibility
links/bind mounts in place for /var/run and /var/lock.  (This is what
we've all done so far.)  So I think the remaining question is if we're
going to phase out /var/run and /var/lock, and what the timescale for
that might be if we do.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
Url : http://lists.linux-foundation.org/pipermail/fhs-discuss/attachments/20110524/3eb97877/attachment.pgp