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

[Steve Langasek]

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.

> If so, we need to take this into account.
> One system had a > 1MiB /var/run/samba/namelist.debug file, which
> could possibly have been put elsewhere.

It fits the FHS definition for /var/run.  It doesn't belong elsewhere.

>  wins.tdb, connections.tdb and locking.tdb in particular look like they
> can potentially grow very large; would keeping these on /var and deleting
> them on server restart be more appropriate than using /run?  utmp could
> also potentially grow to several MiB.

Keep them *where* on /var?  They're already exactly where the FHS says they
should be.  The server will null them out on startup, which is precisely the
sort of file that's *meant to be stored in /var/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?  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.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org