Linux Archive - Default size limits for /run (/var/run) and /run/lock (/var/lock)

Linux Archive (http://www.linux-archive.org/)

- Debian Development (http://www.linux-archive.org/debian-development/)

- - Default size limits for /run (/var/run) and /run/lock (/var/lock) (http://www.linux-archive.org/debian-development/512884-default-size-limits-run-var-run-run-lock-var-lock.html)

Default size limits for /run (/var/run) and /run/lock (/var/lock)

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

for a variety of systems (desktop, server, large samba setup, very
large and busy systems, minimal environments etc.). We want to be
sure the default is sane for all but the most extreme outliers,
where the sysadmin would need to configure a bigger value as the
default. A sensible size for /tmp would also be useful, but this
obviously varies widely. Note this is for a tmpfs /tmp, which is
not mounted by default (only defaults if root is read-only).

Thanks for any feedback (any stats can be sent directly to me to
avoid flooding the list). I'd just like the output of the above
command, plus a small description of what the system is for
(size, major services etc.) for context.

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.

Default size limits for /run (/var/run) and /run/lock (/var/lock)

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.

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.

Default size limits for /run (/var/run) and /run/lock (/var/lock)

Am 12.04.2011 13:38, schrieb Roger Leigh:

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

I don't think symlinking /tmp to /run would be a good idea, as one could fill up
/tmp (accidentaly) pretty quick.
If we want to make / ro, then a separate tmpfs for /tmp looks like a better idea
to me.

Cheers,
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

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/
slangasek@ubuntu.com vorlon@debian.org

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110412144454.GC9036@virgil.dodds.net">http://lists.debian.org/20110412144454.GC9036@virgil.dodds.net

Default size limits for /run (/var/run) and /run/lock (/var/lock)

Hi there!

On Tue, 12 Apr 2011 13:38:03 +0200, Roger Leigh wrote:
> 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.

Do you mean that the meaning of RAMLOCK has completely changed?
Currently, `man rcS` gives:

RAMLOCK
Make /var/lock/ available as a ram file system (tmpfs).
Will also disable cleaning of /var/lock/ during boot.
Set to 'yes' to enable, to 'no' to disable. The size
of the tmpfs can be controlled using TMPFS_SIZE and
LOCK_SIZE in /etc/default/tmpfs. Because of this,
packages can not expect directories in /var/lock to
exist after boot. Packages expecting this are buggy
and need to be fixed.

I consider completely changing it a serious bug, may I suggest
deprecating it completely and adding a new variable instead? I guess
the same should be applied to RAMRUN, i.e. simply deprecate it.

Thx, bye,
Gismo / Luca

Default size limits for /run (/var/run) and /run/lock (/var/lock)

On Tue, Apr 12, 2011 at 08:12:21PM +0200, Luca Capello wrote:
> Hi there!
>
> On Tue, 12 Apr 2011 13:38:03 +0200, Roger Leigh wrote:
> > 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.
>
> Do you mean that the meaning of RAMLOCK has completely changed?
> Currently, `man rcS` gives:
>
> RAMLOCK
> Make /var/lock/ available as a ram file system (tmpfs).
> Will also disable cleaning of /var/lock/ during boot.
> Set to 'yes' to enable, to 'no' to disable. The size
> of the tmpfs can be controlled using TMPFS_SIZE and
> LOCK_SIZE in /etc/default/tmpfs. Because of this,
> packages can not expect directories in /var/lock to
> exist after boot. Packages expecting this are buggy
> and need to be fixed.
>
> I consider completely changing it a serious bug, may I suggest
> deprecating it completely and adding a new variable instead? I guess
> the same should be applied to RAMRUN, i.e. simply deprecate it.

With the patch as it stands at present, RAMRUN is deprecated. /run
is always a tmpfs; RUN_SIZE will set its size, as before.

RAMLOCK is unchanged, except for the fact that it's mounted on
/run/lock rather than /var/lock. Likewise, LOCK_SIZE is unchanged
in its meaning.

We could introduce new variables for /run such as RUNLOCK, but given
that it does exactly what it used to do, I don't think it gains us
anything.

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.

Default size limits for /run (/var/run) and /run/lock (/var/lock)

On Tue, Apr 12, 2011 at 07:47:35PM +0100, Roger Leigh wrote:
> With the patch as it stands at present, RAMRUN is deprecated. /run
> is always a tmpfs; RUN_SIZE will set its size, as before.

Hmm, just thinking... vServers don't really allow mounting AFAIK as that
would be the host's job. Wouldn't making /run a tmpfs in every case
conflict here? Or am I jumping around nonsense now...?

Hauke

--
.'`. Jan Hauke Rahm <jhr@debian.org> www.jhr-online.de
: :' : Debian Developer www.debian.org
`. `'` Member of the Linux Foundation www.linux.com
`- Fellow of the Free Software Foundation Europe www.fsfe.org

Default size limits for /run (/var/run) and /run/lock (/var/lock)

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.