FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo User

 
 
LinkBack Thread Tools
 
Old 05-27-2012, 04:29 AM
Joshua Murphy
 
Default How can I control size of /run (tmpfs)?

On Sun, May 27, 2012 at 3:06 AM, Dale <rdalek1967@gmail.com> wrote:
> Pandu Poluan wrote:
>>
>> On May 27, 2012 7:19 AM, "Dale" <rdalek1967@gmail.com
>
>>>
>>> What I was saying tho, since it appears to be needed now, since /var may
>>> not be mounted yet, it was created and is used during booting up. *Since
>>> it is there, why not use it, even AFTER the system is booted. *After
>>> all, *the files are already there since they were put there during boot
>>> up. *No need moving them and all that when they are already created and
>>> available.
>>>
>>> Plus, as someone said, I think it was you in another reply, what if /var
>>> fails to mount at all? *At that point, it still works since /run is
>>> there already. *Since /run is on tmpfs, if it fails to mount for some
>>> reason, you got issues already. *;-)
>>>
>>> I don't mind it being there, I just hope udev, or whatever else may use
>>> it later on, doesn't get memory hungry. * Actually, maybe some other
>>> small directories could be placed there as well. *The lock files would
>>> be a good one to start with. *Just thinking. *May want to duck tho. *lol
>>>
>>
>> You mean /var/lock ? Hasn't it transmogrified to /run/lock now?
>>
>> Rgds,
>>
>
> Well, the /run/lock directory is there but there is nothing in it on
> mine. *It does look to me like they would move the files from /var/lock,
> or any other lock files, there tho. *They appear to be small here since
> it takes up so little space.
>
> root@fireball / # du -shc /var/lock/
> 32K * * /var/lock/
> 32K * * total
> root@fireball / #
>
> That would total up to be less than 300K for what is there and /var/lock
> on my machine.
>
> I dunno. *Just makes sense to me.
>
> Dale
>
> :-) *:-)
>
> --
> I am only responsible for what I said ... Not for what you understood or
> how you interpreted my words!
>
> Miss the compile output? *Hint:
> EMERGE_DEFAULT_OPTS="--quiet-build=n"

Well, given that it's there, it cleans up after itself, and it avoids
issues in the instance where /var isn't available early on, is there
much reason _not_ to link /var/run and /var/lock over to their
respective equivalents on /run? And both with and without /var mounted
(so they exist and are writable even if /var doesn't come up)? If I
recall its purpose properly, /var exists to hold data that _needs_ to
be writable in an actively running system, logs, lock files, caches,
etc.. but as tmpfs didn't exist back when it was thought up, no
separation was explicitly defined between persistent and
non-persistent data. With /run around now, there's an explicitly
defined lack of persistence that would suit /var/run and /var/lock
rather well, since stale service pids, lock files, and the like can
wreak havoc on an unplanned restart (which tends to be bad enough with
the prospect of, say, a failed UPS as it is). Also, any
inconsistencies in the above rambling curiosity (as well as the
rambling itself, I should note) are the result of having been awake
far too early for a Saturday, and still being awake for the start of
Sunday, so apologies may be required on my part.

--
Poison [BLX]
Joshua M. Murphy
 
Old 05-27-2012, 04:51 AM
Dale
 
Default How can I control size of /run (tmpfs)?

Joshua Murphy wrote:

> Well, given that it's there, it cleans up after itself, and it avoids
> issues in the instance where /var isn't available early on, is there
> much reason _not_ to link /var/run and /var/lock over to their
> respective equivalents on /run? And both with and without /var mounted
> (so they exist and are writable even if /var doesn't come up)? If I
> recall its purpose properly, /var exists to hold data that _needs_ to
> be writable in an actively running system, logs, lock files, caches,
> etc.. but as tmpfs didn't exist back when it was thought up, no
> separation was explicitly defined between persistent and
> non-persistent data. With /run around now, there's an explicitly
> defined lack of persistence that would suit /var/run and /var/lock
> rather well, since stale service pids, lock files, and the like can
> wreak havoc on an unplanned restart (which tends to be bad enough with
> the prospect of, say, a failed UPS as it is). Also, any
> inconsistencies in the above rambling curiosity (as well as the
> rambling itself, I should note) are the result of having been awake
> far too early for a Saturday, and still being awake for the start of
> Sunday, so apologies may be required on my part.
>


Well, I don't see why not. As you say, lack of a proper clean up after
a bad shutdown can cause problems. Anything in /run would disappear
after a shutdown, clean or not, since it is in tmpfs. It doesn't seem
to use much ram either. I really don't know of a reason why it couldn't
be set that way. I'm not the sharpest tool in the shed tho. lol

As for one of us setting it to do that manually, I guess one could do
that. If I recall correctly, /var/lock is *supposed* to be cleaned up
when booting but that was a good long while ago. This may be something
the devs are already getting ready for. I get the feeling that they are
taking what I call baby steps. I noticed a upgrade to baselayout and I
think OpenRC as well not long ago. I'm not sure what decided to put
stuff in /run. I would think it would be one of those but it could be
some other package. I guess udev could be one that could have made it
as well. It does have a directory in there that has stuff in it. The
rest are empty.

I'd wait for a serious guru to reply before changing anything tho, just
to be safe. ;-)

You think being up late at night is bad. You should see me when my meds
are making me goofy. lol

Dale

:-) :-)

--
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!

Miss the compile output? Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"
 
Old 05-27-2012, 05:22 AM
Joshua Murphy
 
Default How can I control size of /run (tmpfs)?

On Sun, May 27, 2012 at 4:51 AM, Dale <rdalek1967@gmail.com> wrote:
> Joshua Murphy wrote:
<snip>
>
> Well, I don't see why not. *As you say, lack of a proper clean up after
> a bad shutdown can cause problems. *Anything in /run would disappear
> after a shutdown, clean or not, since it is in tmpfs. * It doesn't seem
> to use much ram either. *I really don't know of a reason why it couldn't
> be set that way. *I'm not the sharpest tool in the shed tho. *lol
>
> As for one of us setting it to do that manually, I guess one could do
> that. *If I recall correctly, /var/lock is *supposed* to be cleaned up
> when booting but that was a good long while ago. *This may be something
> the devs are already getting ready for. *I get the feeling that they are
> taking what I call baby steps. *I noticed a upgrade to baselayout and I
> think OpenRC as well not long ago. *I'm not sure what decided to put
> stuff in /run. *I would think it would be one of those but it could be
> some other package. *I guess udev could be one that could have made it
> as well. *It does have a directory in there that has stuff in it. *The
> rest are empty.
>
> I'd wait for a serious guru to reply before changing anything tho, just
> to be safe. *;-)
>
> You think being up late at night is bad. *You should see me when my meds
> are making me goofy. *lol
>
> Dale
>
> :-) *:-)


I would try it right now, but

a) the only proper 'desktop' I have running is a windows box, the rest
of my systems, netbook, laptops, and servers, are stripped down to the
bare essentials and are likely to continue skipping along smoothly for
a long while regardless of what I do to them, hardly a useful test for
something that could potentially cause catastrophic breakage for more
'normal' systems, and

b) if it *did* break, I would dread it as I went about trying to
remember my exact steps to get there after I wake up tomorrow,
especially with the fact that I'm aiming to head to the office when I
wake, rather than toy around with fixing things here at home.

Maybe tomorrow evening on a couple systems, if the idea itself doesn't
bring about any "don't do this, you'll break <x>" responses between
now and then (and, depending on the severity of the potential
breakage, may still have to poke it with a stick).

--
Poison [BLX]
Joshua M. Murphy
 
Old 05-27-2012, 06:04 AM
Dale
 
Default How can I control size of /run (tmpfs)?

Joshua Murphy wrote:
> On Sun, May 27, 2012 at 4:51 AM, Dale <rdalek1967@gmail.com> wrote:
>> Joshua Murphy wrote:
> <snip>
>>
>> Well, I don't see why not. As you say, lack of a proper clean up after
>> a bad shutdown can cause problems. Anything in /run would disappear
>> after a shutdown, clean or not, since it is in tmpfs. It doesn't seem
>> to use much ram either. I really don't know of a reason why it couldn't
>> be set that way. I'm not the sharpest tool in the shed tho. lol
>>
>> As for one of us setting it to do that manually, I guess one could do
>> that. If I recall correctly, /var/lock is *supposed* to be cleaned up
>> when booting but that was a good long while ago. This may be something
>> the devs are already getting ready for. I get the feeling that they are
>> taking what I call baby steps. I noticed a upgrade to baselayout and I
>> think OpenRC as well not long ago. I'm not sure what decided to put
>> stuff in /run. I would think it would be one of those but it could be
>> some other package. I guess udev could be one that could have made it
>> as well. It does have a directory in there that has stuff in it. The
>> rest are empty.
>>
>> I'd wait for a serious guru to reply before changing anything tho, just
>> to be safe. ;-)
>>
>> You think being up late at night is bad. You should see me when my meds
>> are making me goofy. lol
>>
>> Dale
>>
>> :-) :-)
>
>
> I would try it right now, but
>
> a) the only proper 'desktop' I have running is a windows box, the rest
> of my systems, netbook, laptops, and servers, are stripped down to the
> bare essentials and are likely to continue skipping along smoothly for
> a long while regardless of what I do to them, hardly a useful test for
> something that could potentially cause catastrophic breakage for more
> 'normal' systems, and
>
> b) if it *did* break, I would dread it as I went about trying to
> remember my exact steps to get there after I wake up tomorrow,
> especially with the fact that I'm aiming to head to the office when I
> wake, rather than toy around with fixing things here at home.
>
> Maybe tomorrow evening on a couple systems, if the idea itself doesn't
> bring about any "don't do this, you'll break <x>" responses between
> now and then (and, depending on the severity of the potential
> breakage, may still have to poke it with a stick).
>


Be careful, sometimes when you poke things with a stick, it bites. ROFL

Dale

:-) :-)

--
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!

Miss the compile output? Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"
 
Old 05-27-2012, 06:20 AM
Canek Peláez Valdés
 
Default How can I control size of /run (tmpfs)?

On Sat, May 26, 2012 at 11:29 PM, Joshua Murphy <poisonbl@gmail.com> wrote:
[ snip ]
> Well, given that it's there, it cleans up after itself, and it avoids
> issues in the instance where /var isn't available early on, is there
> much reason _not_ to link /var/run and /var/lock over to their
> respective equivalents on /run?

I use systemd, which was the one introducing both /run and /run/lock:

http://lists.freedesktop.org/archives/systemd-devel/2011-March/001757.html

With systemd, /var/run and /var/lock are bind-mounted to /run and
/run/lock respectively. /run uses in my laptop (regularly suspended,
with an uptime of 25 days) 8.8 megabytes, which I think is basically
nothing for my 4 gigabyte RAM.

After more programs (dracut, plymouth) started using /run and
/run/lock, OpenRC implemented the same functionality; or so I read
somewhere, I haven't used OpenRC in a while. In theory, it should work
the same as with systemd.

Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México
 
Old 05-27-2012, 06:34 AM
Canek Peláez Valdés
 
Default How can I control size of /run (tmpfs)?

On Sun, May 27, 2012 at 1:20 AM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> On Sat, May 26, 2012 at 11:29 PM, Joshua Murphy <poisonbl@gmail.com> wrote:
> [ snip ]
>> Well, given that it's there, it cleans up after itself, and it avoids
>> issues in the instance where /var isn't available early on, is there
>> much reason _not_ to link /var/run and /var/lock over to their
>> respective equivalents on /run?
>
> I use systemd, which was the one introducing both /run and /run/lock:
>
> http://lists.freedesktop.org/archives/systemd-devel/2011-March/001757.html
>
> With systemd, /var/run and /var/lock are bind-mounted to /run and
> /run/lock respectively. /run uses in my laptop (regularly suspended,
> with an uptime of 25 days) 8.8 megabytes, which I think is basically
> nothing for my 4 gigabyte RAM.
>
> After more programs (dracut, plymouth) started using /run and
> /run/lock, OpenRC implemented the same functionality; or so I read
> somewhere, I haven't used OpenRC in a while. In theory, it should work
> the same as with systemd.

I take that back; OpenRC doesn't bind-mount /run in /var/run. I ssh'd
to a server running OpenRC, and /var/run is independent from /run. And
still a regular directory, not a tmpfs.

That's a shame. Given that udev uses /run (stable "old" version,
171-r6), OpenRC should use it too; there is basically no cost, and the
gains are obvious.

With systemd is automatic the bind-mounting of /run into /var/run.
Perhaps a future version of OpenRC will use it?

Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México
 
Old 05-27-2012, 07:05 AM
Jarry
 
Default How can I control size of /run (tmpfs)?

I have read through all replies, but I still did not find
answers to my original questions:

Q1: Can I somehow reduce the size of /run? I know it is tmpfs
and I know this is upper limit normally never achieved, but
I want to reduce this upper limit. Is it possible, or is it
hard-coded to half of physical memory?

Q2: Can I turn this "/run in tmpfs" feature off? I do not
see *any* advantage in vasting memory for /run (although
I agree there might be some point in moving "run" from
/var/run to /run). But I see one big problem:

If badly written application starts writing some crap in
/run, it could deadlock my computer quite easily. And before
you ask, no it is not so easy to do with /run on hard-drive
because I have plenty of TB there and monitoring software
running which alerts me as soon as any partition is half
full. Unfortunatelly this does not work for tmpfs because
with given read/write speed of ram-disk it would be full
in a few seconds before I had any chance to act...

Jarry

--
__________________________________________________ _____________
This mailbox accepts e-mails only from selected mailing-lists!
Everything else is considered to be spam and therefore deleted.
 
Old 05-27-2012, 07:59 AM
Alan McKinnon
 
Default How can I control size of /run (tmpfs)?

On Sun, 27 May 2012 09:05:46 +0200
Jarry <mr.jarry@gmail.com> wrote:

> I have read through all replies, but I still did not find
> answers to my original questions:
>
> Q1: Can I somehow reduce the size of /run? I know it is tmpfs
> and I know this is upper limit normally never achieved, but
> I want to reduce this upper limit. Is it possible, or is it
> hard-coded to half of physical memory?

I think this works IIRC:

List it in /etc/fstab. Max size goes in the options field using the
syntax described in man mount


> Q2: Can I turn this "/run in tmpfs" feature off? I do not
> see *any* advantage in vasting memory for /run (although
> I agree there might be some point in moving "run" from
> /var/run to /run). But I see one big problem:


If if limit the tmpfs to say 100M or so then this is not a problem at
all


>
> If badly written application starts writing some crap in
> /run, it could deadlock my computer quite easily. And before
> you ask, no it is not so easy to do with /run on hard-drive
> because I have plenty of TB there and monitoring software
> running which alerts me as soon as any partition is half
> full. Unfortunatelly this does not work for tmpfs because
> with given read/write speed of ram-disk it would be full
> in a few seconds before I had any chance to act...
>
> Jarry
>



--
Alan McKinnnon
alan.mckinnon@gmail.com
 
Old 05-27-2012, 08:16 AM
Neil Bothwick
 
Default How can I control size of /run (tmpfs)?

On Sun, 27 May 2012 04:29:17 +0000, Joshua Murphy wrote:

> Well, given that it's there, it cleans up after itself, and it avoids
> issues in the instance where /var isn't available early on, is there
> much reason _not_ to link /var/run and /var/lock over to their
> respective equivalents on /run? And both with and without /var mounted
> (so they exist and are writable even if /var doesn't come up)?

I did that months ago to resolve an issue with a specific package that
hadn't been updated to use /run at the time. I never got round to
removing the links and it has caused no problems.


--
Neil Bothwick

Suicidal twin kills sister by mistake!
 
Old 05-27-2012, 08:24 AM
Neil Bothwick
 
Default How can I control size of /run (tmpfs)?

On Sun, 27 May 2012 09:05:46 +0200, Jarry wrote:

> I have read through all replies, but I still did not find
> answers to my original questions:
>
> Q1: Can I somehow reduce the size of /run? I know it is tmpfs
> and I know this is upper limit normally never achieved, but
> I want to reduce this upper limit. Is it possible, or is it
> hard-coded to half of physical memory?

That has been answered, either use fstab, which may or not work, or mount
-o remount, which should.

> Q2: Can I turn this "/run in tmpfs" feature off? I do not
> see *any* advantage in vasting memory for /run

Given that /var/run would be cached, at least initially, there is no more
memory usage.

> If badly written application starts writing some crap in
> /run, it could deadlock my computer quite easily. And before
> you ask, no it is not so easy to do with /run on hard-drive
> because I have plenty of TB there and monitoring software
> running which alerts me as soon as any partition is half
> full. Unfortunatelly this does not work for tmpfs because
> with given read/write speed of ram-disk it would be full
> in a few seconds before I had any chance to act...

Except that the default size is HALF your RAM, so something else would
need to be using the other half and all your swap (tmpfs will use swap if
physical memory is not available).


--
Neil Bothwick

Octal: (n.) a base-8 counting system designed so that one hand may count
upon the fingers of the other. Thumbs are not used, and the index finger
is reserved for the 'carry.'
 

Thread Tools




All times are GMT. The time now is 02:54 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org