It is better in terms of performance and power consumption to have a tmpfs /var/run dir (as well as /tmp and /var/lock). Unfortunately it is currently impossible to do so with ipw3945d. The problem is that ipw3945d is unable to create its /var/run/ipw3945d dir if it doesn't exist. Currently the init scripts rely on that dir being already created by the emerge process. So I suggest to add the dir creation to the init script start process. Does this make sense?
Or an even easier solution, to move the pidfile to the /var/run dir. A patch to the init script goes on annex.
Created attachment 121653 [details, diff] Location change of the pid file Changes the location of the pid file to support tmpfs /var/run dir
Not a baselayout issue. Plus note that you will break *lots* of stuff by moving /var/run to tmpfs; the directories there are *not* supposed to get wiped on reboot, they are created via keepdir with appropriate permissions for a reason, messing with this is not supported.
(In reply to comment #3) > Not a baselayout issue. Oh sorry.. > Plus note that you will break *lots* of stuff by moving /var/run to tmpfs; the > directories there are *not* supposed to get wiped on reboot, they are created > via keepdir with appropriate permissions for a reason, messing with this is not > supported. > Currently everything is working except ipw3945d. The programs that automatically create a dir on service start are: cups, dbus and wpa_supplicant. I wonder if this change can be considered as a future improvement to gentoo.. It is somewhat like having a dynamic /dev.
You're right, this will make a mess. BUT I've checked how things work and came to the conclusion it can be done system-wide. I'm willing to start working on it (how should I proceed from now on?). The advantages are obvious, especially because it would allow gentoo to work on embedded platforms without magnetic HD's. You also get lower disk activity without delaying the witting too much, which is good for laptops. Finally, every distro and its dog has some form of support for this.. :)
(In reply to comment #5) > Finally, every distro and its dog has some form of support for this.. :) Erm, for this argument, you might read Bug 123884, Comment #7 :P
That was quite an argue!.... :( It's not on by default as the submitter said, but there are the RAMRUN and RAMLOCK variables in debian sid (and thus in ubuntu). Check the comment before the last one: http://www.webservertalk.com/archive97-2006-10-1715404.html As for standards, I don't know if having a tmpfs /var/run or /var/lock is allowed, but something that "works all the time" can be arranged: it's a matter of gzip'ing the contents in /var/run and gunzip'ing upon boot.. just like in the /dev dir.
(In reply to comment #0) > It is better in terms of performance and power consumption to have a tmpfs > /var/run dir (as well as /tmp and /var/lock). Unfortunately it is currently > impossible to do so with ipw3945d. > > The problem is that ipw3945d is unable to create its /var/run/ipw3945d dir if > it doesn't exist. Currently the init scripts rely on that dir being already > created by the emerge process. The flaw in your thinking is simply the following: - The ipw3945d daemon is started with the userid ipw3945d - /var/run has 0775, root:root as permissions/owner So basically the ipw3945d is going to be unable to place it's initfile in /var/run, which is going to make it fail. (In reply to comment #7) > That was quite an argue!.... :( > > It's not on by default as the submitter said, but there are the RAMRUN and > RAMLOCK variables in debian sid (and thus in ubuntu). Check the comment before > the last one: http://www.webservertalk.com/archive97-2006-10-1715404.html Well, we ain't Debian and/or Ubuntu.
(In reply to comment #8) > (In reply to comment #0) > > It is better in terms of performance and power consumption to have a tmpfs > > /var/run dir (as well as /tmp and /var/lock). Unfortunately it is currently > > impossible to do so with ipw3945d. > > > > The problem is that ipw3945d is unable to create its /var/run/ipw3945d dir if > > it doesn't exist. Currently the init scripts rely on that dir being already > > created by the emerge process. > > The flaw in your thinking is simply the following: > > - The ipw3945d daemon is started with the userid ipw3945d > - /var/run has 0775, root:root as permissions/owner > > So basically the ipw3945d is going to be unable to place it's initfile in > /var/run, which is going to make it fail. Unless the init script is changed to actually test for the dir and create it. This is done by many packages, but isn't done by so many others. So I guess there should be a standard for this things. And maybe a function to "test for dir || create it with perms xyz". Instead of creating the dir on the ebuild and rely on "keep" files we should just put a function call on the init scripts. This would work _all_ the time. I can provide the function if you provide me a place in the rc libraries for it :) > (In reply to comment #7) > > That was quite an argue!.... :( > > > > It's not on by default as the submitter said, but there are the RAMRUN and > > RAMLOCK variables in debian sid (and thus in ubuntu). Check the comment before > > the last one: http://www.webservertalk.com/archive97-2006-10-1715404.html > > Well, we ain't Debian and/or Ubuntu. Of course I'm not suggesting we add some cryptic/undocumented variable to some exotic init script to do the job. I'm just suggesting we actually add some robustness to the init scripts: and this is "geek thinking", not "human thinking" :)
How is this for such a function?: # first argument is the dir name, second is the [owner[:[group]] string function var_run_dir { [ ! -e /var/run/$1 ] && mkdir /var/run/$1 [ $2 ] && fowners $2 /var/run/$1 } So for instance the dbus init script will change from this: [ ! -e /var/run/dbus ] && mkdir /var/run/dbus To this: var_run_dir dbus How neat is this? :) I guess my pidfile patch is useless... It worked because I had the wrong permissions set for /var/run. But I ditched ipw3945, so when I corrected the perms it caused no problem..
We *don't* support /var/run on tmpfs. If you dislike it, please maintain the ebuild in your own overlay. Thanks.
(In reply to comment #11) > We *don't* support /var/run on tmpfs. If you dislike it, please maintain the > ebuild in your own overlay. But now I _am_ proposing such support, _and_ providing the relevant changes in a way that _works all the time_. So who should I bug to get these changes approved? Thanks,
(In reply to comment #12) > But now I _am_ proposing such support, _and_ providing the relevant changes in > a way that _works all the time_. So who should I bug to get these changes > approved? Certainly not ipw3945d or any other ebuild maintainer.
(In reply to comment #13) > (In reply to comment #12) > > But now I _am_ proposing such support, _and_ providing the relevant changes in > > a way that _works all the time_. So who should I bug to get these changes > > approved? > > Certainly not ipw3945d or any other ebuild maintainer. > Oh sorry... Forgot to also change that..
you really need to back up broad claims like "It is better in terms of performance and power consumption" most programs write to /var/run/ at startup and never touch it again
(In reply to comment #15) > you really need to back up broad claims like "It is better in terms of > performance and power consumption" Ok, here it goes: * Writing to ram is usually faster and requires less power. The kernel manages efficiently (hopefully) the use of ram vs. disc. > most programs write to /var/run/ at startup and never touch it again * Still, checking for those files is faster, and requires no disc access. * Less disc usage means discs can be left spinned down most of the time, even starting up a process. * baselayout-2 relies on tmpfs for its internals ;) So, there is really no disadvantage (apart from the setup trouble) on using tmpfs. And still, there are some advantages. So you either win or stay the same.
you're still talking in broad useless claims of course accessing ram is faster and more power efficient, however you provide no real numbers/data to back up your statements infrequently accessed nodes or frequently *cached* nodes provide no real noticeably savings ... saying i save 0.0000001% in energy is retarded
baselayout-2 allows you to specify a list of mount points you want mounted early on in the boot process (end of localmount) it's up to you to set that list and then set up your /etc/fstab however you like
(In reply to comment #17) > you're still talking in broad useless claims > > of course accessing ram is faster and more power efficient, however you provide > no real numbers/data to back up your statements Sorry, no numbers. > infrequently accessed nodes or frequently *cached* nodes provide no real > noticeably savings ... saying i save 0.0000001% in energy is retarded My personal concern is disc usage. I have my laptop set to spindown a few seconds after no disc usage, and it is annoying to see it spin up every time it needs to check for instance the laptop-mode-* files, or the /var/run/cups/certs/ dir, etc that are stored in /var/run. So if doing a small access to the disc doesn't bring much power save at first, the fact that the discs have to spin up and stay that way for a few seconds does spend more energy, and is noticeably slower. Also, please check the gentoo power management guide on Disc Power Management, Other Tricks: http://www.gentoo.org/doc/en/power-management-guide.xml?style=printable
(In reply to comment #18) > baselayout-2 allows you to specify a list of mount points you want mounted > early on in the boot process (end of localmount) > > it's up to you to set that list and then set up your /etc/fstab however you > like > I'm sorry, but have you really read the bug report? I ask this because you didn't seem to understand what this is all about. I'll explain: > (by me) > Currently [some of] the init scripts rely on that dir being already > created by the emerge process. (...) > (by Jakub Mok) > the > directories there are *not* supposed to get wiped on reboot, they are created > via keepdir with appropriate permissions for a reason, messing with this is > not supported. (...) > (by me) > Unless the init script is changed to actually test for the dir and create it. > This is done by many packages, but isn't done by so many others. So what is needed is to replace the individual solutions that some package maintainers used by a more generic solution, and use it for all packages that require it. I'm working on it, so unless there's a _real_ reason to refuse the fix, I ask you to leave it open. I'll submit a patch to baselayout-2 with explanations soon. Thanks.
doing keepdir in /var/run is not trustworthy ... init.d scripts need to sanity check the setup of /var/run according to their needs file [again] sep bug reports about such packages
(In reply to comment #21) > doing keepdir in /var/run is not trustworthy ... Any real reason why? > file [again] sep bug reports about such packages Maintainers are generally not interested in adding such cruft to initscripts, ebuilds already take care of what's needed. See Bug 123884, comments above on this one etc. If users wipe what ebuilds installed and get missing dirs and wrong permissions, that's kinda their problem.
FWIW: http://www.pathname.com/fhs/pub/fhs-2.3.html#VARRUNRUNTIMEVARIABLEDATA <snip> This directory contains system information data describing the system since it was booted. Files under this directory must be cleared (removed or truncated as appropriate) at the beginning of the boot process. Programs may have a subdirectory of /var/run; this is encouraged for programs that use more than one run-time file. </snip> Doesn't say anything about wiping the *directories* on reboot.
yes, ive read the FHS spec adding a simple `mkdir -p` call to init.d scripts makes things nicely robust ... consider it a Gentoo requirement if you want to be anal
(In reply to comment #24) > adding a simple `mkdir -p` call to init.d scripts makes things nicely robust Simple mkdir -p won't set the needed permissions. Whatever, this doesn't change a thing wrt the fact that maintainers don't want to support it, so telling users to file bugs where they've already been WONTFIXed doesn't make sense.
(In reply to comment #25) > (In reply to comment #24) > > adding a simple `mkdir -p` call to init.d scripts makes things nicely robust > Simple mkdir -p won't set the needed permissions. Whatever, this doesn't change > a thing wrt the fact that maintainers don't want to support it, so telling > users to file bugs where they've already been WONTFIXed doesn't make sense. I'm making an applet to baselayout that allows a simple "checkdir -d /path/to/dir -o owner:group" line in the init script. I bet reasonable maintainers will support this. I'm currently on holliday, and unfortunately couldn't finish it before I came. Internet is a "scarce resource" here :) I'll submit a new bug report with patch this weekend. Anyway, thanks for the support.
