[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



One last rc.d comment. (noting I use a variety but try to stick with latest)

For 20 yrs. every time I try NFS during boot scripts, no matter which linux, I tend to get my linux frozen when nfs can't mount.

I have yet to see an NFS that offers file access in a suitable manner (ie, error checking, correct locking, roll-backs, etc), though I occasionally, sparingly, use it myself.

Why you all want to make it default for everyone even if the don't have nfs configured I have no idea ! It's sure to cause problems and isn't required by everyone.

Ok, you can now beat me with rusty spoons I'll try not to write anymore (this week)


johnandsara2@cox.netJohn D. Hendrickson and Sara Darnell wrote:
I've noticed I have to check /etc carefully.

Some rc.d scripts that packages install edit and or activate things in /etc (they make insertions into automatically actived scripts in /etc for ssh, ppp, perl, network (pre-ifupdown or what), exim, things or other possible phone home things). While most or all are innoculous (some DO look suspect) I don't allow that on my box - I boot thin is why. And whenever there is somethign I read it to see "why I must run it". Due to that I use some of my own init scripts which are slackware or potatoe scripts :)


Luca Capello wrote:
Hi there!

Disclaimer: this is my last post on this matter (i.e. the meaning of
RAMLOCK), it seems there is a problem with myself or my understanding.

On Tue, 12 Apr 2011 23:42:58 +0200, Roger Leigh wrote:
On Tue, Apr 12, 2011 at 10:35:37PM +0200, Luca Capello wrote:
On Tue, 12 Apr 2011 20:47:35 +0200, Roger Leigh wrote:
On Tue, Apr 12, 2011 at 08:12:21PM +0200, Luca Capello wrote:
Currently, `man rcS` gives:

    RAMLOCK
        Make /var/lock/ available as a ram file system (tmpfs).
[...]
Again, I found it changed: how can you define LOCK_SIZE if /run/lock is
on the same tmpfs than /run?
If you set RAMLOCK=yes, then /run/lock is a *separate* tmpfs
of size LOCK_SIZE, *exactly* like the /var/lock tmpfs mount
(it's the same code with s/var/run/g).  So the actual behaviour of this
option is entirely unchanged bar the switch from /var/lock to
/run/lock.

So by default, /run and /run/lock are on the same tmpfs.  But
if you set RAMLOCK=yes, you'll get a second tmpfs mounted on
/run/lock.  So yes, /run/lock will always be on a tmpfs filesystem,
that's obviously the main point of the patch.

Either I do not read `man rcS` as you read it or we do not understand
each other, so here the situation before and after your patch for /run
(/var/lock became useless, everything is in /run/lock now, but I kept
using /var/lock for consistency with the previous state):

[before] RAMLOCK=no  -> /var/lock on the same filesystem /var is on
         RAMLOCK=yes -> /var/lock on tmpfs
 [after] RAMLOCK=no  -> /var/lock is on tmpfs, shared with /run (given
                        that /var/lock is symlinked/bind-mounted to
                        /run/lock)
         RAMLOCK=yes -> /var/lock gets its own tmpfs, differently from
                        the one mounted at /run

So, the meaning of RAMLOCK, WRT `man rcS` and as I read it, *has*
changed.  This is where we do not agree on wordings, but given that
English is not my mother language, maybe it is only my fault.

Thx, bye,
Gismo / Luca




Reply to: