Re: [Pkg-samba-maint] Default size limits for /run (/var/run) and /run/lock (/var/lock)
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/