From mboxrd@z Thu Jan 1 00:00:00 1970
Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org)
by finch.gentoo.org with esmtp (Exim 4.60)
(envelope-from <gentoo-user+bounces-138669-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1SYV8B-0007Nk-45
for garchives@archives.gentoo.org; Sun, 27 May 2012 04:31:03 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id BE835E0720;
Sun, 27 May 2012 04:30:41 +0000 (UTC)
Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181])
by pigeon.gentoo.org (Postfix) with ESMTP id 22885E06C5
for <gentoo-user@lists.gentoo.org>; Sun, 27 May 2012 04:29:17 +0000 (UTC)
Received: by vcbf1 with SMTP id f1so1248396vcb.40
for <gentoo-user@lists.gentoo.org>; Sat, 26 May 2012 21:29:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:content-type:content-transfer-encoding;
bh=wceKYCNQcQMYiNUQdwwJWbf0ahAP1PU8fBtU2i0kDEg=;
b=TJxwbQIixsTIeUjhAovz2ITzLaK5mAwZhdfaRKtS/BN+fTmvDb568z4t/alm2U5RZ8
GB+T3//LocvZM/xbwlmFF5ijM/PsmAmOOqUG4pcuAlW1BG9esOQ13uheV303n5RWqaZd
onmv/h+M99LRgGm6xb0K3CjYMrpZomDVFBPkm7Ni8LEuUvBwqAsBQMcS+ID/AsZDSa39
51Iw+3L+D+3ivfGC6UB2TxP/iQbHWq0wC/mWctLhZYnb+hyNMkJZ9NoHTXfZP49S3hgG
wZibetzG9jkd/PE2pOVxvELPRoNYtlnRIXogzr/de2HX2cHQi2A4bW4zVqkKo149cmpT
zUnA==
Precedence: bulk
List-Post: <mailto:gentoo-user@lists.gentoo.org>
List-Help: <mailto:gentoo-user+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-user+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-user+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-user.gentoo.org>
X-BeenThere: gentoo-user@lists.gentoo.org
Reply-to: gentoo-user@lists.gentoo.org
MIME-Version: 1.0
Received: by 10.52.93.203 with SMTP id cw11mr1092023vdb.71.1338092957420; Sat,
26 May 2012 21:29:17 -0700 (PDT)
Received: by 10.220.119.146 with HTTP; Sat, 26 May 2012 21:29:17 -0700 (PDT)
In-Reply-To: <4FC19A24.2000103@gmail.com>
References: <4FC1332A.3040703@gmail.com>
<4FC1368E.7080005@gmail.com>
<4FC13850.2020802@gmail.com>
<20120526214001.0668531f@digimed.co.uk>
<4FC15692.9070507@gmail.com>
<20120526233444.670274c8@digimed.co.uk>
<4FC16492.5020603@gmail.com>
<20120527012105.284de0e6@khamul.example.com>
<4FC17238.4020605@gmail.com>
<CAA2qdGVxzeWkxu2fWQ2_kTACd5reUovUxV_JfQ+dByZy-+o4nQ@mail.gmail.com>
<4FC19A24.2000103@gmail.com>
Date: Sun, 27 May 2012 04:29:17 +0000
Message-ID: <CAOTuDKq0OMnopmoFeXrgN8PyTTDx8pRATOjzVBH47qr7eg3Szw@mail.gmail.com>
Subject: Re: [gentoo-user] How can I control size of /run (tmpfs)?
From: Joshua Murphy <poisonbl@gmail.com>
To: gentoo-user@lists.gentoo.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Archives-Salt: 9a35e50c-3ac3-4b8a-be1e-3a00f028cf29
X-Archives-Hash: f2ec5cc3f504d89930f66391900380bb
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 ma=
y
>>> not be mounted yet, it was created and is used during booting up. =C2=
=A0Since
>>> it is there, why not use it, even AFTER the system is booted. =C2=A0Aft=
er
>>> all, =C2=A0the files are already there since they were put there during=
boot
>>> up. =C2=A0No need moving them and all that when they are already create=
d and
>>> available.
>>>
>>> Plus, as someone said, I think it was you in another reply, what if /va=
r
>>> fails to mount at all? =C2=A0At that point, it still works since /run i=
s
>>> there already. =C2=A0Since /run is on tmpfs, if it fails to mount for s=
ome
>>> reason, you got issues already. =C2=A0;-)
>>>
>>> I don't mind it being there, I just hope udev, or whatever else may use
>>> it later on, doesn't get memory hungry. =C2=A0 Actually, maybe some oth=
er
>>> small directories could be placed there as well. =C2=A0The lock files w=
ould
>>> be a good one to start with. =C2=A0Just thinking. =C2=A0May want to duc=
k tho. =C2=A0lol
>>>
>>
>> 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. =C2=A0It does look to me like they would move the files from /var/l=
ock,
> or any other lock files, there tho. =C2=A0They appear to be small here si=
nce
> it takes up so little space.
>
> root@fireball / # du -shc /var/lock/
> 32K =C2=A0 =C2=A0 /var/lock/
> 32K =C2=A0 =C2=A0 total
> root@fireball / #
>
> That would total up to be less than 300K for what is there and /var/lock
> on my machine.
>
> I dunno. =C2=A0Just makes sense to me.
>
> Dale
>
> :-) =C2=A0:-)
>
> --
> I am only responsible for what I said ... Not for what you understood or
> how you interpreted my words!
>
> Miss the compile output? =C2=A0Hint:
> EMERGE_DEFAULT_OPTS=3D"--quiet-build=3Dn"
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.
--=20
Poison [BLX]
Joshua M. Murphy