[arch-general] [PATCHES] About /var/run/ and /var/lock/ checks in daemons
Hi people! I interested to make Arch Linux suitable for use with a /var/run and /var/lock that are mounted as tmpfs. But this also helps, in the case that not mounted as tmpfs, to make more simple "purge function" for these directories at rc.sysinit step. In my case this is "just for fun!", but other users can be benefited by this, for example "netbook users". OK, i initially created rc-script patches for the packages in the extra repo that use /var/run/program-name-directory and fails if not exists. (these list was obtained with """ for x in $(find /usr/share/pkgtools/lists -type f); do egrep -l "var/run/.+" $x;done """ @@NOTE@@: I will send the patches to the FL individualy per package now, reference to this email in FL, and then copy the links to response in this email. ;) Please review it, thanks in advance. :) ** Actually work OK (/var/run) core/openswan-2.4.11-1 core/dbus-core-1.2.4-1 core/netcfg-2.1.2-1 extra/consolekit-0.3.0-3 ** Patched RC files (/var/run) extra/apache-2.2.11-2 extra/bind-9.5.0.P2-1 extra/clamav-0.94-1 extra/courier-imap-4.4.1-1 extra/courier-mta-0.60.0-1 extra/cyrus-sasl-2.1.22-10 extra/fetchmail-6.3.8-4 extra/hal-0.5.11-7 (patched for policykit) extra/laptop-mode-tools-1.47-1 extra/lighttpd-1.4.20-2 extra/mpd-0.14.1-3 extra/policykit-0.9-7 (no rc-script here, patched in hal) extra/samba-3.2.7-1 extra/wicd-1.5.8-1 ** Researched (/var/run) extra/iptraf-3.0.0-2 (Trivial patch for iptraf.c or using a profile.d/iptraf for creating a "iptraf()" or another solution) * Apparently these don't use /var/run/program-name-directory, but maybe a simple "mkdir" to rc-script for precaution. extra/bftpd-2.3-1 (The daemon uses directly /var/run/bftpd.pid) extra/networkmanager-0.7.0-1 (The daemon uses directly /var/run/NetworkManager.pid) extra/wesnoth-1.4.7-1 (this game don't have a rc-script for the daemon, if run the /usr/bin/wesnothd without /var/run/wesnothd it fails, solution: provide a rc-script) ** Pending for research (/var/run) community/pulseaudio-0.9.14-1 community/ultimate-ircd-3.0.2-1 community/xen-3.3.1-1 community/wdm-1.28-2 community/dspam-3.8.0-2 community/inn-2.4.5-3 community/gpsd-2.37-2 community/apache13-1.3.41-3 community/freeradius-2.1.3-1 community/lastfmsubmitd-0.35-1 community/selinux-pam-1.0.1-1 community/fail2ban-0.8.3-1 community/ircservices-5.0.62-3 community/p3scan-2.3.2-2 community/bind-geodns-9.4.1-1 community/jabberd14-1.6.1.1-3 ** Pending for research (/var/lock) core/dmraid-1.0.0.rc14-2 extra/sane-1.0.19-2 -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
Gerardo Exequiel Pozzi wrote:
Hi people!
I interested to make Arch Linux suitable for use with a /var/run and /var/lock that are mounted as tmpfs. But this also helps, in the case that not mounted as tmpfs, to make more simple "purge function" for these directories at rc.sysinit step.
In my case this is "just for fun!", but other users can be benefited by this, for example "netbook users".
OK, i initially created rc-script patches for the packages in the extra repo that use /var/run/program-name-directory and fails if not exists. (these list was obtained with """ for x in $(find /usr/share/pkgtools/lists -type f); do egrep -l "var/run/.+" $x;done """
@@NOTE@@: I will send the patches to the FL individualy per package now, reference to this email in FL, and then copy the links to response in this email. ;)
Please review it, thanks in advance. :)
** Actually work OK (/var/run) core/openswan-2.4.11-1 core/dbus-core-1.2.4-1 core/netcfg-2.1.2-1 extra/consolekit-0.3.0-3
** Patched RC files (/var/run) extra/apache-2.2.11-2 extra/bind-9.5.0.P2-1 extra/clamav-0.94-1 extra/courier-imap-4.4.1-1 extra/courier-mta-0.60.0-1 extra/cyrus-sasl-2.1.22-10 extra/fetchmail-6.3.8-4 extra/hal-0.5.11-7 (patched for policykit) extra/laptop-mode-tools-1.47-1 extra/lighttpd-1.4.20-2 extra/mpd-0.14.1-3 extra/policykit-0.9-7 (no rc-script here, patched in hal) extra/samba-3.2.7-1 extra/wicd-1.5.8-1
** Researched (/var/run) extra/iptraf-3.0.0-2 (Trivial patch for iptraf.c or using a profile.d/iptraf for creating a "iptraf()" or another solution)
* Apparently these don't use /var/run/program-name-directory, but maybe a simple "mkdir" to rc-script for precaution. extra/bftpd-2.3-1 (The daemon uses directly /var/run/bftpd.pid) extra/networkmanager-0.7.0-1 (The daemon uses directly /var/run/NetworkManager.pid)
extra/wesnoth-1.4.7-1 (this game don't have a rc-script for the daemon, if run the /usr/bin/wesnothd without /var/run/wesnothd it fails, solution: provide a rc-script)
** Pending for research (/var/run) community/pulseaudio-0.9.14-1 community/ultimate-ircd-3.0.2-1 community/xen-3.3.1-1 community/wdm-1.28-2 community/dspam-3.8.0-2 community/inn-2.4.5-3 community/gpsd-2.37-2 community/apache13-1.3.41-3 community/freeradius-2.1.3-1 community/lastfmsubmitd-0.35-1 community/selinux-pam-1.0.1-1 community/fail2ban-0.8.3-1 community/ircservices-5.0.62-3 community/p3scan-2.3.2-2 community/bind-geodns-9.4.1-1 community/jabberd14-1.6.1.1-3
** Pending for research (/var/lock) core/dmraid-1.0.0.rc14-2 extra/sane-1.0.19-2
** Patched RC files (/var/run) extra/apache-2.2.11-2 http://bugs.archlinux.org/task/13225 extra/bind-9.5.0.P2-1 http://bugs.archlinux.org/task/13204 extra/clamav-0.94-1 http://bugs.archlinux.org/task/13226 extra/courier-imap-4.4.1-1 http://bugs.archlinux.org/task/13227 extra/courier-mta-0.60.0-1 http://bugs.archlinux.org/task/13228 extra/cyrus-sasl-2.1.22-10 http://bugs.archlinux.org/task/13229 extra/fetchmail-6.3.8-4 http://bugs.archlinux.org/task/13230 extra/hal-0.5.11-7 (patched for policykit) http://bugs.archlinux.org/task/13211 extra/laptop-mode-tools-1.47-1 http://bugs.archlinux.org/task/13231 extra/lighttpd-1.4.20-2 http://bugs.archlinux.org/task/13232 extra/mpd-0.14.1-3 http://bugs.archlinux.org/task/13233 extra/policykit-0.9-7 (no rc-script here, patched in hal) http://bugs.archlinux.org/task/13211 extra/samba-3.2.7-1 http://bugs.archlinux.org/task/13234 extra/wicd-1.5.8-1 http://bugs.archlinux.org/task/13235 -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
On Thu, 2009-02-12 at 05:51 -0200, Gerardo Exequiel Pozzi wrote:
Hi people!
I interested to make Arch Linux suitable for use with a /var/run and /var/lock that are mounted as tmpfs. But this also helps, in the case that not mounted as tmpfs, to make more simple "purge function" for these directories at rc.sysinit step.
In my case this is "just for fun!", but other users can be benefited by this, for example "netbook users".
OK, i initially created rc-script patches for the packages in the extra repo that use /var/run/program-name-directory and fails if not exists. (these list was obtained with """ for x in $(find /usr/share/pkgtools/lists -type f); do egrep -l "var/run/.+" $x;done """
@@NOTE@@: I will send the patches to the FL individualy per package now, reference to this email in FL, and then copy the links to response in this email. ;)
Please review it, thanks in advance. :)
** Actually work OK (/var/run) core/openswan-2.4.11-1 core/dbus-core-1.2.4-1 core/netcfg-2.1.2-1 extra/consolekit-0.3.0-3
** Patched RC files (/var/run) extra/apache-2.2.11-2 extra/bind-9.5.0.P2-1 extra/clamav-0.94-1 extra/courier-imap-4.4.1-1 extra/courier-mta-0.60.0-1 extra/cyrus-sasl-2.1.22-10 extra/fetchmail-6.3.8-4 extra/hal-0.5.11-7 (patched for policykit) extra/laptop-mode-tools-1.47-1 extra/lighttpd-1.4.20-2 extra/mpd-0.14.1-3 extra/policykit-0.9-7 (no rc-script here, patched in hal) extra/samba-3.2.7-1 extra/wicd-1.5.8-1
** Researched (/var/run) extra/iptraf-3.0.0-2 (Trivial patch for iptraf.c or using a profile.d/iptraf for creating a "iptraf()" or another solution)
* Apparently these don't use /var/run/program-name-directory, but maybe a simple "mkdir" to rc-script for precaution. extra/bftpd-2.3-1 (The daemon uses directly /var/run/bftpd.pid) extra/networkmanager-0.7.0-1 (The daemon uses directly /var/run/NetworkManager.pid)
extra/wesnoth-1.4.7-1 (this game don't have a rc-script for the daemon, if run the /usr/bin/wesnothd without /var/run/wesnothd it fails, solution: provide a rc-script)
** Pending for research (/var/run) community/pulseaudio-0.9.14-1 community/ultimate-ircd-3.0.2-1 community/xen-3.3.1-1 community/wdm-1.28-2 community/dspam-3.8.0-2 community/inn-2.4.5-3 community/gpsd-2.37-2 community/apache13-1.3.41-3 community/freeradius-2.1.3-1 community/lastfmsubmitd-0.35-1 community/selinux-pam-1.0.1-1 community/fail2ban-0.8.3-1 community/ircservices-5.0.62-3 community/p3scan-2.3.2-2 community/bind-geodns-9.4.1-1 community/jabberd14-1.6.1.1-3
** Pending for research (/var/lock) core/dmraid-1.0.0.rc14-2 extra/sane-1.0.19-2
If this requires patching so many packages, and given the fact that /var/run on tmpfs is not default in archlinux, maybe you should try building /var/run from an initial directory or something like that. This is also what I use for my OpenBSD router which runs from compactflash and has /var mounted on ramdisk.
Excerpts from Jan de Groot's message of Thu Feb 12 08:59:41 +0100 2009:
I interested to make Arch Linux suitable for use with a /var/run and /var/lock that are mounted as tmpfs. But this also helps, in the case that not mounted as tmpfs, to make more simple "purge function" for these directories at rc.sysinit step.
In my case this is "just for fun!", but other users can be benefited by this, for example "netbook users". If this requires patching so many packages, and given the fact
On Thu, 2009-02-12 at 05:51 -0200, Gerardo Exequiel Pozzi wrote: that /var/run on tmpfs is not default in archlinux, maybe you should try building /var/run from an initial directory or something like that. This is also what I use for my OpenBSD router which runs from compactflash and has /var mounted on ramdisk.
I have a setup on my netbook where the whole /var is mounted as tmpfs and rsynced from and to real directory (/var-sync in my case) on boot/shutdown. Patches to rc.sysinit and rc.shutdown follow. [Note that whenever you update initscripts, you need to patch at least rc.shutdown before rebooting :)]
Excerpts from Jan Spakula's message of Thu Feb 12 09:22:00 +0100 2009:
Excerpts from Jan de Groot's message of Thu Feb 12 08:59:41 +0100 2009:
I interested to make Arch Linux suitable for use with a /var/run and /var/lock that are mounted as tmpfs. But this also helps, in the case that not mounted as tmpfs, to make more simple "purge function" for these directories at rc.sysinit step.
In my case this is "just for fun!", but other users can be benefited by this, for example "netbook users". If this requires patching so many packages, and given the fact
On Thu, 2009-02-12 at 05:51 -0200, Gerardo Exequiel Pozzi wrote: that /var/run on tmpfs is not default in archlinux, maybe you should try building /var/run from an initial directory or something like that. This is also what I use for my OpenBSD router which runs from compactflash and has /var mounted on ramdisk.
I have a setup on my netbook where the whole /var is mounted as tmpfs and rsynced from and to real directory (/var-sync in my case) on boot/shutdown. Patches to rc.sysinit and rc.shutdown follow. [Note that whenever you update initscripts, you need to patch at least rc.shutdown before rebooting :)]
Well apparently attachments are scrubbed, so here you go http://rafb.net/p/ePKlct55.html http://rafb.net/p/yDQSPc95.html Advantages are mainly on netbooks, which have limited number of writes to their ssd drives, this eliminated a big source of uncontrolled writes.
I also have these as tmpfs: /var/cache/songbird /var/cache/firefox /var/lock /var/log /var/run /var/tmp /tmp I created a simple daemon to sync the files. I don't need patching: just add it to the daemon array. I don't care about all except for logs. Here is the small daemon: #!/bin/bash now=`date +"%Y%m%d_%Hh%m"` case "$1" in stop) mkdir -p /logs_backup/$now cp -Rp /var/log/* /logs_backup/$now/ ;; start) ;; *) echo 'Usage: /etc/rc.d/logsbackup stop' exit 1 ;; esac It copies the log to /logs_backup/ with a new directory containing the date. Because of this logs don't get overwritten. You need to check them manually though. You don't want log to take all ssd space :) 2009/2/12 Jan Spakula <jan.spakula@gmx.com>
Excerpts from Jan de Groot's message of Thu Feb 12 08:59:41 +0100 2009:
I interested to make Arch Linux suitable for use with a /var/run and /var/lock that are mounted as tmpfs. But this also helps, in the case that not mounted as tmpfs, to make more simple "purge function" for these directories at rc.sysinit step.
In my case this is "just for fun!", but other users can be benefited by this, for example "netbook users". If this requires patching so many packages, and given the fact
On Thu, 2009-02-12 at 05:51 -0200, Gerardo Exequiel Pozzi wrote: that /var/run on tmpfs is not default in archlinux, maybe you should
Excerpts from Jan Spakula's message of Thu Feb 12 09:22:00 +0100 2009: try
building /var/run from an initial directory or something like that. This is also what I use for my OpenBSD router which runs from compactflash and has /var mounted on ramdisk.
I have a setup on my netbook where the whole /var is mounted as tmpfs and rsynced from and to real directory (/var-sync in my case) on boot/shutdown. Patches to rc.sysinit and rc.shutdown follow. [Note that whenever you update initscripts, you need to patch at least rc.shutdown before rebooting :)]
Well apparently attachments are scrubbed, so here you go http://rafb.net/p/ePKlct55.html http://rafb.net/p/yDQSPc95.html
Advantages are mainly on netbooks, which have limited number of writes to their ssd drives, this eliminated a big source of uncontrolled writes.
Jan Spakula wrote:
Excerpts from Jan Spakula's message of Thu Feb 12 09:22:00 +0100 2009:
Excerpts from Jan de Groot's message of Thu Feb 12 08:59:41 +0100 2009:
On Thu, 2009-02-12 at 05:51 -0200, Gerardo Exequiel Pozzi wrote:
I interested to make Arch Linux suitable for use with a /var/run and /var/lock that are mounted as tmpfs. But this also helps, in the case that not mounted as tmpfs, to make more simple "purge function" for these directories at rc.sysinit step.
In my case this is "just for fun!", but other users can be benefited by this, for example "netbook users".
If this requires patching so many packages, and given the fact that /var/run on tmpfs is not default in archlinux, maybe you should try building /var/run from an initial directory or something like that. This is also what I use for my OpenBSD router which runs from compactflash and has /var mounted on ramdisk.
I have a setup on my netbook where the whole /var is mounted as tmpfs and rsynced from and to real directory (/var-sync in my case) on boot/shutdown. Patches to rc.sysinit and rc.shutdown follow. [Note that whenever you update initscripts, you need to patch at least rc.shutdown before rebooting :)]
Well apparently attachments are scrubbed, so here you go http://rafb.net/p/ePKlct55.html http://rafb.net/p/yDQSPc95.html
Advantages are mainly on netbooks, which have limited number of writes to their ssd drives, this eliminated a big source of uncontrolled writes.
Hi Jan Spakula, Check the rsync manpage for the --inplace parameter, this reduces the amout of writes to the destination, ideal for files that grows "in appended form" like most of /var/log files. But again read the manpage for what are the _risk_ of using this ;) -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
Jan de Groot wrote:
On Thu, 2009-02-12 at 05:51 -0200, Gerardo Exequiel Pozzi wrote:
Hi people!
I interested to make Arch Linux suitable for use with a /var/run and /var/lock that are mounted as tmpfs. But this also helps, in the case that not mounted as tmpfs, to make more simple "purge function" for these directories at rc.sysinit step.
In my case this is "just for fun!", but other users can be benefited by this, for example "netbook users".
OK, i initially created rc-script patches for the packages in the extra repo that use /var/run/program-name-directory and fails if not exists. (these list was obtained with """ for x in $(find /usr/share/pkgtools/lists -type f); do egrep -l "var/run/.+" $x;done """
@@NOTE@@: I will send the patches to the FL individualy per package now, reference to this email in FL, and then copy the links to response in this email. ;)
Please review it, thanks in advance. :)
If this requires patching so many packages, and given the fact that /var/run on tmpfs is not default in archlinux, maybe you should try building /var/run from an initial directory or something like that. This is also what I use for my OpenBSD router which runs from compactflash and has /var mounted on ramdisk.
OK JGC, I know that Arch Linux don't support these directories as tmpfs or "all empty" by default, but with these trivial patches to rc-script can support it. Not only this is usefull for "tmpfs", maybe for other things. Ok the FHS recomendations, about /var/run as how to interpret the FHS's recommendations can lead to different paths: For example (PATH 1) if we understand that /var/run at startup must be completely clean, these patches are useful. But (PATH 2 "The current Arch" ) if we interpret that there should be no files, but there may be directories. The number of packets that need to be changed I do not think is problem, also need not be changed immediately. Maintainers can apply the patch for the next update when new version is released. For example, the current rc-script of HAL that you mantain, it check that the /var/run/hald/ and subdirs are created, but these are always created by the package. :) Why not do the same with other packages? Personally it is not something I need, just occurred to me that it might be a good idea, I take my time researching what packages were needed, and I did. Sorry if I bothered. Thanks for your time. (and sorry for my bad english) -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
On Thu, 2009-02-12 at 20:42 -0200, Gerardo Exequiel Pozzi wrote:
I know that Arch Linux don't support these directories as tmpfs or "all empty" by default, but with these trivial patches to rc-script can support it. Not only this is usefull for "tmpfs", maybe for other things.
Having initscripts for daemons just to create this path (policykit) or let other packages create the required directories instead (hal that creates policykit directories?) isn't the most trivial thing in my opinion.
On Fri, Feb 13, 2009 at 1:42 AM, Jan de Groot <jan@jgc.homeip.net> wrote:
On Thu, 2009-02-12 at 20:42 -0200, Gerardo Exequiel Pozzi wrote:
I know that Arch Linux don't support these directories as tmpfs or "all empty" by default, but with these trivial patches to rc-script can support it. Not only this is usefull for "tmpfs", maybe for other things.
Having initscripts for daemons just to create this path (policykit) or let other packages create the required directories instead (hal that creates policykit directories?) isn't the most trivial thing in my opinion.
Still, I think this had potential. We can already see that it would be useful on some netbooks, so I think it's a step in the right direction. While this may be a non-trivial change, I do see the benefit, so I'd like to implement this _in theory_ at some point. So keep up the good work and we'll see where we can get with this. I'd recommend filing a feature request in the bug tracker
Aaron Griffin wrote:
On Fri, Feb 13, 2009 at 1:42 AM, Jan de Groot <jan@jgc.homeip.net> wrote:
On Thu, 2009-02-12 at 20:42 -0200, Gerardo Exequiel Pozzi wrote:
I know that Arch Linux don't support these directories as tmpfs or "all empty" by default, but with these trivial patches to rc-script can support it. Not only this is usefull for "tmpfs", maybe for other things.
Having initscripts for daemons just to create this path (policykit) or let other packages create the required directories instead (hal that creates policykit directories?) isn't the most trivial thing in my opinion.
Still, I think this had potential. We can already see that it would be useful on some netbooks, so I think it's a step in the right direction.
While this may be a non-trivial change, I do see the benefit, so I'd like to implement this _in theory_ at some point. So keep up the good work and we'll see where we can get with this. I'd recommend filing a feature request in the bug tracker
Thank you very much for good efforts. :) Well, in the case of non-trivial patch of PolicyKit, this apparently will become obsolete in the near future and will be replaced by a new implementation polkit [1] / eggdbus [2]. It is possible that the situation will change radically. I will create a feature request to the FS that globalized packages that are required to be friendly with the desired behavior. Like in the initial email. Again, thanks for your time, good luck ;) [1] http://lists.freedesktop.org/archives/polkit-devel/2009-January/000070.html [2] http://mail.gnome.org/archives/gtk-devel-list/2008-December/msg00059.html -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
On Sat, Feb 14, 2009 at 3:39 AM, Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote:
I will create a feature request to the FS that globalized packages that are required to be friendly with the desired behavior. Like in the initial email.
Again, thanks for your time, good luck ;)
I was looking at your bug reports when I saw the following criticism : http://bugs.archlinux.org/task/13231#comment39323 It has nothing to do with laptop-mode-tools (I will blame dolby for that :)), so I thought I would comment here instead. I agree with phrakture's general comment that bug reports with only an url are not nice, but as djgera said, this one is particular as a multi feature request. However, here are the steps I would have done : 1) start the discussion on the arch-general ML as he did 2) see if there is enough interest for it, then post a meta feature request with the same content than the original mail 3) if there is a common agreement, then post single feature request for each packages in order to implement the meta feature request (I believe the big feature request could depend on each single feature request). So far you did 1), then you just reached 2), but in the meantime you already made 3). I think this was a mistake. Imo, it should not be a decision taken by each developer separately for his own packages. It should be a common agreement made by developers that rc scripts should be written that way (in theory) to support tmpfs on /var/*. If you don't have this, it does not make sense to make this flood of bug reports, as they could all be closed as invalid. See http://bugs.archlinux.org/task/13225 for example. Now we already have 2 devs, JGC and Pierre who seem to be against this proposal, and who recommended you to just populate /var/run and others based on an initial directory. Then two users reported they were already using tmpfs with no problems. Jan Spakula posted his modified rc.sysinit and rc.shutdown, and Nicolas said he just wrote a separate rc script to do that syncing job. I am not against your proposal, but you did not make clear what its advantages are, and why it is worth the additional complexity?
Xavier wrote:
Now we already have 2 devs, JGC and Pierre who seem to be against this proposal, and who recommended you to just populate /var/run and others based on an initial directory. Then two users reported they were already using tmpfs with no problems. Jan Spakula posted his modified rc.sysinit and rc.shutdown, and Nicolas said he just wrote a separate rc script to do that syncing job. I am not against your proposal, but you did not make clear what its advantages are, and why it is worth the additional complexity?
As I said earlier, depending on how we interpret the standards of the FHS. And here I __apologize__, my English for write is not very good because it is not my native language, in fact I am using the google translator to help me (hehe), so if in any part of my message tone offense was not, not is my intention offend any user and your proposed solutions. [@] If the initial content of the /var/run must be completely empty at boot or must persist directories but not files. This can be seen in the behavior of various programs. Some create the appropriate directory in /var/run and work well, but fail if no other before. Some programs, when completed, left files in there, and others are "well educated" and delete its contents. So, here comes in the task of the startup script to delete those files. My personal interpretation is that the directories in there, are generated at runtime, and these can be eliminated without any problems. (Clearly this is not true, as I said above many programs fail) Well, therefore, the benefit of each program is responsible for creating the temporary directory, if that does not exist, it allows two things: * The contents of the directory can be deleted without any exceptions. * This directory can be mounted as tmpfs with the simple addition of a line in the fstab and also has the advantage of removing the need to erase the contents in the boot. This behavior of erase or not, could be controlled with a simple check fstab or switch in rc.conf (this also applies to /var/lock (1777) and the most problematic for deletion: the "Mr /tmp") * Any other purpose. [@] Ok that cleared, I will say this: The solution of copying temporal/run-time data of the /var/run for mounting this as tmpfs i do not think a clean solution, but if it works of course :) My idea behind this is that each program do its work to function properly. Thanks for your time ;) -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
Gerardo Exequiel Pozzi wrote:
Hi people!
I interested to make Arch Linux suitable for use with a /var/run and /var/lock that are mounted as tmpfs. But this also helps, in the case that not mounted as tmpfs, to make more simple "purge function" for these directories at rc.sysinit step.
In my case this is "just for fun!", but other users can be benefited by this, for example "netbook users".
OK, i initially created rc-script patches for the packages in the extra repo that use /var/run/program-name-directory and fails if not exists. (these list was obtained with """ for x in $(find /usr/share/pkgtools/lists -type f); do egrep -l "var/run/.+" $x;done """
@@NOTE@@: I will send the patches to the FL individualy per package now, reference to this email in FL, and then copy the links to response in this email. ;)
Please review it, thanks in advance. :)
What exactly are the advantages of running /var/run and /var/lock on tmpfs? Glenn
RedShift wrote:
Gerardo Exequiel Pozzi wrote:
Hi people!
I interested to make Arch Linux suitable for use with a /var/run and /var/lock that are mounted as tmpfs. But this also helps, in the case that not mounted as tmpfs, to make more simple "purge function" for these directories at rc.sysinit step.
In my case this is "just for fun!", but other users can be benefited by this, for example "netbook users".
OK, i initially created rc-script patches for the packages in the extra repo that use /var/run/program-name-directory and fails if not exists. (these list was obtained with """ for x in $(find /usr/share/pkgtools/lists -type f); do egrep -l "var/run/.+" $x;done """
@@NOTE@@: I will send the patches to the FL individualy per package now, reference to this email in FL, and then copy the links to response in this email. ;)
Please review it, thanks in advance. :)
What exactly are the advantages of running /var/run and /var/lock on tmpfs?
Glenn
Well, frankly, from my point of view, since the system directories /var/run, /var/lock and /tmp should be empty (in that order of priority). Have it as tmpfs, simplifies the way these are purged on startup (rc.sysinit), in a way that removes the need to run "find, rm" on them. Particularly in /tmp, where the removal of these files, can be dangerous. But today, the command "rm" progress, not left behind quite a number of vulnerabilities. For example: rm -rf /tmp/.* (that is used in rc.sysinit) in the old days it was dangerous, as it descended recursively deleting the parent directory. Today rm refused to use the forms "rm- r ." and "rm -r ..' and similars and ignore these special directories. This also are applied to the /var/lock that have 1777 perms like /tmp. At least, this is the use that I give. Other people may give it another utility. My two cents ;) (sorry my bad english) -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
I interested to make Arch Linux suitable for use with a /var/run and /var/lock that are mounted as tmpfs. But this also helps, in the case that not mounted as tmpfs, to make more simple "purge function" for these directories at rc.sysinit step.
This could also help to run the root filesystem (/) as read-only. I've not tried this with ArchLinux but have done it with Slackware previously. The benefit of a read-only root is you can share it between several network computers or between different resource containers (kind of virtualization). Has anyone tried this. -- damjan
tmpfs used to be used for /tmp before, the reason it got removed as tmpfs was that a tmpfs would get clogged and also had to be setup in /etc/fstab which many others didn't know how to do or did incorrectly, thus leading to lots of difficulties for users. I can't remember exactly, but it was something like this. It was thus decided that the most KISS thing to do was to just have it as a normal dir. Noone remembers this? The moment you expand the system is the moment you introduce another thing to learn... -K
Hi people!
I interested to make Arch Linux suitable for use with a /var/run and /var/lock that are mounted as tmpfs. But this also helps, in the case that not mounted as tmpfs, to make more simple "purge function" for these directories at rc.sysinit step.
In my case this is "just for fun!", but other users can be benefited by this, for example "netbook users".
OK, i initially created rc-script patches for the packages in the extra repo that use /var/run/program-name-directory and fails if not exists. (these list was obtained with """ for x in $(find /usr/share/pkgtools/lists -type f); do egrep -l "var/run/.+" $x;done """
@@NOTE@@: I will send the patches to the FL individualy per package now, reference to this email in FL, and then copy the links to response in this email. ;)
Please review it, thanks in advance. :)
** Actually work OK (/var/run) core/openswan-2.4.11-1 core/dbus-core-1.2.4-1 core/netcfg-2.1.2-1 extra/consolekit-0.3.0-3
** Patched RC files (/var/run) extra/apache-2.2.11-2 extra/bind-9.5.0.P2-1 extra/clamav-0.94-1 extra/courier-imap-4.4.1-1 extra/courier-mta-0.60.0-1 extra/cyrus-sasl-2.1.22-10 extra/fetchmail-6.3.8-4 extra/hal-0.5.11-7 (patched for policykit) extra/laptop-mode-tools-1.47-1 extra/lighttpd-1.4.20-2 extra/mpd-0.14.1-3 extra/policykit-0.9-7 (no rc-script here, patched in hal) extra/samba-3.2.7-1 extra/wicd-1.5.8-1
** Researched (/var/run) extra/iptraf-3.0.0-2 (Trivial patch for iptraf.c or using a profile.d/iptraf for creating a "iptraf()" or another solution)
* Apparently these don't use /var/run/program-name-directory, but maybe a simple "mkdir" to rc-script for precaution. extra/bftpd-2.3-1 (The daemon uses directly /var/run/bftpd.pid) extra/networkmanager-0.7.0-1 (The daemon uses directly /var/run/NetworkManager.pid)
extra/wesnoth-1.4.7-1 (this game don't have a rc-script for the daemon, if run the /usr/bin/wesnothd without /var/run/wesnothd it fails, solution: provide a rc-script)
** Pending for research (/var/run) community/pulseaudio-0.9.14-1 community/ultimate-ircd-3.0.2-1 community/xen-3.3.1-1 community/wdm-1.28-2 community/dspam-3.8.0-2 community/inn-2.4.5-3 community/gpsd-2.37-2 community/apache13-1.3.41-3 community/freeradius-2.1.3-1 community/lastfmsubmitd-0.35-1 community/selinux-pam-1.0.1-1 community/fail2ban-0.8.3-1 community/ircservices-5.0.62-3 community/p3scan-2.3.2-2 community/bind-geodns-9.4.1-1 community/jabberd14-1.6.1.1-3
** Pending for research (/var/lock) core/dmraid-1.0.0.rc14-2 extra/sane-1.0.19-2
hello I think that what Gerardo wanted to say is to make POSSIBLE (and optional) the mount of /va/lock /var/run and /tmp as tmpfs, right now you cannot do it because many startup script doesnt create their own directories specially for /var/run the idea is change those script so you can start your system with an empty /var/run (and friends) in this case you may (not have) change some lines in fstab to mount /var/run as tmpfs the advantages of this is that you can increase the life of some netbooks (the SD harddrive have limited writings) thanks On Sun, Feb 15, 2009 at 12:39 AM, Kristoffer Fossgård <kfs1@online.no> wrote:
tmpfs used to be used for /tmp before, the reason it got removed as tmpfs was that a tmpfs would get clogged and also had to be setup in /etc/fstab which many others didn't know how to do or did incorrectly, thus leading to lots of difficulties for users. I can't remember exactly, but it was something like this. It was thus decided that the most KISS thing to do was to just have it as a normal dir.
Noone remembers this?
The moment you expand the system is the moment you introduce another thing to learn...
-K
Hi people!
I interested to make Arch Linux suitable for use with a /var/run and /var/lock that are mounted as tmpfs. But this also helps, in the case that not mounted as tmpfs, to make more simple "purge function" for these directories at rc.sysinit step.
In my case this is "just for fun!", but other users can be benefited by this, for example "netbook users".
OK, i initially created rc-script patches for the packages in the extra repo that use /var/run/program-name-directory and fails if not exists. (these list was obtained with """ for x in $(find /usr/share/pkgtools/lists -type f); do egrep -l "var/run/.+" $x;done """
@@NOTE@@: I will send the patches to the FL individualy per package now, reference to this email in FL, and then copy the links to response in this email. ;)
Please review it, thanks in advance. :)
** Actually work OK (/var/run) core/openswan-2.4.11-1 core/dbus-core-1.2.4-1 core/netcfg-2.1.2-1 extra/consolekit-0.3.0-3
** Patched RC files (/var/run) extra/apache-2.2.11-2 extra/bind-9.5.0.P2-1 extra/clamav-0.94-1 extra/courier-imap-4.4.1-1 extra/courier-mta-0.60.0-1 extra/cyrus-sasl-2.1.22-10 extra/fetchmail-6.3.8-4 extra/hal-0.5.11-7 (patched for policykit) extra/laptop-mode-tools-1.47-1 extra/lighttpd-1.4.20-2 extra/mpd-0.14.1-3 extra/policykit-0.9-7 (no rc-script here, patched in hal) extra/samba-3.2.7-1 extra/wicd-1.5.8-1
** Researched (/var/run) extra/iptraf-3.0.0-2 (Trivial patch for iptraf.c or using a profile.d/iptraf for creating a "iptraf()" or another solution)
* Apparently these don't use /var/run/program-name-directory, but maybe a simple "mkdir" to rc-script for precaution. extra/bftpd-2.3-1 (The daemon uses directly /var/run/bftpd.pid) extra/networkmanager-0.7.0-1 (The daemon uses directly /var/run/NetworkManager.pid)
extra/wesnoth-1.4.7-1 (this game don't have a rc-script for the daemon, if run the /usr/bin/wesnothd without /var/run/wesnothd it fails, solution: provide a rc-script)
** Pending for research (/var/run) community/pulseaudio-0.9.14-1 community/ultimate-ircd-3.0.2-1 community/xen-3.3.1-1 community/wdm-1.28-2 community/dspam-3.8.0-2 community/inn-2.4.5-3 community/gpsd-2.37-2 community/apache13-1.3.41-3 community/freeradius-2.1.3-1 community/lastfmsubmitd-0.35-1 community/selinux-pam-1.0.1-1 community/fail2ban-0.8.3-1 community/ircservices-5.0.62-3 community/p3scan-2.3.2-2 community/bind-geodns-9.4.1-1 community/jabberd14-1.6.1.1-3
** Pending for research (/var/lock) core/dmraid-1.0.0.rc14-2 extra/sane-1.0.19-2
hello I think that what Gerardo wanted to say is to make POSSIBLE (and optional) the mount of /va/lock /var/run and /tmp as tmpfs, right now you cannot do it because many startup script doesnt create their own directories specially for /var/run the idea is change those script so you can start your system with an empty /var/run (and friends) in this case you may (not have) change some lines in fstab to mount /var/run as tmpfs the advantages of this is that you can increase the life of some netbooks (the SD harddrive have limited writings) thanks On Sun, Feb 15, 2009 at 12:39 AM, Kristoffer Fossgård <kfs1@online.no> wrote:
tmpfs used to be used for /tmp before, the reason it got removed as tmpfs was that a tmpfs would get clogged and also had to be setup in /etc/fstab which many others didn't know how to do or did incorrectly, thus leading to lots of difficulties for users. I can't remember exactly, but it was something like this. It was thus decided that the most KISS thing to do was to just have it as a normal dir.
Noone remembers this?
The moment you expand the system is the moment you introduce another thing to learn...
-K
Hi people!
I interested to make Arch Linux suitable for use with a /var/run and /var/lock that are mounted as tmpfs. But this also helps, in the case that not mounted as tmpfs, to make more simple "purge function" for these directories at rc.sysinit step.
In my case this is "just for fun!", but other users can be benefited by this, for example "netbook users".
OK, i initially created rc-script patches for the packages in the extra repo that use /var/run/program-name-directory and fails if not exists. (these list was obtained with """ for x in $(find /usr/share/pkgtools/lists -type f); do egrep -l "var/run/.+" $x;done """
@@NOTE@@: I will send the patches to the FL individualy per package now, reference to this email in FL, and then copy the links to response in this email. ;)
Please review it, thanks in advance. :)
** Actually work OK (/var/run) core/openswan-2.4.11-1 core/dbus-core-1.2.4-1 core/netcfg-2.1.2-1 extra/consolekit-0.3.0-3
** Patched RC files (/var/run) extra/apache-2.2.11-2 extra/bind-9.5.0.P2-1 extra/clamav-0.94-1 extra/courier-imap-4.4.1-1 extra/courier-mta-0.60.0-1 extra/cyrus-sasl-2.1.22-10 extra/fetchmail-6.3.8-4 extra/hal-0.5.11-7 (patched for policykit) extra/laptop-mode-tools-1.47-1 extra/lighttpd-1.4.20-2 extra/mpd-0.14.1-3 extra/policykit-0.9-7 (no rc-script here, patched in hal) extra/samba-3.2.7-1 extra/wicd-1.5.8-1
** Researched (/var/run) extra/iptraf-3.0.0-2 (Trivial patch for iptraf.c or using a profile.d/iptraf for creating a "iptraf()" or another solution)
* Apparently these don't use /var/run/program-name-directory, but maybe a simple "mkdir" to rc-script for precaution. extra/bftpd-2.3-1 (The daemon uses directly /var/run/bftpd.pid) extra/networkmanager-0.7.0-1 (The daemon uses directly /var/run/NetworkManager.pid)
extra/wesnoth-1.4.7-1 (this game don't have a rc-script for the daemon, if run the /usr/bin/wesnothd without /var/run/wesnothd it fails, solution: provide a rc-script)
** Pending for research (/var/run) community/pulseaudio-0.9.14-1 community/ultimate-ircd-3.0.2-1 community/xen-3.3.1-1 community/wdm-1.28-2 community/dspam-3.8.0-2 community/inn-2.4.5-3 community/gpsd-2.37-2 community/apache13-1.3.41-3 community/freeradius-2.1.3-1 community/lastfmsubmitd-0.35-1 community/selinux-pam-1.0.1-1 community/fail2ban-0.8.3-1 community/ircservices-5.0.62-3 community/p3scan-2.3.2-2 community/bind-geodns-9.4.1-1 community/jabberd14-1.6.1.1-3
** Pending for research (/var/lock) core/dmraid-1.0.0.rc14-2 extra/sane-1.0.19-2
Gerardo Exequiel Pozzi wrote:
Hi people!
I interested to make Arch Linux suitable for use with a /var/run and /var/lock that are mounted as tmpfs. But this also helps, in the case that not mounted as tmpfs, to make more simple "purge function" for these directories at rc.sysinit step.
In my case this is "just for fun!", but other users can be benefited by this, for example "netbook users".
OK, i initially created rc-script patches for the packages in the extra repo that use /var/run/program-name-directory and fails if not exists. (these list was obtained with """ for x in $(find /usr/share/pkgtools/lists -type f); do egrep -l "var/run/.+" $x;done """
@@NOTE@@: I will send the patches to the FL individualy per package now, reference to this email in FL, and then copy the links to response in this email. ;)
Please review it, thanks in advance. :)
You are going about it the wrong way. Instead of putting mkdir's and touches all over the initscripts, modify /etc/rc.d/functions to take into account an empty /var/run and /var/lock. For those who think it'll be advantageous for SSD's (for their lifetime), I don't see much writes in /var/run or /var/lock other than during startup. Glenn
participants (10)
-
Aaron Griffin
-
Damjan Georgievski
-
Gerardo Exequiel Pozzi
-
Jan de Groot
-
Jan Spakula
-
Juan Diego
-
Kristoffer Fossgård
-
Nicolas Bigaouette
-
RedShift
-
Xavier