[Pkg-samba-maint] Default size limits for /run (/var/run) and /run/lock (/var/lock)

Tue Apr 12 19:19:59 UTC 2011

On Tue, Apr 12, 2011 at 07:44:54AM -0700, Steve Langasek wrote:
> On Tue, Apr 12, 2011 at 12:38:03PM +0100, Roger Leigh wrote:
> > On Mon, Apr 11, 2011 at 08:01:42PM +0100, Roger Leigh wrote:
> > > With the transition to /run and /run/lock as tmpfs filesystems, it
> > > would be desirable to provide sensible default size limits.  Currently,
> > > we default to the tmpfs default of ½ RAM.  But with several tmpfs
> > > filesystems, this does have the potential for the system to be OOMed
> > > by a user filling up more than one of the filesystems.  A sensible
> > > default size limit would be useful here, for at least some of the
> > > filesystems.
> 
> > > We currently allow specification of size limits for:
> > > /run (RUN_SIZE)
> > > /run/lock (LOCK_SIZE, optional)
> > > /dev/shm (SHM_SIZE)
> > > /tmp (TMP_SIZE, optional)
> 
> > > [from temporary git repo at http://git.debian.org/?p=collab-maint/sysvinit;a=summary]
> 
> > > In order to default to a sensible size, I would appreciate it if I
> > > could have some figures for the useage of these filesystems: e.g.
> 
> > > % sudo du -sk /var/run /var/lock /dev/shm
> 
> > /var/run: Most systems use just 1-200 KiB.  A few use a lot (tens of
> > MiB).  The large users appear to be Samba, which creates a number of
> > .tdb files under /var/run in addition to pidfiles; presumably on
> > very busy systems, these can grow to be quite large.  I guess they
> > are transient state, but is /var/run the appropriate place for them?
> 
> Yes, it is, per the FHS.

I thought so at well; I just wanted to check, given that it's the main
user of space under /run.

> > Without taking Samba into consideration, 10MiB would be more than
> > plenty for all but the most extreme uses.  Allowing for Samba, we need
> > at least 30MiB, and potentially >50MiB for a good safety margin.  Any
> > comments from the Samba maintainers?
> 
> I would like to know what real-world problem you're trying to solve by
> limiting the size of these filesystems.  Have you had actual reports of
> users running into trouble with the current half-of-RAM default filling up?
> I've never heard such a thing.  This is a root-only filesystem, so if the
> user has a service that wants that much space for temp files, why impose
> additional limits?

Resources are limited, and there's always a size limit.  But we
currently ignore the issue by simply accepting the kernel defaults,
which are far, far too large (but on a very low memory system, might
equally be too small).  We can of course continue to do so; this
doesn't directly cause problems--the space isn't actually claimed until
used--but there is the potential for the lack of consideration for the
real usage requirements to be abused.

For filesystems such as /run/lock, we can safely set a limit for it.
e.g. 2MiB would be fine; it's several hundred times the typical usage.
Having it sized at 4GiB (as is the case on my 8GiB desktop) is clearly
just too large.  We should be able to set a more sensible default than
that.  Current usage on my system: 12 KiB...  The same applies to
/lib/init/rw (currently 4GiB also; actual usage 8 KiB).

Having multiple tmpfses with the kernel defaults means that a user or
badly written program could intentionally or accidentally lock up the
machine by using all available memory by filling up one or more of the
tmpfses.  And the majority /are/ user writable by default, even /run
(via /var/lock, which is not a separate mount by default--maybe it
should be?).  /dev/shm is user writable, /tmp is user writable.

This isn't a new problem; users could always fill up /var before now
as well (by default).  But now they can lock up the system rather
than just using up free disc space.

>  If the problem is that multiple tmpfs are mounted and
> each can expand to half-of-RAM, either reduce the number of tmpfses
> presented (as discussed), or limit the *whole* allocation for known mount
> points to half-of-RAM and partition appropriately, or both.  But imposing
> stricter limits than necessary based on survey data is just wrong.

I wasn't wanting to impose "strict" limits, but a sensible default
based upon what was commonly used, with a big margin on top of that,
to ensure the limit would never be hit in practice.

For /var/run, 100MiB would be plenty more than would ever be required
for the vast majority of users.  But the suggestion of computing it
as a fraction of core+swap is a good one (perhaps with a minimum
limit).  

As you state above, reducing the total number of tmpfses would be
useful--we can then have one or two with sysadmin (or kernel) set
limits, so an individual directory won't have an outrageously
small limit that might be reached.

For this reason, I've adapted the patch to move /dev/shm to /run/shm;
it's configurable whether this is a separate tmpfs mount, or simply
a subdirectory of /run, and the size is also configurable as before
(SHM_SIZE, with RAMSHM as the option to toggle the mounting).  We
could additionally allow /tmp to be moved under /run/tmp, so that
all existing tmpfs mounts could share a single tmpfs (I haven't
done this yet).  Currently we mount a tmpfs on /tmp if RAMTMP=yes
or root is mounted read-only, but we could move it under /run.

If the above was done, all ephemeral system state and data would
have been moved under /run, and each would be individually
mountable with its own size limit should the sysadmin desire it.

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.alioth.debian.org/pipermail/pkg-samba-maint/attachments/20110412/3cde3111/attachment.pgp>