Re: 2.4 vs. 2.6 (was: Re: Moving /var/run to a tmpfs?)
On 9/17/06, Hendrik Sattler [EMAIL PROTECTED] wrote: A good hint for such cases is to actually report such bugs to the driver developers. Did you? You must have pretty uncommon hardware, though, as many use 2.6 kernels without such problems... I have an old server with 2.4 because 2.6 won't run on it. Not big deal, it doesn't need 2.6 anyway... -- Martín Ferrari
Re: Moving /var/run to a tmpfs?
Hi On Tue, 19 Sep 2006 21:52:12 +0200 Martijn van Oosterhout [EMAIL PROTECTED] wrote: Odd, I always thought is was because C did not have enough int types: char1 bytes short 2 bytes int 4 bytes long 8 bytes If you make an int 8 bytes, you have to find some other way of indicating one of the shorter types (short short maybe? or long char?). Nothing says long has to be bigger that int, only thing which is defined is: sizeof(short) = sizeof(int) = sizeof(long) so having short, int, long of same size is not a problem. -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Re: Moving /var/run to a tmpfs?
On 9/20/06, Michal Čihař [EMAIL PROTECTED] wrote: char1 bytes short 2 bytes int 4 bytes long 8 bytes Nothing says long has to be bigger that int, only thing which is defined is: sizeof(short) = sizeof(int) = sizeof(long) so having short, int, long of same size is not a problem. I think you're missing the point. If you make an int 8 bytes, what are you going to call 4 byte integers? If you call them short, what are you going to call 2 byte integers? Anyway, the link to the paper posted in this thread has many much better arguments. Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/
Re: Moving /var/run to a tmpfs?
Hi On Wed, 20 Sep 2006 12:07:40 +0200 Martijn van Oosterhout [EMAIL PROTECTED] wrote: On 9/20/06, Michal Čihař [EMAIL PROTECTED] wrote: Nothing says long has to be bigger that int, only thing which is defined is: sizeof(short) = sizeof(int) = sizeof(long) so having short, int, long of same size is not a problem. I think you're missing the point. If you make an int 8 bytes, what are you going to call 4 byte integers? If you call them short, what are you going to call 2 byte integers? There is something what forces you to have 4 byte and 2 byte types defined? Anyway, the link to the paper posted in this thread has many much better arguments. I just wanted to point out that ISO C defines only relationship of sizes of those types and nothing else. The other assumptions come from things we got used to, because they were valid for ILP32 model which has been used most of time. PS: No need to CC me. -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Re: Moving /var/run to a tmpfs?
On Tue, Sep 19, 2006 at 10:49:14PM +0200, Hendrik Sattler wrote: with an ILP64 data model. However, the question should rather be: *why* compilers do not define int to be 64bit on a 64bit architecture? And the answer is simple: Yes int should be 64bit on a 64bit architecture, since int is defined as the architectures natural size data type. However, it is mostly not because of the elsewise massively increasing porting-expenses due to many programmers who never thought about it and simply assumed int to be 32bit. So, your metaphor implicitely leads to exactly the same answer ;) The answer is that the LP64 scheme is used and not ILP64. There is a good and detailed explanation available: http://www.unix.org/whitepapers/64bit.html This does not seem to be related to having /var/run on a tmpfs or even with Debian development in general. Please at least change the Subject, or, better yet, move it to another mailing list. thanks, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Moving /var/run to a tmpfs?
Am Dienstag 19 September 2006 04:01 schrieb Miles Bader: Steve Langasek [EMAIL PROTECTED] writes: It is also clear that this is how many maintainers have understood it, because as you yourself have noticed, there are many packages that assume they can ship directories in /var/run and have them remain available after reboot. :) I think it's more likely that the average maintainer just never thought about the issue, and did what they did because it works. I.e. the same reason many people used to assume int was 32 bits. When 64-bit processors became common, lots of programs broke. The solution to that was to educate programmers to be more careful and assume less, not to retroactively add silly restrictions to the definition of int. Which OS combination does not define int to be 32bit on a 64bit architecture? long should better be 64bit then as many assume that you can cast a pointer into a long and back (e.g. timer in the linux kernel has a long for private data and not a void*, really sick). HS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Moving /var/run to a tmpfs?
Hendrik Sattler [EMAIL PROTECTED] wrote: Which OS combination does not define int to be 32bit on a 64bit architecture? This is mainly compiler-, not primarily OS-dependent. And: all compilers with an ILP64 data model. However, the question should rather be: *why* compilers do not define int to be 64bit on a 64bit architecture? And the answer is simple: Yes int should be 64bit on a 64bit architecture, since int is defined as the architectures natural size data type. However, it is mostly not because of the elsewise massively increasing porting-expenses due to many programmers who never thought about it and simply assumed int to be 32bit. So, your metaphor implicitely leads to exactly the same answer ;) regards Mario -- snupidity bjmg: ja, logik ist mein fachgebiet. das liegt im gen uepsie in welchem? snupidity im zweiten X -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Moving /var/run to a tmpfs?
Hendrik Sattler [EMAIL PROTECTED] writes: Which OS combination does not define int to be 32bit on a 64bit architecture? long should better be 64bit then as many assume that you can cast a pointer into a long and back (e.g. timer in the linux kernel has a long for private data and not a void*, really sick). I meant long, not int. Sorry. -Miles -- People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird. -- Donald Knuth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Moving /var/run to a tmpfs?
On 9/19/06, Mario 'BitKoenig' Holbe [EMAIL PROTECTED] wrote: However, the question should rather be: *why* compilers do not define int to be 64bit on a 64bit architecture? And the answer is simple: Yes int should be 64bit on a 64bit architecture, since int is defined as the architectures natural size data type. However, it is mostly not because of the elsewise massively increasing porting-expenses due to many programmers who never thought about it and simply assumed int to be 32bit. Odd, I always thought is was because C did not have enough int types: char1 bytes short 2 bytes int 4 bytes long 8 bytes If you make an int 8 bytes, you have to find some other way of indicating one of the shorter types (short short maybe? or long char?). Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Moving /var/run to a tmpfs?
Am Dienstag 19 September 2006 20:25 schrieb Mario 'BitKoenig' Holbe: Hendrik Sattler [EMAIL PROTECTED] wrote: Which OS combination does not define int to be 32bit on a 64bit architecture? This is mainly compiler-, not primarily OS-dependent. And: all compilers with an ILP64 data model. However, the question should rather be: *why* compilers do not define int to be 64bit on a 64bit architecture? And the answer is simple: Yes int should be 64bit on a 64bit architecture, since int is defined as the architectures natural size data type. However, it is mostly not because of the elsewise massively increasing porting-expenses due to many programmers who never thought about it and simply assumed int to be 32bit. So, your metaphor implicitely leads to exactly the same answer ;) The answer is that the LP64 scheme is used and not ILP64. There is a good and detailed explanation available: http://www.unix.org/whitepapers/64bit.html HS pgplj2Msoq7Bg.pgp Description: PGP signature
Re: Moving /var/run to a tmpfs?
* Marco d'Itri [EMAIL PROTECTED] [2006-09-16 20:20]: etch requires a 2.6 kernel too. No. Debian won't provide a 2.4 kernel for etch but it works fine with self built ones. yours Martin -- [EMAIL PROTECTED] Debian GNU/Linux - The Universal Operating System Rhamphoryncus guess lp0 on fire finally got taken literally.. [on 20.11.2002 satie.debian.org burnt down due to a fire in the Twente university in Enschede, NL]
Re: Moving /var/run to a tmpfs?
* Andreas Metzler [EMAIL PROTECTED] [2006-09-16 19:42]: It has been pointed out to me in http://bugs.debian.org/387699 that syvinit is going to move /var/run to a tmpfs to solve a long-standing issue, having some place to store state information before partitions are checked and mounted. (I do not know how they are going to handle the fact that /var/run is needed before /var is mounted, mount --move requires kernel 2.6 afaict.) I prefere to have this optional, propably defaulting to yes as I don't want to waste a single byte for /var/run or /var/lock on low memory systems (which run 2.4 for the smaller memory footprint) so I can still change it without manual intervention. yours Martin -- [EMAIL PROTECTED] Debian GNU/Linux - The Universal Operating System kevc oh oh, can i get we.are.the.knights.who.say.ni ? Clint .no -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Policy process (was: [Pkg-sysvinit-devel] Re: Moving /var/run to a tmpfs?)
On Sun, Sep 17, 2006 at 11:43:18AM -0700, Russ Allbery wrote: Copying the debian-policy list, since this conversation is basically about that. Kurt Roeckx [EMAIL PROTECTED] writes: I don't think policy changes need to be seconded. We have a policy team that should decide on what comes in policy and what not. Although, it more looks like it's just 1 person doing all the work. I sometimes feel that they go to slow which changing things, and I'm not really sure it's a good or bad thing. Some of those currently open bugs against the policy package, like your ~ in version numbers, really shouldn't be a problem to get into the policy. I don't think anybody has a problem with it. I think it's just that no new version of the policy has been made yet. Well, policy-process is still shipped with the debian-policy package, and my experience in the past is that when I follow that process, the changes go into Policy fairly quickly. Certainly seconding would show that someone reviewed the wording of my proposed ~ patch and has confirmed that it sounds like an accurate and implementable description of their behavior. Maybe Manoj could weigh in on how he sees the current process? That document says things like: The group that decides on policy should be the group of developers on the debian-policy mailing list, which is how it was always done; so the group of policy maintainers have no real power over policy. And that is not the impression I get from it. Also, I believe this has changed since they are now delegates of the DPL: http://lists.debian.org/debian-devel-announce/2005/07/msg2.html But it's unclear to me what this exactly means. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Moving /var/run to a tmpfs?
Steve Langasek [EMAIL PROTECTED] writes: It is also clear that this is how many maintainers have understood it, because as you yourself have noticed, there are many packages that assume they can ship directories in /var/run and have them remain available after reboot. :) I think it's more likely that the average maintainer just never thought about the issue, and did what they did because it works. I.e. the same reason many people used to assume int was 32 bits. When 64-bit processors became common, lots of programs broke. The solution to that was to educate programmers to be more careful and assume less, not to retroactively add silly restrictions to the definition of int. -miles -- Any man who is a triangle, has thee right, when in Cartesian Space, to have angles, which when summed, come to know more, nor no less, than nine score degrees, should he so wish. [TEMPLE OV THEE LEMUR] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Moving /var/run to a tmpfs?
On Sat September 16 2006 16:56, Petter Reinholdtsen wrote: [Steve Langasek] However, that's not the same thing as saying it's ok for sysvinit to *make* /var/run a tmpfs on the admin's behalf. I think it's pretty clear that this violates the letter of the FHS, and such a change needs to be considered carefully. I fail to see how it violates the letter of the FHS. It is as far as I can see unspecified what kind of file systems will be used, and also if directories will persist across boots. The reason I believe it is important to have some writable file system available at the very beginning of the boot is that there are programs running when kernel modules are loaded by udev that need a place to store state information. At the moment, there is no location to do that, and strange things can happen when the coldplug events happen early in the boot. To fix it, some tmpfs area need to be mounted in mountkernfs.sh. This issue has been discussed here on the list a few months ago, without any conclusion being reached. I do not want us to release etch with a boot system unable to handle detected hardware properly, so I decided to fix this now. Also, it is useful to make it easier to set up stateless workstations using Debian (aka diskless machines ala LTSP), and storing state information in a RAM file system make this a lot easier. Sounds fine, if one has enough RAM to spare. How big can /var/run get? Could such a change limit the usefulness of low mem systems? Is it feasible to create a tmpfs based /var/run during boot then move its contents to a disk based /var/run (if that is the admin's the preference) when /var becomes available? - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Moving /var/run to a tmpfs?
In gmane.linux.debian.devel.general Kurt Roeckx [EMAIL PROTECTED] wrote: Anyway, it would be useful if you didn't have to login on merkel to be able to see your list. I suggest you either submit those files to the BTS, or put it on people.debian.org or something. http://people.debian.org/~ametzler/ cu andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Moving /var/run to a tmpfs?
On Sun, Sep 17, 2006 at 11:10:33AM +0200, Mario 'BitKoenig' Holbe wrote: are checked and mounted. (I do not know how they are going to handle the fact that /var/run is needed before /var is mounted, mount --move requires kernel 2.6 afaict.) Relying on 2.6-only features for this is IMHO a no-go. 2.2 as well as 2.4 are maintained kernel-trees and just because the kernel-team seems to like to live on the bleeding-edge of still heavily-changing kernels only, there is no need for admins of stable systems to do the same. There is no requirement that 2.2 kernels be supported by the etch userspace, and indeed for most release architectures there is no such support in glibc for etch. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Moving /var/run to a tmpfs?
Andreas Metzler [EMAIL PROTECTED] wrote:
It has been pointed out to me in http://bugs.debian.org/387699
that syvinit is going to move /var/run to a tmpfs to solve a long-standing
Yes, having the opportunity to mount /var/run on a tmpfs would be really
nice. Please consider the same for /var/lock, too. Since both IMHO
require a policy-change, it would be one go for both :)
are checked and mounted. (I do not know how they are going to handle
the fact that /var/run is needed before /var is mounted, mount --move
requires kernel 2.6 afaict.)
Relying on 2.6-only features for this is IMHO a no-go. 2.2 as well as
2.4 are maintained kernel-trees and just because the kernel-team seems
to like to live on the bleeding-edge of still heavily-changing kernels
only, there is no need for admins of stable systems to do the same.
This is nice, but is going to break packages that either ship a
subdirectory of /var/run in the deb or generate it once in
postinst and rely on its existence afterwards.
Yes. Anything shipped with a package (and thus being under package
manager's control) being removed afterwards is IMHO a no-go, too.
Therefor, the Debian policy should explicitely forbid packages to ship
files/directories within /var/run and /var/lock and require them to be
created at runtime instead.
The whole thing is grey territory in FHS, but still I tend to think
that sysvinit should somehow preserve the (empty) directory structure
of /var/run through reboots. Either by using some find+tar magic after
mounting /usr or by keeping /var/run a real directory and keep the
pre-mount stuff in /var/run/pre-mount. Other thoughts?
Those are all ugly hacks. Preserving structures like this will most
likely open room for race conditions/inconsistencies, i.e. systems that
die after the installation of some packages and before the mirror-magic
kept their state.
A somewhat more stable ugly hack could be to use any of the fs-merge
approaches (unionfs, translucency, ...) to get directories written to
the persistent layer while getting files written to the transient layer.
However, even this remains an ugly hack :)
And the approach to require packages to ship their /var/{run,lock}
directories somewhere else and get them mirrored to their real positions
automagically IMHO is ugly as well and requires quite the same effort as
providing some debhelpers that deal with on-the-fly creation/removal,
while the latter is the most clean approach, IMHO.
regards
Mario
--
Why did the tachyon cross the road?
Because it was on the other side.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Moving /var/run to a tmpfs?
Steve Langasek [EMAIL PROTECTED] wrote: It is clear /to me/ from the juxtaposition of these two sentences that the FHS intends for programs to be allowed to create such subdirectories without them being removed at the beginning of the boot process. It is also clear Well, it would then probably be interesting to see how Ubuntu deals with their FHS-incompatibility - except the filing of bugs against Debian packages, of course :) regards Mario -- reich sein heisst nicht, einen Ferrari zu kaufen, sondern einen zu verbrennen Dietmar Wischmeier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Moving /var/run to a tmpfs?
On Sunday 17 September 2006 11:23, Steve Langasek wrote: On Sun, Sep 17, 2006 at 11:10:33AM +0200, Mario 'BitKoenig' Holbe wrote: Relying on 2.6-only features for this is IMHO a no-go. 2.2 as well as 2.4 are maintained kernel-trees and just because the kernel-team seems to like to live on the bleeding-edge of still heavily-changing kernels only, there is no need for admins of stable systems to do the same. There is no requirement that 2.2 kernels be supported by the etch userspace, and indeed for most release architectures there is no such support in glibc for etch. It does make a case for keeping a package like initrd-tools around though. pgp91xXafQQR0.pgp Description: PGP signature
Re: Moving /var/run to a tmpfs?
On Sep 17, Frans Pop [EMAIL PROTECTED] wrote: It does make a case for keeping a package like initrd-tools around though. The problem with supporting old kernels is not just the need to maintain a few packages like initrd-tools or modutils, but that every important package cannot rely on features of modern kernels: inotify, sysfs, etc. This means that Debian as a whole will either lack support for features relying on these kernel features or will become more and more complex due to compatibility code. Please consider carefully the effects of advocating support for old kernels. -- ciao, Marco signature.asc Description: Digital signature
Re: [Pkg-sysvinit-devel] Re: Moving /var/run to a tmpfs?
[Mario Holbe] Is it? Yes, mounting tmpfs on /var/run/ and /var/lock/ is supposed to work, and packages not handling it need to be fixed. And as you can see in /etc/init.d/, quite a few packages got this right already. A few got still it haven't been adjusted to work like that, and we should get those fixed soon. So, as long as the Debian policy doesn't handle this, I agree that we should update the policy to document this fact. because if I would fix this, the submitter would surely come and require me to handle the magic disappearing of files under /usr/bin or directories under /usr/lib or whatever. If you believe this, you must have misunderstood what make /var/run/ and /var/lock/ special. They are supposed to be cleaned at boot, and this feature is not shared with /usr/bin/, /usr/lib or whatever. It is this property that make it OK to mount a tmpfs as /var/run/ and /var/lock/. Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
2.4 vs. 2.6 (was: Re: Moving /var/run to a tmpfs?)
Marco d'Itri [EMAIL PROTECTED] wrote: The problem with supporting old kernels is not just the need to maintain 2.4 is not old, it's just stable :) a few packages like initrd-tools or modutils, but that every important package cannot rely on features of modern kernels: inotify, sysfs, etc. Well, I live quite well with Debian unstable on top of 2.4 on my workstation. It seems there are not so much important packages that really rely on modern features. This means that Debian as a whole will either lack support for features relying on these kernel features or will become more and more complex due to compatibility code. Well, if there are really packages that demand on 2.6, they just can depend on kernel-image-2.6, this is no problem at all. I agree with you that package maintainers should not be forced to develop 2.4-compatibility on their own, if upstream doesn't do it itself. However, from my point of view, quite all relevant software just *does* support 2.4 and 2.6 upstream anyways. So there is virtually no need to increase complexity. Please consider carefully the effects of advocating support for old kernels. IIRC, Linus declared feature-freeze for 2.6.16 first. To be honest, I cannot see any feature-freeze until now. I personally decided to give 2.6 a first try on my workstation when 2.6.18 is out. However, as long as I can easily freeze my machine just by doing really simple disk-I/O tasks (which just happened when I had a need to boot into a Knoppix), I will definitely not consider it to run on my servers. regards Mario -- File names are infinite in length where infinity is set to 255 characters. -- Peter Collinson, The Unix File System -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.4 vs. 2.6 (was: Re: Moving /var/run to a tmpfs?)
Am Sonntag 17 September 2006 12:28 schrieb Mario 'BitKoenig' Holbe: However, as long as I can easily freeze my machine just by doing really simple disk-I/O tasks (which just happened when I had a need to boot into a Knoppix), I will definitely not consider it to run on my servers. A good hint for such cases is to actually report such bugs to the driver developers. Did you? You must have pretty uncommon hardware, though, as many use 2.6 kernels without such problems... HS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Moving /var/run to a tmpfs?
[Petter Reinholdtsen] Here is the list of packages in sarge with directories in /var/run/, according to the file on merkel: I got the commands used by Andreas Metzler to extract packages in sarge with files or directories in /var/run/, and ran the it on etch. These are the 159 packages: anon-proxy aolserver4 apache2 asterisk autofs backuppc bacula bcron bincimap-run bind9 bindgraph binkd bld blootbot bnetd bopm bricolage caudium cfs cipe clamav courier courier-authlib couriergraph crack cupsys cyrus-imapd-2.2 cyrus21-imapd dancer-ircd dancer-services davfs2 dbus diald distmp3 dovecot dropbear echolot fai firebird2 flumotion freeradius geneweb glibc gnue-appserver gnunet greylistd gsmlib hal havp heartbeat-2 hostapd hotplug hsqldb hula inn inn2 ipband ipsec-tools iptraf ircd-hybrid ircd-irc2 ircd-ircu isdnutils ivman jabber jabber-common jftpgw john kannel kolab-cyrus-imapd laptop-net lastfmsubmitd libapache-mod-backhand libchipcard2 linesrv linuxlogo lyskom-server mailman mailscanner masqmail mgetty midentd mindi mixmaster mldonkey mobilemesh mon mtink munin mysql-dfsg-5.0 nagios nagios2 ndtpd newsx nut oinkmaster oops openct openntpd openssh openssh-krb5 openswan p3scan peercast pipsecd polipo pootle portreserve pppconfig prelude-manager proftpd proxsmtp psad pure-ftpd pymsnt qpsmtpd quagga quickml radvd rageircd remote-tty roundup roxen4 runit runit-run runit-services samba samhain scanlogd screen sendmail siproxd slidentd slimp3 smokeping socklog spfmilter spong spread stunnel super sympa tenshi tetrinetx tiger torrus twoftpd uml-utilities usbmount userv util-vserver vde vpnc vsftpd wackamole whereami xsp yaws zabbix Some of these will handle /var/run/ as a tmpfs. I converted the commands to a script, in case you want to do this analysis later. #!/bin/sh dist=etch tmpdir=/home/pere cd /org/ftp.root/debian zgrep ^Filename: dists/$dist/main/binary-i386/Packages.gz | \ sed -e 's/^Filename: //' $tmpdir/filenames.$dist.stable for i in `cat $tmpdir/filenames.$dist.stable` ; do if nice -19 dpkg --contents $i | grep -q /var/run ; then echo $i fi done $tmpdir/contains_var_run.$dist for i in `cat $tmpdir/contains_var_run.$dist` ; do if nice -19 dpkg --contents $i | grep -q /var/run/. ; then echo $i fi done $tmpdir/contains_var_run.subdir.$dist Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Moving /var/run to a tmpfs?
On Sep 17, Petter Reinholdtsen [EMAIL PROTECTED] wrote: I got the commands used by Andreas Metzler to extract packages in sarge with files or directories in /var/run/, and ran the it on etch. These are the 159 packages: Not all of them are buggy, e.g. ssh, inn and inn2 have the directory in the package but also create it in the init script if needed. -- ciao, Marco signature.asc Description: Digital signature
Re: [Pkg-sysvinit-devel] Re: Moving /var/run to a tmpfs?
Petter Reinholdtsen [EMAIL PROTECTED] writes: [Mario Holbe] So, as long as the Debian policy doesn't handle this, I agree that we should update the policy to document this fact. It would be quite nice to have more people participating in the Policy process in general. There are a fair number of proposals, but not a lot of people reading proposals, helping achieve consensus, and seconding. For example, I haven't gotten any responses to my patch to document ~ in version numbers, and I'm not sure what happened to the menu policy overhaul. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Moving /var/run to a tmpfs?
On Sat, Sep 16, 2006 at 06:54:05PM +0200, Andreas Metzler wrote: The whole thing is grey territory in FHS, but still I tend to think that sysvinit should somehow preserve the (empty) directory structure of /var/run through reboots. Definitely. When using chroots, it is not uncommon that some directories containing UNIX-domain sockets (like /var/run/saslauthd, /var/run/mysql, /var/run/postgresql) are bind-mounted to 5-10 different locations. Right now all that information can be kept in one single location: /etc/fstab. Having to edit the init scripts instead would be quite inconvenient. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-sysvinit-devel] Re: Moving /var/run to a tmpfs?
On Sun, Sep 17, 2006 at 09:55:46AM -0700, Russ Allbery wrote: Petter Reinholdtsen [EMAIL PROTECTED] writes: [Mario Holbe] So, as long as the Debian policy doesn't handle this, I agree that we should update the policy to document this fact. It would be quite nice to have more people participating in the Policy process in general. There are a fair number of proposals, but not a lot of people reading proposals, helping achieve consensus, and seconding. For example, I haven't gotten any responses to my patch to document ~ in version numbers, and I'm not sure what happened to the menu policy overhaul. I don't think policy changes need to be seconded. We have a policy team that should decide on what comes in policy and what not. Although, it more looks like it's just 1 person doing all the work. I sometimes feel that they go to slow which changing things, and I'm not really sure it's a good or bad thing. Some of those currently open bugs against the policy package, like your ~ in version numbers, really shouldn't be a problem to get into the policy. I don't think anybody has a problem with it. I think it's just that no new version of the policy has been made yet. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Policy process (was: [Pkg-sysvinit-devel] Re: Moving /var/run to a tmpfs?)
Copying the debian-policy list, since this conversation is basically about that. Kurt Roeckx [EMAIL PROTECTED] writes: I don't think policy changes need to be seconded. We have a policy team that should decide on what comes in policy and what not. Although, it more looks like it's just 1 person doing all the work. I sometimes feel that they go to slow which changing things, and I'm not really sure it's a good or bad thing. Some of those currently open bugs against the policy package, like your ~ in version numbers, really shouldn't be a problem to get into the policy. I don't think anybody has a problem with it. I think it's just that no new version of the policy has been made yet. Well, policy-process is still shipped with the debian-policy package, and my experience in the past is that when I follow that process, the changes go into Policy fairly quickly. Certainly seconding would show that someone reviewed the wording of my proposed ~ patch and has confirmed that it sounds like an accurate and implementable description of their behavior. Maybe Manoj could weigh in on how he sees the current process? -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Policy process (was: [Pkg-sysvinit-devel] Re: Moving /var/run to a tmpfs?)
On Sun, Sep 17, 2006 at 11:43:18AM -0700, Russ Allbery wrote: Kurt Roeckx [EMAIL PROTECTED] writes: I don't think policy changes need to be seconded. We have a policy team that should decide on what comes in policy and what not. Although, it more looks like it's just 1 person doing all the work. I sometimes feel that they go to slow which changing things, and I'm not really sure it's a good or bad thing. Some of those currently open bugs against the policy package, like your ~ in version numbers, really shouldn't be a problem to get into the policy. I don't think anybody has a problem with it. I think it's just that no new version of the policy has been made yet. Well, policy-process is still shipped with the debian-policy package, and my experience in the past is that when I follow that process, the changes go into Policy fairly quickly. Certainly seconding would show that someone reviewed the wording of my proposed ~ patch and has confirmed that it sounds like an accurate and implementable description of their behavior. Hello, As a debian-policy denizen, I am quick to second proposal I like. However, here this a purely the description of what dpkg do. What matter is whether the text is faithful to the implementation, not whether I like it or not, and i don't feel qualified to vet the text. However, there is at least 2 dpkg maintainers, they are very qualified to check it, and I expected they would second the proposal. If they did not see it, I suggest to forward it to them asking for review and second. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Moving /var/run to a tmpfs?
Marco d'Itri [EMAIL PROTECTED] wrote: Not all of them are buggy, e.g. ssh, inn and inn2 have the directory in the package but also create it in the init script if needed. I would consider this a bug, when a package ships things which it expects to magically disappear and where it thus cares about re-creating them all the time. There's just no need to ship them in the package then at all. Well... a minor bug probably :) regards Mario -- () Ascii Ribbon Campaign /\ Support plain text e-mail -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-sysvinit-devel] Re: Moving /var/run to a tmpfs?
On Sun, 17 Sep 2006 the mental interface of Russ Allbery told: Petter Reinholdtsen [EMAIL PROTECTED] writes: [Mario Holbe] So, as long as the Debian policy doesn't handle this, I agree that we should update the policy to document this fact. It would be quite nice to have more people participating in the Policy process in general. There are a fair number of proposals, but not a lot of people reading proposals, helping achieve consensus, and seconding. For example, I haven't gotten any responses to my patch to document ~ in version numbers, and I'm not sure what happened to the menu policy overhaul. I've experienced problems using tilde in Filenames: The problem is caused by the fact that there is a ~ in the directory name. Libtool uses ~ as a separator. [1] [1]http://autoconf-archive.cryp.to/patch_libtool_changing_cmds_ifs.html Elimar -- Alles was viel bedacht wird ist bedenklich!;-) Friedrich Nietzsche -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Moving /var/run to a tmpfs?
On Sun, Sep 17, 2006 at 11:02:41PM +0200, Mario 'BitKoenig' Holbe wrote: Marco d'Itri [EMAIL PROTECTED] wrote: Not all of them are buggy, e.g. ssh, inn and inn2 have the directory in the package but also create it in the init script if needed. I would consider this a bug, when a package ships things which it expects to magically disappear and where it thus cares about re-creating them all the time. There's just no need to ship them in the package then at all. Well... a minor bug probably :) That's not a bug, that's fairly reasonable behavious - in the case that /var/run *isn't* a tmpfs, the package knows about the directory, the postrm script can purge stuff from it, and the directory gets cleaned away like it should. Is /var/run being *mandated* as having to be tmpfs? -- Brett Parker -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-sysvinit-devel] Re: Moving /var/run to a tmpfs?
On Sun, 17 Sep 2006, Mario 'BitKoenig' Holbe wrote: cons, and issues and difficulties... would it probably make sense to split the discussion about /var/x being able to be tmpfs'ed out and just choose another location for the intended place-to-store-things-while- nothing-else-is-mounted-rw? Yes. I have just done that. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Moving /var/run to a tmpfs?
On Sun, 17 Sep 2006, Marco d'Itri wrote: On Sep 17, Petter Reinholdtsen [EMAIL PROTECTED] wrote: I got the commands used by Andreas Metzler to extract packages in sarge with files or directories in /var/run/, and ran the it on etch. These are the 159 packages: Not all of them are buggy, e.g. ssh, inn and inn2 have the directory in the package but also create it in the init script if needed. ditto for sendmail -- Rick Nelson I've heard a Jew and a Muslim argue in a Damascus cafe with less passion than the emacs wars. -- Ronald Florence [EMAIL PROTECTED] in [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Moving /var/run to a tmpfs?
Hello, It has been pointed out to me in http://bugs.debian.org/387699 that syvinit is going to move /var/run to a tmpfs to solve a long-standing issue, having some place to store state information before partitions are checked and mounted. (I do not know how they are going to handle the fact that /var/run is needed before /var is mounted, mount --move requires kernel 2.6 afaict.) This is nice, but is going to break packages that either ship a subdirectory of /var/run in the deb or generate it once in postinst and rely on its existence afterwards. Contents*gz and therefore packages.d.o do not list (empty) directories but only files, so I cannot yet say how many packages this is actually going to break, I have listed those I found on my system in the bug-report noted above. The whole thing is grey territory in FHS, but still I tend to think that sysvinit should somehow preserve the (empty) directory structure of /var/run through reboots. Either by using some find+tar magic after mounting /usr or by keeping /var/run a real directory and keep the pre-mount stuff in /var/run/pre-mount. Other thoughts? cu andreas -- The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal vision of the emperor's, and its inclusion in this work does not constitute tacit approval by the author or the publisher for any such projects, howsoever undertaken.(c) Jasper Ffforde -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Moving /var/run to a tmpfs?
On Sat, Sep 16, 2006 at 06:54:05PM +0200, Andreas Metzler wrote: Hello, It has been pointed out to me in http://bugs.debian.org/387699 that syvinit is going to move /var/run to a tmpfs to solve a long-standing issue, having some place to store state information before partitions are checked and mounted. (I do not know how they are going to handle the fact that /var/run is needed before /var is mounted, mount --move requires kernel 2.6 afaict.) This is nice, but is going to break packages that either ship a subdirectory of /var/run in the deb or generate it once in postinst and rely on its existence afterwards. Contents*gz and therefore packages.d.o do not list (empty) directories but only files, so I cannot yet say how many packages this is actually going to break, I have listed those I found on my system in the bug-report noted above. Afaik, Ubuntu is already using this. As a result, I've actually got a bug against my package submitted because it didn't handle it. My package now recreates the directory from the init script if it's missing, and I'm not really happy about that solution. I'm not really sure what the right thing to do is. Maybe the FHS should be made clear on what you can expect from /var/run. I guess it would be useful to know what people now put in there. I know some daemons just want to have empty directory they can chroot to. Maybe they should put that somewhere else? I have no idea what others are putting there. Anyway, it would be useful if you didn't have to login on merkel to be able to see your list. I suggest you either submit those files to the BTS, or put it on people.debian.org or something. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Moving /var/run to a tmpfs?
On Sep 16, Andreas Metzler [EMAIL PROTECTED] wrote: are checked and mounted. (I do not know how they are going to handle the fact that /var/run is needed before /var is mounted, mount --move requires kernel 2.6 afaict.) etch requires a 2.6 kernel too. This is nice, but is going to break packages that either ship a subdirectory of /var/run in the deb or generate it once in postinst and rely on its existence afterwards. I think it was considered a bug even before this, because admins may locally mount a tmpfs on /var/run. The whole thing is grey territory in FHS, but still I tend to think that sysvinit should somehow preserve the (empty) directory structure of /var/run through reboots. Either by using some find+tar magic after Not worth the added complexity. Fix the bugs instead of adding workaround which will need to be maintained forever. -- ciao, Marco signature.asc Description: Digital signature
Re: Moving /var/run to a tmpfs?
Hi Andreas! You wrote: The whole thing is grey territory in FHS, but still I tend to think that sysvinit should somehow preserve the (empty) directory structure of /var/run through reboots. Either by using some find+tar magic after mounting /usr or by keeping /var/run a real directory and keep the pre-mount stuff in /var/run/pre-mount. Other thoughts? Ubuntu has had a tmpfs on /var/run for quite a while, afaik. So, I assume that fixes for the kind of problems you mentioned have been merged back into the debian packages already. -- Kind regards, ++ | Bas Zoetekouw | GPG key: 0644fab7 | || Fingerprint: c1f5 f24c d514 3fec 8bf6 | | [EMAIL PROTECTED], [EMAIL PROTECTED] | a2b1 2bae e41f 0644 fab7 | ++ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Moving /var/run to a tmpfs?
On Sat, Sep 16, 2006 at 08:19:24PM +0200, Marco d'Itri wrote: are checked and mounted. (I do not know how they are going to handle the fact that /var/run is needed before /var is mounted, mount --move requires kernel 2.6 afaict.) etch requires a 2.6 kernel too. No, it uses 2.6 by default, but still supports (as good as possible) 2.4 kernels, AFAIK Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Moving /var/run to a tmpfs?
[Kurt Roeckx] Afaik, Ubuntu is already using this. As a result, I've actually got a bug against my package submitted because it didn't handle it. My package now recreates the directory from the init script if it's missing, and I'm not really happy about that solution. Why not? 'mkdir -p' (or 'install -d' if you need a non-root owner or custom permissions) is a quick one-liner. I'd much rather my system didn't assume that /var/run or /tmp or /dev/shm will retain anything at all between reboots. signature.asc Description: Digital signature
Re: Moving /var/run to a tmpfs?
On Sat, Sep 16, 2006 at 02:21:19PM -0500, Peter Samuelson wrote: [Kurt Roeckx] Afaik, Ubuntu is already using this. As a result, I've actually got a bug against my package submitted because it didn't handle it. My package now recreates the directory from the init script if it's missing, and I'm not really happy about that solution. Why not? 'mkdir -p' (or 'install -d' if you need a non-root owner or custom permissions) is a quick one-liner. I'd much rather my system didn't assume that /var/run or /tmp or /dev/shm will retain anything at all between reboots. The FHS says we can create directories under /var/run that are application specific. It also says that all files should be removed or truncated. It does not say anything about directories being removed. On the other hand, about /tmp it very clear and says: Programs must not assume that any files or directories in /tmp are preserve between invocations of the program. If I create a directory in /var/run, I expect it to stay there. And if I can't expect that, I'd like to see that documented somewhere. kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-sysvinit-devel] Re: Moving /var/run to a tmpfs?
[Kurt Roeckx] I'm not really sure what the right thing to do is. Maybe the FHS should be made clear on what you can expect from /var/run. I believe it is quite clear that the sysadmin is allowed to use tmpfs as /var/run/, and that packages which fail to support this has a bug. To test the impact, I had a look at the packages installed on my test machines, as well as some of the packages listed in the file on merkel: OK: alsa-base 1.0.12-1: init.d script creates /var/run/alsa/ apache2-common 2.0.55-4.2: init.d script creates /var/run/apache2/ autofs 4.1.4-11: init.d script creates /var/run/autofs/ cupsys 1.2.3-1: init.d script creates /var/run/cups/ dbus 0.92-2: init.d script creates /var/run/dbus/ dirmngr 0.9.6-1: init.d script creates /var/run/dirmngr hal 0.5.7.1-2: /etc/dbus-1/event.d/20hal creates /var/run/hal/ mpd 0.11.5-9: package no longer uses subdir in /var/run/ openssh-server 4.3p2-3: init.d script creates /var/run/sshd/ postgresql 7.5.21: package no longer uses subdir in /var/run/ ssh 4.3p2-3: Just a dummy package Not checked, missing or uninstallable in sid hotplug: /var/run/usb dbus-1: /var/run/dbus Unsure slapd 2.3.25-1: Uses /var/run/slapd/, but not sure if it creates it. Need fix: pppconfig 2.3.14: /etc/ppp/ip-*.d/0dns-* expect /var/run/pppconfig to exist greylistd 0.8.3.1: init.d expect /var/run/greylistd pident 3.0.19.ds1-1: store pid in /var/run/identd/ but is started via inetd! clamav-daemon 0.88.4-2: init.d script expect /var/run/clamav/ crack-md5: Symlink /var/run/Crack/bin/debian, but nothing uses it? samba 3.0.23c-1: init.d script expect /var/run/samba/ Anyway, it would be useful if you didn't have to login on merkel to be able to see your list. I suggest you either submit those files to the BTS, or put it on people.debian.org or something. Here is the list of packages in sarge with directories in /var/run/, according to the file on merkel: alsa-base aolserver aolserver4 apache2-common asterisk autofs bacula-common bacula-director-common bacula-fd bacula-sd bincimap-run bind9 bindgraph binkd bld bnetd bopm caudium cfs chipcard-tools clamav-base courier-authdaemon courier-base courier-pcpcouriergraph crack crack-md5 cupsys cyrus21-common dancer-ircd dancer-services dbbalancer dbus-1 diald dirmngr distmp3 dovecot-common dropbear echolot fai firebird2-server-common freeradius gnunet greylistd gwtp hal hostapd hotplug inn inn2 ipband iptraf ircd-hybrid ircd-irc2 ircd-ircu isdnlog jabber jabber-common jftpgw john laptop-net libapache-mod-backhand linesrv lwresd lyskom-server mailman mailscanner messagewall mgetty-fax midentd mindi mixmaster mobilemesh mon mtink munin munin-node mysql-server mysql-server-4.1 nagios-common ndtpd newsx nut oinkmaster openct openntpd p3scan pgpool pipsecd pkcipe polipo postgresql pppconfig proftpd proftpd-ldap proftpd-mysql proftpd-pgsql psad pure-ftpd-common quagga quickml racoon radvd roundup roxen4 runit runit-run samba samhain scalemail screen sendmail-bin siproxd slapd slidentd slimp3 smokeping socklog-run spong-client spong-server spread ssh ssh-krb5 stunnel super sympa tetrinetx tiger totd twoftpd-run uml-utilities usbmount userv util-vserver vpnc vsftpd wackamole whereami Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-sysvinit-devel] Re: Moving /var/run to a tmpfs?
On Saturday 16 September 2006 23:07, Petter Reinholdtsen wrote: I agree that this need to be documented. We work on some notes for the sysvinit package, and will include it there. Sounds to me like this belongs in policy. pgpTZyxVfGvin.pgp Description: PGP signature
Re: [Pkg-sysvinit-devel] Re: Moving /var/run to a tmpfs?
On Sat, Sep 16, 2006 at 09:38:07PM +0200, Petter Reinholdtsen wrote: [Kurt Roeckx] I'm not really sure what the right thing to do is. Maybe the FHS should be made clear on what you can expect from /var/run. I believe it is quite clear that the sysadmin is allowed to use tmpfs as /var/run/, and that packages which fail to support this has a bug. However, that's not the same thing as saying it's ok for sysvinit to *make* /var/run a tmpfs on the admin's behalf. I think it's pretty clear that this violates the letter of the FHS, and such a change needs to be considered carefully. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-sysvinit-devel] Re: Moving /var/run to a tmpfs?
[Kurt Roeckx] The FHS says we can create directories under /var/run that are application specific. It also says that all files should be removed or truncated. It does not say anything about directories being removed. It does not say they will stay either, though it specifies Programs may have a subdirectory of /var/run; this is encouraged for programs that use more than one run-time file. I guess it is is unspecified if directories are persistent or not. And as some have pointed out, there are sysadmins already mounting /var/run/ as tmpfs, and it is a bug with the package if it does not work properly. If I create a directory in /var/run, I expect it to stay there. And if I can't expect that, I'd like to see that documented somewhere. I agree that this need to be documented. We work on some notes for the sysvinit package, and will include it there. Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Moving /var/run to a tmpfs?
[Steve Langasek] However, that's not the same thing as saying it's ok for sysvinit to *make* /var/run a tmpfs on the admin's behalf. I think it's pretty clear that this violates the letter of the FHS, and such a change needs to be considered carefully. I fail to see how it violates the letter of the FHS. It is as far as I can see unspecified what kind of file systems will be used, and also if directories will persist across boots. The reason I believe it is important to have some writable file system available at the very beginning of the boot is that there are programs running when kernel modules are loaded by udev that need a place to store state information. At the moment, there is no location to do that, and strange things can happen when the coldplug events happen early in the boot. To fix it, some tmpfs area need to be mounted in mountkernfs.sh. This issue has been discussed here on the list a few months ago, without any conclusion being reached. I do not want us to release etch with a boot system unable to handle detected hardware properly, so I decided to fix this now. Also, it is useful to make it easier to set up stateless workstations using Debian (aka diskless machines ala LTSP), and storing state information in a RAM file system make this a lot easier. /var/run/ is the natural place to store state information that should be cleared at boot time, so I decided to use that as the tmpfs location. It sure helped to notice that Ubuntu already had patches to do this, and that these patches are structured in a way that should work with upgrades and also make sure /var/run/ isn't shadowed when /var/ is mounted later in the boot. The only problem I have found so far is with packages failing to create the directories they use in /var/run/. These will break when this change is done. But there are not very many such packages, because /var/run/ as tmpfs is supposed to be a supported configuration, and most packages have been fixed already to handle it. We could of couse create /lib/init/rw/ or similar (/run, /lib/run, etc have been proposed too), and ask packages like ifupdown to store their state there, but I believe that is a bad idea because /var/run/ is specified to be the location for runtime state information, and creating another location for the same purpose is just increasing the complexity without much gain. I guess we can also add code during halt and reboot to store the directories present in /var/run/ somewhere on / for mountkernfs.sh to find and use it to recreate the directory structure, but I believe that is a guaranteed way to fill /var/run/ with cruft, and recommend against it. After all, it is not very hard to do the equivalent of '[ -d /var/run/mydir] || mkdir /var/run/mydir' in the programs that want a subdir in /var/run/. All in all, I believe the right solution for Debian is to make /var/run/ a tmpfs directory by default, and modify the packages using subdirectories there to create it before they use it instead of when the package is installed. Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Moving /var/run to a tmpfs?
This one time, at band camp, Petter Reinholdtsen said: [Steve Langasek] However, that's not the same thing as saying it's ok for sysvinit to *make* /var/run a tmpfs on the admin's behalf. I think it's pretty clear that this violates the letter of the FHS, and such a change needs to be considered carefully. I fail to see how it violates the letter of the FHS. It is as far as I can see unspecified what kind of file systems will be used, and also if directories will persist across boots. While I don't absolutely agree with /var/run being tmpfs, I can see the arguments and I'm not really interested in repeating them here. But really, if you change a filesystem out from under me, and a locally installed application breaks as a result, that is a bug in the package that decided to whimsically change a filesystem on my system. So please, after due consideration make new installs default to tmpfs if you like, but don't change existing setups lightly. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Moving /var/run to a tmpfs?
On Sun, Sep 17, 2006 at 12:56:47AM +0200, Petter Reinholdtsen wrote: [Steve Langasek] However, that's not the same thing as saying it's ok for sysvinit to *make* /var/run a tmpfs on the admin's behalf. I think it's pretty clear that this violates the letter of the FHS, and such a change needs to be considered carefully. I fail to see how it violates the letter of the FHS. It is as far as I can see unspecified what kind of file systems will be used, and also if directories will persist across boots. 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 [...] It is clear /to me/ from the juxtaposition of these two sentences that the FHS intends for programs to be allowed to create such subdirectories without them being removed at the beginning of the boot process. It is also clear that this is how many maintainers have understood it, because as you yourself have noticed, there are many packages that assume they can ship directories in /var/run and have them remain available after reboot. :) The question is not whether we fix our packages to work sensibly when /var/run is a tmpfs -- I agree that we should -- but what the consequences are for *third-party* packages that are written with this same understanding of the FHS. The reason I believe it is important to have some writable file system available at the very beginning of the boot is that there are programs running when kernel modules are loaded by udev that need a place to store state information. At the moment, there is no location to do that, and strange things can happen when the coldplug events happen early in the boot. To fix it, some tmpfs area need to be mounted in mountkernfs.sh. /var/run/ is the natural place to store state information that should be cleared at boot time, so I decided to use that as the tmpfs location. It sure helped to notice that Ubuntu already had patches to do this, and that these patches are structured in a way that should work with upgrades and also make sure /var/run/ isn't shadowed when /var/ is mounted later in the boot. And is this technique safe with the 2.4 kernels that our userspace needs to continue supporting in etch for upgrade purposes? All in all, I believe the right solution for Debian is to make /var/run/ a tmpfs directory by default, and modify the packages using subdirectories there to create it before they use it instead of when the package is installed. I definitely do not agree that we should be making /var/run a tmpfs directory by default for etch. Indeed, I think we should push for clarification of the FHS on this point before making any such change, because the FHS is not just for the benefit of packages' interactions with one another -- it's also for the benefit of third-party packagers and to give users a set of assumptions they can depend on when interacting with their own systems. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
