| 1 |
On Sun, May 27, 2012 at 3:06 AM, Dale <rdalek1967@×××××.com> wrote: |
| 2 |
> Pandu Poluan wrote: |
| 3 |
>> |
| 4 |
>> On May 27, 2012 7:19 AM, "Dale" <rdalek1967@×××××.com |
| 5 |
> |
| 6 |
>>> |
| 7 |
>>> What I was saying tho, since it appears to be needed now, since /var may |
| 8 |
>>> not be mounted yet, it was created and is used during booting up. Since |
| 9 |
>>> it is there, why not use it, even AFTER the system is booted. After |
| 10 |
>>> all, the files are already there since they were put there during boot |
| 11 |
>>> up. No need moving them and all that when they are already created and |
| 12 |
>>> available. |
| 13 |
>>> |
| 14 |
>>> Plus, as someone said, I think it was you in another reply, what if /var |
| 15 |
>>> fails to mount at all? At that point, it still works since /run is |
| 16 |
>>> there already. Since /run is on tmpfs, if it fails to mount for some |
| 17 |
>>> reason, you got issues already. ;-) |
| 18 |
>>> |
| 19 |
>>> I don't mind it being there, I just hope udev, or whatever else may use |
| 20 |
>>> it later on, doesn't get memory hungry. Actually, maybe some other |
| 21 |
>>> small directories could be placed there as well. The lock files would |
| 22 |
>>> be a good one to start with. Just thinking. May want to duck tho. lol |
| 23 |
>>> |
| 24 |
>> |
| 25 |
>> You mean /var/lock ? Hasn't it transmogrified to /run/lock now? |
| 26 |
>> |
| 27 |
>> Rgds, |
| 28 |
>> |
| 29 |
> |
| 30 |
> Well, the /run/lock directory is there but there is nothing in it on |
| 31 |
> mine. It does look to me like they would move the files from /var/lock, |
| 32 |
> or any other lock files, there tho. They appear to be small here since |
| 33 |
> it takes up so little space. |
| 34 |
> |
| 35 |
> root@fireball / # du -shc /var/lock/ |
| 36 |
> 32K /var/lock/ |
| 37 |
> 32K total |
| 38 |
> root@fireball / # |
| 39 |
> |
| 40 |
> That would total up to be less than 300K for what is there and /var/lock |
| 41 |
> on my machine. |
| 42 |
> |
| 43 |
> I dunno. Just makes sense to me. |
| 44 |
> |
| 45 |
> Dale |
| 46 |
> |
| 47 |
> :-) :-) |
| 48 |
> |
| 49 |
> -- |
| 50 |
> I am only responsible for what I said ... Not for what you understood or |
| 51 |
> how you interpreted my words! |
| 52 |
> |
| 53 |
> Miss the compile output? Hint: |
| 54 |
> EMERGE_DEFAULT_OPTS="--quiet-build=n" |
| 55 |
|
| 56 |
Well, given that it's there, it cleans up after itself, and it avoids |
| 57 |
issues in the instance where /var isn't available early on, is there |
| 58 |
much reason _not_ to link /var/run and /var/lock over to their |
| 59 |
respective equivalents on /run? And both with and without /var mounted |
| 60 |
(so they exist and are writable even if /var doesn't come up)? If I |
| 61 |
recall its purpose properly, /var exists to hold data that _needs_ to |
| 62 |
be writable in an actively running system, logs, lock files, caches, |
| 63 |
etc.. but as tmpfs didn't exist back when it was thought up, no |
| 64 |
separation was explicitly defined between persistent and |
| 65 |
non-persistent data. With /run around now, there's an explicitly |
| 66 |
defined lack of persistence that would suit /var/run and /var/lock |
| 67 |
rather well, since stale service pids, lock files, and the like can |
| 68 |
wreak havoc on an unplanned restart (which tends to be bad enough with |
| 69 |
the prospect of, say, a failed UPS as it is). Also, any |
| 70 |
inconsistencies in the above rambling curiosity (as well as the |
| 71 |
rambling itself, I should note) are the result of having been awake |
| 72 |
far too early for a Saturday, and still being awake for the start of |
| 73 |
Sunday, so apologies may be required on my part. |
| 74 |
|
| 75 |
-- |
| 76 |
Poison [BLX] |
| 77 |
Joshua M. Murphy |
Archives