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

Roger Leigh rleigh at codelibre.net
Tue Apr 12 11:38:03 UTC 2011

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

OK, some results:

                /var/run  /var/lock  /dev/shm
Min                    9         0         0
5% percentile         60         0         0
Mean                 886         9       599
Median               120         8         0
95% percentile       612        17       310
Max                47696        52     80744

I was going to do this separately for different types of system
(desktop, server, etc.), but there really wasn't much difference
except for a few outliers.

/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?
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.  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.

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?

/var/lock: Tiny usage under all circumstances.  One MiB would be
more than plenty.

/tmp, /dev/shm: Can vary massively depending on what's using it; we
can't set a sensible default at all.

Josh Triplett suggested that we could use a single tmpfs on /run and
have the rest as symlinks into /run, with potentially a separate
tmpfs for user-writable filesystems to prevent a user DoS.  This idea
does have merit, and we could make it the default.  We currently do
this for /var/lock (/run/lock), which can be mounted as a separate
tmpfs on /run/lock if RAMLOCK is set in /etc/defaults/rcS.  We could
also do the same for /dev/shm (/run/shm) and /tmp (/run/tmp) as well.
In the case of /tmp this would not be the default except when root is
read-only.  This would mean we don't have to choose a default size for
each filesystem separately.  But the sysadmin would have the ability to
enable it should they choose.


  .''`.  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/1dd548c5/attachment.pgp>

More information about the Pkg-samba-maint mailing list