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 ) id 1SYVTc-0002Tw-9F for garchives@archives.gentoo.org; Sun, 27 May 2012 04:53:12 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2F63DE072C; Sun, 27 May 2012 04:52:57 +0000 (UTC) Received: from mail-yw0-f53.google.com (mail-yw0-f53.google.com [209.85.213.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 72187E060F for ; Sun, 27 May 2012 04:51:36 +0000 (UTC) Received: by yhp26 with SMTP id 26so1477993yhp.40 for ; Sat, 26 May 2012 21:51:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=JxEEGttqGByCAHEQWvM+3e8tfq/5b9D6QiFEE1eC4lQ=; b=JRgE9b0MbFykl9FW/vTpEFDV5vVWA+nAFK9M5mG2WGjc/y33DlwSFbfFsXvBYvuK/+ POOQhbebymG7Ejgi3QwWndhhzXsdNdqizvkuUVh+sm0dnaXXG38HbEekm9GsbtcwKq3J ZLLfs88MqW6MNVqDsCfS19mVkTadCulOCMY7QDs4BR7TqtuZ/1HGbSu/pH5P3ikUqUoi 7S5j6xO/ZVIxZ56r7dMiaFPa2HwcI+O4DRimfYQJjsCZ617KEhJbvGVLp/54MyoDLjVl J6URrvBhHJNs1cWUY2atYkQY0UtzpqieFp4r5udKFPpFo1EyhBZ8/0B3ubb9JQa54Rk2 +INw== Received: by 10.236.182.7 with SMTP id n7mr3742047yhm.61.1338094295868; Sat, 26 May 2012 21:51:35 -0700 (PDT) Received: from [192.168.2.5] (adsl-65-0-93-185.jan.bellsouth.net. [65.0.93.185]) by mx.google.com with ESMTPS id p4sm33526757yhl.5.2012.05.26.21.51.33 (version=SSLv3 cipher=OTHER); Sat, 26 May 2012 21:51:35 -0700 (PDT) Message-ID: <4FC1B2D4.30807@gmail.com> Date: Sat, 26 May 2012 23:51:32 -0500 From: Dale User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120523 Firefox/12.0 SeaMonkey/2.9.1 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] How can I control size of /run (tmpfs)? 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> <4FC19A24.2000103@gmail.com> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: 7ab214b1-1126-400d-8a73-5dfb4edb5fe0 X-Archives-Hash: a361ec18ee0b996b8e7b063506e8979b 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"