Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)
Gunnar Wolf wrote: It does achieve not having bogus information on. If your system crashed, some crappy daemons will refuse to start if /var/run/crappyserver.pid exists, or will try to communicate with their peers using /var/run/sloppydaemon.socket, possibly failing cleanly, but possibly leading to head-scratching In Debian policy: : The init.d scripts must ensure that they will behave sensibly : (i.e., returning success and not starting multiple copies of a : service) if invoked with start when the service is already running, : or with stop when it isn't, and that they don't kill : unfortunately-named user processes. this case is not cited in the examples, but I really think that *behave sensibly* cover also thiscase , i.e. after a crash a daemon should start, also if .pid exists. ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)
On Mon, 2009-04-06 at 20:42 +0200, Michael Biebl wrote:
Steve Langasek wrote:
I think he's referring to the fact that the FHS requires all files in
/var/run to be cleared on boot. We have an init script
(/etc/rcS.d/S36mountall-bootclean) that takes care of this at the system
level, though, on behalf of all packages; the trouble is it's a lot less
efficient, overall, to have to repeatedly clean /var/run on boot than it is
to just write it to a tmpfs and let the contents be lost on reboot.
I think that is one of them main questions:
Is it more efficient, to cleanup /var/tmp (i.e. remove everything besides
directories) on boot in a single place (mountall-bootclean), or is it more
efficient to use a tmpfs and let every package create it's run directory on
boot.
It's probably hard to tell without proper benchmarking.
Another possibility would be to recreate the directories
in /var/{run,lock} on boot in a centeral initscript. Each package could
ship a directory as template somewhere else which would be copied on
boot (after cleaning or mounting a tmpfs) to /var/{run,lock}. Or shell
script snippets could be used instead.
This would at least avoid having an initscript for the sole purpose of
creating those directories.
Jan
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)
Giacomo A. Catenazzi dijo [Tue, Apr 07, 2009 at 11:05:35AM +0200]: In Debian policy: : The init.d scripts must ensure that they will behave sensibly : (i.e., returning success and not starting multiple copies of a : service) if invoked with start when the service is already running, : or with stop when it isn't, and that they don't kill : unfortunately-named user processes. this case is not cited in the examples, but I really think that *behave sensibly* cover also thiscase , i.e. after a crash a daemon should start, also if .pid exists. Strong +1. This is, however, unrelated to whatever happened at boot - If the daemon crashed during regular system usage and it is started again, it should start regardless if there are any pidfiles lying around. -- Gunnar Wolf - gw...@gwolf.org - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)
Petter Reinholdtsen dijo [Sat, Apr 04, 2009 at 06:42:29AM +0200]: Not quite sure what the question is. As far as I know, Debian supported tmpfs mounted /var/run when I become co-maintainer of sysvinit, and I have tried to keep it this way. The only recent changes it that it has become easier to enable it. Very good to notice that this now is documented in the policy. If you wonder what the advantages of tmpfs in /var/run is, I know of several, but do not really have time to track down them all. One of them I care specially about is the fact that it allow a computer to boot with a read-only local file system (think diskless workstations and thin clients booting LTSP, machines with flash disks and files with problems with their file systems), and I believe this is a clear advantage. Having tmpfs there also make it more obvious that the content of /var/run/ will be erased at boot. It does achieve not having bogus information on. If your system crashed, some crappy daemons will refuse to start if /var/run/crappyserver.pid exists, or will try to communicate with their peers using /var/run/sloppydaemon.socket, possibly failing cleanly, but possibly leading to head-scratching -- Gunnar Wolf - gw...@gwolf.org - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)
Gunnar Wolf wrote: Petter Reinholdtsen dijo [Sat, Apr 04, 2009 at 06:42:29AM +0200]: Not quite sure what the question is. As far as I know, Debian supported tmpfs mounted /var/run when I become co-maintainer of sysvinit, and I have tried to keep it this way. The only recent changes it that it has become easier to enable it. Very good to notice that this now is documented in the policy. If you wonder what the advantages of tmpfs in /var/run is, I know of several, but do not really have time to track down them all. One of them I care specially about is the fact that it allow a computer to boot with a read-only local file system (think diskless workstations and thin clients booting LTSP, machines with flash disks and files with problems with their file systems), and I believe this is a clear advantage. Having tmpfs there also make it more obvious that the content of /var/run/ will be erased at boot. It does achieve not having bogus information on. If your system crashed, some crappy daemons will refuse to start if /var/run/crappyserver.pid exists, or will try to communicate with their peers using /var/run/sloppydaemon.socket, possibly failing cleanly, but possibly leading to head-scratching /etc/init.d/mountall-bootclean.sh will take care of cleaning up /var/tmp. If not, it would be a bug in mountall-bootclean.sh. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)
Steve Langasek wrote: On Sat, Apr 04, 2009 at 01:14:51AM +0200, Michael Biebl wrote: Ubuntu. The FHS is silent about directories in /var/run across reboots but requires that all files in /var/run be deleted on reboot. 4.) You have to manually cleanup in postrm. (I guess most packages will forget that, leaving cruft around) If you're creating any files in /var/run during the operation of the package (and if not, why do you have a directory in /var/run in the first place?), then you have to do this anyway, so this isn't new. (Well, I suppose you could just rely on the next reboot deleting them, but that doesn't feel very clean and I'm not sure that's really in the spirit of our requirements.) Not really. Say you have a pretty standard system daemon When the daemon is stopped in postinst, the pid file will be automatically deleted and dpkg will cleanup the remaining /var/run/$foo directory. I think he's referring to the fact that the FHS requires all files in /var/run to be cleared on boot. We have an init script (/etc/rcS.d/S36mountall-bootclean) that takes care of this at the system level, though, on behalf of all packages; the trouble is it's a lot less efficient, overall, to have to repeatedly clean /var/run on boot than it is to just write it to a tmpfs and let the contents be lost on reboot. I think that is one of them main questions: Is it more efficient, to cleanup /var/tmp (i.e. remove everything besides directories) on boot in a single place (mountall-bootclean), or is it more efficient to use a tmpfs and let every package create it's run directory on boot. It's probably hard to tell without proper benchmarking. What can be said though is, that all packages that need a /var/run/ directory must be fixed. (for the numbers: maybe a new archive scan with the new lintian would help to see, how many packages are affected) so it at least requires work by the maintainers. 5.) If your package does not have an init script (I happen to maintain two such packages), I now have to create init scripts simply to create a /var/run directory. That's insane and even more wasting cpu cycles. Could you provide more details about what package without an init script uses /var/run? The only other case that I can think of is packages that create transient UNIX-domain sockets. policykit is such an example. Potentially as D-Bus system bus activated system services are affected by this, because they (usually) don't ship any init script. $ grep -A4 'start)' /etc/init.d/policykit start) mkdir -p /var/run/PolicyKit chown root:polkituser /var/run/PolicyKit chmod 770 /var/run/PolicyKit ;; $ That's what I have on an Ubuntu system; why can't the Debian package do the same? Sure it can. But I consider this solution very ugly and refused to do this so far. For the reasons already mentioned it also makes the (previouly init system agnostic) D-Bus service dependend on sysv-rc. (Yes, this is the only function of this init script. But still, either you create the directories on boot or you have to clean all the files on boot.) We will se such services more and more in the future (like it or not). No. Services that work that way are Doing It Wrong, and we should not accept this as inevitable. Ok, what do you think are they doing wrong: Being started on-demand via D-Bus, i.e. not shipping a sysv init script? I provided a list of cons of tmpfs (you could probably also add, that it breaks selinux). Is there actually a list of pros? Probably? In what case does this break selinux? I'm not a selinux expert, but I read somewhere, that the security context is lost, so you'd have to relabel the directory. I don't know, how costly that operation is (and if this is necessary for a directory in /var/tmp). Maybe Russell or Manoj can chime in here, if they read this. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)
Michael Biebl bi...@debian.org writes: What can be said though is, that all packages that need a /var/run/ directory must be fixed. (for the numbers: maybe a new archive scan with the new lintian would help to see, how many packages are affected) so it at least requires work by the maintainers. This is in progress now. Lintian is still sadly slower than we'd like, so it's only about two-thirds done and probably won't be finished until Wednesday or so. (I have some additional ideas to speed it up, but haven't had a lot of time to work on it.) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)
On Mon, 2009-04-06 at 20:42 +0200, Michael Biebl wrote: Sure it can. But I consider this solution very ugly and refused to do this so far. For the reasons already mentioned it also makes the (previouly init system agnostic) D-Bus service dependend on sysv-rc. Wait, now I'm confused. Why wouldn't this same init script work in file-rc? Or are you saying something else? -- -Julian Blake Kongslie If this is a mailing list, please CC me on replies. vim: set ft=text : signature.asc Description: This is a digitally signed message part
Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)
Michael Biebl wrote: Gunnar Wolf wrote: /etc/init.d/mountall-bootclean.sh will take care of cleaning up /var/tmp. /var/run, of course. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)
OoO En cette nuit striée d'éclairs du samedi 04 avril 2009, vers 02:14, Russ Allbery r...@debian.org disait : There are still daemons though (like proftpd comes to mind), which ship a subdirectory in /var/run and support inetd. What does it use the directory for? I don't know for proftpd, but a daemon can use an empty directory in /var/run to chroot into it. -- FUNNY NOISES ARE NOT FUNNY FUNNY NOISES ARE NOT FUNNY FUNNY NOISES ARE NOT FUNNY -+- Bart Simpson on chalkboard in episode 8F20 pgpaTIof8Ed1U.pgp Description: PGP signature
Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)
Vincent Bernat ber...@debian.org writes: I don't know for proftpd, but a daemon can use an empty directory in /var/run to chroot into it. Seems like a good use for /var/lib to me. There's no reason that I can see to put such a directory on a file system that's defined as transient. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)
OoO En ce début de soirée du dimanche 05 avril 2009, vers 21:56, Russ Allbery r...@debian.org disait : I don't know for proftpd, but a daemon can use an empty directory in /var/run to chroot into it. Seems like a good use for /var/lib to me. There's no reason that I can see to put such a directory on a file system that's defined as transient. Both /var/lib and /var/run are for files, not really empty directories. It seems to be more usual to put an empty (or almost empty) directory into /var/run than into /var/lib. Googling a bit, I did not find any rationale behind this. It seems not advisable to use /var/empty (an hole in an application could permit to share the exploit with another for example). This is not an argument against having /var/run in tmpfs, just an information about what kind of daemon could be run from inetd and need something in /var/run. -- I WILL NOT HANG DONUTS ON MY PERSON I WILL NOT HANG DONUTS ON MY PERSON I WILL NOT HANG DONUTS ON MY PERSON -+- Bart Simpson on chalkboard in episode 2F13 pgpJs7ykkZEwH.pgp Description: PGP signature
Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)
On 04/04/09 01:22, Steve Langasek wrote: On Sat, Apr 04, 2009 at 01:14:51AM +0200, Michael Biebl wrote: I provided a list of cons of tmpfs (you could probably also add, that it breaks selinux). Is there actually a list of pros? Probably? In what case does this break selinux? It doesn't actually break selinux - the init script just needs to include [ -x /sbin/restorecon ] restorecon /var/run/$dir to ensure that the directory is labelled correctly on selinux systems. -- Martin Orr -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)
Paul Wise p...@debian.org writes: On Sat, Apr 4, 2009 at 7:37 AM, Michael Biebl bi...@debian.org wrote: Afaik, Ubuntu is the only Linux distro which supports and uses tmpfs by default. The OpenEmbedded distros do this too, I've especially seen that the ones associated with OpenMoko do that. Maemo does it, too. (Actually in links /var/run to /tmp/.run) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)
On Fri, Apr 03, 2009 at 11:40:57PM +0200, Michael Biebl wrote: Subject: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1) Hi, one of the changes in 3.8.1 was, that support for tmpfs on /var/run (and /var/tmp) became mandatory [9.3.2]. Lintian is now also complaining very loudly (error) if your package ships a directory in /var/run or /var/tmp and suggests to create them in the init script. While I can see the benefits of having /var/tmp on a tmpfs to a certain degree, I don't really see them for /var/run, instead they make things more complicated, slower and error prone (for imho no real gain) Interesting - The unix way IMHO was that /tmp looses content on reboot while /var/tmp did not. This had been the case for commercial Unices for at least some decades. Flo -- Florian Lohoff f...@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature
Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)
Florian Lohoff f...@rfc822.org writes: On Fri, Apr 03, 2009 at 11:40:57PM +0200, Michael Biebl wrote: one of the changes in 3.8.1 was, that support for tmpfs on /var/run (and /var/tmp) became mandatory [9.3.2]. Lintian is now also complaining very loudly (error) if your package ships a directory in /var/run or /var/tmp and suggests to create them in the init script. While I can see the benefits of having /var/tmp on a tmpfs to a certain degree, I don't really see them for /var/run, instead they make things more complicated, slower and error prone (for imho no real gain) Interesting - The unix way IMHO was that /tmp looses content on reboot while /var/tmp did not. This had been the case for commercial Unices for at least some decades. I'm pretty sure Michael meant /var/lock when he said /var/tmp above. Policy 3.8.1 doesn't change anything about /var/tmp. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)
On Sun, Apr 5, 2009 at 3:32 AM, Russ Allbery r...@debian.org wrote: Florian Lohoff f...@rfc822.org writes: On Fri, Apr 03, 2009 at 11:40:57PM +0200, Michael Biebl wrote: Interesting - The unix way IMHO was that /tmp looses content on reboot while /var/tmp did not. This had been the case for commercial Unices for at least some decades. I'm pretty sure Michael meant /var/lock when he said /var/tmp above. Policy 3.8.1 doesn't change anything about /var/tmp. The embedded devices I mentioned in another message in this thread have /var/tmp as a tmpfs too. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)
Hi, one of the changes in 3.8.1 was, that support for tmpfs on /var/run (and /var/tmp) became mandatory [9.3.2]. Lintian is now also complaining very loudly (error) if your package ships a directory in /var/run or /var/tmp and suggests to create them in the init script. While I can see the benefits of having /var/tmp on a tmpfs to a certain degree, I don't really see them for /var/run, instead they make things more complicated, slower and error prone (for imho no real gain) 1.) It's not the default on Debian anyway 2.) A lot of packages must be changed for this new policy 3.) You have to check for the directory on each boot, meaning wasted cpu cycles, even if you don't use this feature (as said, its default is off on Debian) 4.) You have to manually cleanup in postrm. (I guess most packages will forget that, leaving cruft around) 5.) If your package does not have an init script (I happen to maintain two such packages), I now have to create init scripts simply to create a /var/run directory. That's insane and even more wasting cpu cycles. As I said, I don't see the benefit of a tmpfs for /var/run which would justify this policy change so would very much appreciate to here valid reasons for this change. I also think, that the recommendation to remove the /var/run directories and creating them manually on each boot in each package is the wrong approach. For people, that want to use a tmpfs for /var/run, there could be a script on shutdown which backups (or copies) the content of /var/run and restores it on boot (the creation of this backup could also be triggered by a dpkg file system trigger, which would eliminate of the backup being outdated because of a hard reset. This would obviously only happen, if RAMRUN is set) This way, people using the default (not tmpfs) would not get the performance hit and we wouldn't have to modify a lot of packages. So my suggestion is, to rework 9.3.2 and remove this requirement again. And again, can someone please enlighten my, why tmpfs for /var/run is a good idea anyway. Thoughts, comments? Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)
Michael Biebl bi...@debian.org writes: 1.) It's not the default on Debian anyway It is, however, a standard and supported option and it's the default in Ubuntu. The FHS is silent about directories in /var/run across reboots but requires that all files in /var/run be deleted on reboot. 4.) You have to manually cleanup in postrm. (I guess most packages will forget that, leaving cruft around) If you're creating any files in /var/run during the operation of the package (and if not, why do you have a directory in /var/run in the first place?), then you have to do this anyway, so this isn't new. (Well, I suppose you could just rely on the next reboot deleting them, but that doesn't feel very clean and I'm not sure that's really in the spirit of our requirements.) 5.) If your package does not have an init script (I happen to maintain two such packages), I now have to create init scripts simply to create a /var/run directory. That's insane and even more wasting cpu cycles. Could you provide more details about what package without an init script uses /var/run? The only other case that I can think of is packages that create transient UNIX-domain sockets. As I said, I don't see the benefit of a tmpfs for /var/run which would justify this policy change so would very much appreciate to here valid reasons for this change. Did you already read the Policy bug? It contains a rationale, although I don't know if it's a complete enough one for you. For people, that want to use a tmpfs for /var/run, there could be a script on shutdown which backups (or copies) the content of /var/run and restores it on boot I assume you mean only the directory structure? Otherwise, this would be an FHS violation. Personally, I'm not inclined to revert this change. I think it's correct and continues to be correct, and I'd rather not undo the work that's already been put into making it work. This was added to Policy in part because of various bug reports against packages not working as expected, so removing it from Policy won't make those bug reports go away again. And I think it's better to fix the packages than to add something to preserve /var/run directories across boot, which seems like a hack to me. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)
Russ Allbery wrote: Michael Biebl bi...@debian.org writes: Hi Russ 1.) It's not the default on Debian anyway It is, however, a standard and supported option and it's the default in Hm, what standard exactly do you refer too. Ubuntu. The FHS is silent about directories in /var/run across reboots but requires that all files in /var/run be deleted on reboot. 4.) You have to manually cleanup in postrm. (I guess most packages will forget that, leaving cruft around) If you're creating any files in /var/run during the operation of the package (and if not, why do you have a directory in /var/run in the first place?), then you have to do this anyway, so this isn't new. (Well, I suppose you could just rely on the next reboot deleting them, but that doesn't feel very clean and I'm not sure that's really in the spirit of our requirements.) Not really. Say you have a pretty standard system daemon When the daemon is stopped in postinst, the pid file will be automatically deleted and dpkg will cleanup the remaining /var/run/$foo directory. 5.) If your package does not have an init script (I happen to maintain two such packages), I now have to create init scripts simply to create a /var/run directory. That's insane and even more wasting cpu cycles. Could you provide more details about what package without an init script uses /var/run? The only other case that I can think of is packages that create transient UNIX-domain sockets. policykit is such an example. Potentially as D-Bus system bus activated system services are affected by this, because they (usually) don't ship any init script. We will se such services more and more in the future (like it or not). As I said, I don't see the benefit of a tmpfs for /var/run which would justify this policy change so would very much appreciate to here valid reasons for this change. Did you already read the Policy bug? It contains a rationale, although I don't know if it's a complete enough one for you. I just skimmed over the bug report. And I think it completely misses to justify, why it is a good idea to have tmpfs on /var/run. I provided a list of cons of tmpfs (you could probably also add, that it breaks selinux). Is there actually a list of pros? For people, that want to use a tmpfs for /var/run, there could be a script on shutdown which backups (or copies) the content of /var/run and restores it on boot I assume you mean only the directory structure? Otherwise, this would be an FHS violation. Right, only the directories. would be as simple as tar -cpf /tmp/foo.tgz $(find -type d) Personally, I'm not inclined to revert this change. I think it's correct and continues to be correct, and I'd rather not undo the work that's already been put into making it work. This was added to Policy in part because of various bug reports against packages not working as expected, so removing it from Policy won't make those bug reports go away again. And I think it's better to fix the packages than to add something to preserve /var/run directories across boot, which seems like a hack to me. Not more of a hack than adding init scripts which do nothing else then creating /var/run/foo, with the added benefit that only the users (minority) which actually use RAMRUN would have to live with this hack. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)
Michael Biebl wrote: Russ Allbery wrote: Michael Biebl bi...@debian.org writes: 5.) If your package does not have an init script (I happen to maintain two such packages), I now have to create init scripts simply to create a /var/run directory. That's insane and even more wasting cpu cycles. Could you provide more details about what package without an init script uses /var/run? The only other case that I can think of is packages that create transient UNIX-domain sockets. policykit is such an example. Potentially as D-Bus system bus activated system ^^ all services are affected by this, because they (usually) don't ship any init script. Another class of services which might be affected, are daemons/programs started by inetd. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)
Michael Biebl bi...@debian.org writes: Russ Allbery wrote: It is, however, a standard and supported option and it's the default in Hm, what standard exactly do you refer too. standard, adjective [1622] 2) (a) regularly and widely used, available, or supplied standard automobile equipment (b) well-established and very familiar the standard opera is what I meant. /var/run on tmpfs has been common on UNIX platforms for many years. It was standard on Solaris at least as far back as Solaris 8, for example. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)
Michael Biebl bi...@debian.org writes: Another class of services which might be affected, are daemons/programs started by inetd. Why would they put anything in /var/run? -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)
Russ Allbery wrote: Michael Biebl bi...@debian.org writes: Another class of services which might be affected, are daemons/programs started by inetd. Why would they put anything in /var/run? I guess for the same reasons why other system daemons put stuff in /var/run Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)
Russ Allbery wrote: Michael Biebl bi...@debian.org writes: Russ Allbery wrote: It is, however, a standard and supported option and it's the default in Hm, what standard exactly do you refer too. standard, adjective [1622] 2) (a) regularly and widely used, available, or supplied standard automobile equipment (b) well-established and very familiar the standard opera widely used and well established in Debian is definitely not the case. is what I meant. /var/run on tmpfs has been common on UNIX platforms for many years. It was standard on Solaris at least as far back as Solaris 8, for example. Afaik, Ubuntu is the only Linux distro which supports and uses tmpfs by default. I believe you, when you say that it is common on older UNIX platforms or Solaris, as I don't have experience with them. Again, if there would be a list of cons, I'd be much happier in supporting this new policy. Unfortunately I only see disadvantages. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)
Michael Biebl bi...@debian.org writes: Russ Allbery wrote: Michael Biebl bi...@debian.org writes: Another class of services which might be affected, are daemons/programs started by inetd. Why would they put anything in /var/run? I guess for the same reasons why other system daemons put stuff in /var/run They put their PIDs in /var/run so that they can be easily stopped or checked for status. So why would something started by inetd put anyting in /var/run? I'm still having a hard time understanding what's putting files in /var/run that isn't a daemon. Even UNIX domain sockets exist generally to contact a running daemon. Could you explain what policykit uses /var/run for, and educate me a bit on why D-Bus services have to put things in /var/run but don't have init scripts? -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)
Russ Allbery wrote: Michael Biebl bi...@debian.org writes: Russ Allbery wrote: Michael Biebl bi...@debian.org writes: Another class of services which might be affected, are daemons/programs started by inetd. Why would they put anything in /var/run? I guess for the same reasons why other system daemons put stuff in /var/run They put their PIDs in /var/run so that they can be easily stopped or checked for status. So why would something started by inetd put anyting in /var/run? I'm still having a hard time understanding what's putting files in /var/run that isn't a daemon. Even UNIX domain sockets exist generally to Why is a system service that is started by inetd or D-Bus not a daemon? Remember the times when exim4 or samba could still be started via inetd (although those no longer support inetd mode afaik). There are still daemons though (like proftpd comes to mind), which ship a subdirectory in /var/run and support inetd. contact a running daemon. Could you explain what policykit uses /var/run for, and educate me a bit on why D-Bus services have to put things in /var/run but don't have init scripts? PolicyKit stores credentials in /var/run/PolicyKit which are of temporary nature and are automatically cleaned up on boot. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)
Michael Biebl bi...@debian.org writes: Why is a system service that is started by inetd or D-Bus not a daemon? Remember the times when exim4 or samba could still be started via inetd (although those no longer support inetd mode afaik). Why would you store your PID somewhere if you're started from inetd (that's the main thing daemons use it for)? There's nothing to manage; when you're running in inetd mode, you process one connection and exit. There's no purpose served by storing the PID anywhere (and indeed since multiple copies can be running at the same time, it's not clear how you would even do such a thing). There are still daemons though (like proftpd comes to mind), which ship a subdirectory in /var/run and support inetd. What does it use the directory for? PolicyKit stores credentials in /var/run/PolicyKit which are of temporary nature and are automatically cleaned up on boot. Oh, okay, so you're similar to sudo where you're taking advantage of the fact that /var/run is cleaned on boot but isn't world-writable. sudo appears to create its directory dynamically if it doesn't already exist. I assume the reason why you can't take that approach is that PolicyKit doesn't run as root and hence can't create directories in /var/run? I believe the original motivation for tmpfs /var/run in Solaris was that it was pointless to maintain scripts that try to clean /var/run (or /tmp or any other defined-transient directory) on boot, which can be dangerous and tricky if you don't write them carefully, when you can just put them in tmpfs and have the cleaning happen automatically without doing any work. It simplifies the boot process and eliminates a whole class of potential directory traversal races that you otherwise have to think about. Potential additional boot speed from writing all the startup PID files to a tmpfs file system (and benefits for flash drives as the only system storage and similar special configurations) are just a bonus. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)
Russ Allbery schrieb: I believe the original motivation for tmpfs /var/run in Solaris was that it was pointless to maintain scripts that try to clean /var/run (or /tmp or any other defined-transient directory) on boot, which can be dangerous and tricky if you don't write them carefully, when you can just put them But this functionality is already there as Debian supports a static /var/run and support for that is not going away. Maybe Petter can comment if this ever posed any (security) problems. in tmpfs and have the cleaning happen automatically without doing any work. It simplifies the boot process and eliminates a whole class of I'm not sure I get that point. Why is the boot process simplified if now every script has to check for it's run directory and potentially create it or having to introduce fake boot scripts, which do nothing but create a run directory. potential directory traversal races that you otherwise have to think about. Potential additional boot speed from writing all the startup PID files to a tmpfs file system (and benefits for flash drives as the only system storage and similar special configurations) are just a bonus. I doubt, that the boot process will be faster if I have to fork a shell and create a run directory. And the /var/run directory is not something that is constantly written at, so I also doubt that it will buy you much of your flash drive life. But let's be pragmatic, if we want to support both methods, why should we have to touch dozens (if not hundreds) of init script if I can do the same with 10 lines of shell code (which does the backup/restore) and this problem is solved today. I don't think this solution is less elegant then fixing a myriad of init scripts. I'm even willing to write such a patch and post it here for review. Cheers, Michael P.S: That's it from my side for a while. I'll be waiting for comments from other DDs first. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)
Michael Biebl wrote: Russ Allbery schrieb: [...] in tmpfs and have the cleaning happen automatically without doing any work. It simplifies the boot process and eliminates a whole class of I'm not sure I get that point. Why is the boot process simplified if now every script has to check for it's run directory and potentially create it or having to introduce fake boot scripts, which do nothing but create a run directory. Why do you need fake boot scripts? I haven't seen you prove a fair use of those. It also appears that some are unused; I have the daemon running on my system but there's an empty dir in /var/run without anything in there. potential directory traversal races that you otherwise have to think about. Potential additional boot speed from writing all the startup PID files to a tmpfs file system (and benefits for flash drives as the only system storage and similar special configurations) are just a bonus. I doubt, that the boot process will be faster if I have to fork a shell and create a run directory. And the /var/run directory is not something that is constantly written at, so I also doubt that it will buy you much of your flash drive life. All those system calls (except forking the shell, which by the way should already be in cache so no read from disk) cause no write operation on the disk, which saves time, energy, and sector writes in SSDs. But let's be pragmatic, if we want to support both methods, why should we have to touch dozens (if not hundreds) of init script if I can do the hundreds? I think you are exaggerating, why don't you provide real numbers? same with 10 lines of shell code (which does the backup/restore) and this problem is solved today. I don't think this solution is less elegant then fixing a myriad of init scripts. As Russ already said, the FHS requires that all files in /var/run be deleted on reboot; so there's a myriad of bogus init scripts. Cheers, Raphael Geissert -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)
Raphael Geissert atomo64+deb...@gmail.com writes: As Russ already said, the FHS requires that all files in /var/run be deleted on reboot; so there's a myriad of bogus init scripts. Well, to be fair, it requires that all *files* be deleted, not directories. It doesn't really say anything clear about directories other than recommending that they be used if an application has more than one file. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)
On Sat, Apr 4, 2009 at 7:37 AM, Michael Biebl bi...@debian.org wrote: Afaik, Ubuntu is the only Linux distro which supports and uses tmpfs by default. The OpenEmbedded distros do this too, I've especially seen that the ones associated with OpenMoko do that. In addition the pkg-fso folk's Debian for OpenMoko installer script puts /var/run, /var/lock on a tmpfs and presumably when d-i supports the OpenMoko devices that will be the default on such devices. Again, if there would be a list of cons, I'd be much happier in supporting this new policy. Unfortunately I only see disadvantages. I guess you mean pros rather than cons. One would be that it reduces the number of useless writes to disk/flash, which could be important for mobile situations like phones. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)
On Sat, Apr 04, 2009 at 01:14:51AM +0200, Michael Biebl wrote: Ubuntu. The FHS is silent about directories in /var/run across reboots but requires that all files in /var/run be deleted on reboot. 4.) You have to manually cleanup in postrm. (I guess most packages will forget that, leaving cruft around) If you're creating any files in /var/run during the operation of the package (and if not, why do you have a directory in /var/run in the first place?), then you have to do this anyway, so this isn't new. (Well, I suppose you could just rely on the next reboot deleting them, but that doesn't feel very clean and I'm not sure that's really in the spirit of our requirements.) Not really. Say you have a pretty standard system daemon When the daemon is stopped in postinst, the pid file will be automatically deleted and dpkg will cleanup the remaining /var/run/$foo directory. I think he's referring to the fact that the FHS requires all files in /var/run to be cleared on boot. We have an init script (/etc/rcS.d/S36mountall-bootclean) that takes care of this at the system level, though, on behalf of all packages; the trouble is it's a lot less efficient, overall, to have to repeatedly clean /var/run on boot than it is to just write it to a tmpfs and let the contents be lost on reboot. 5.) If your package does not have an init script (I happen to maintain two such packages), I now have to create init scripts simply to create a /var/run directory. That's insane and even more wasting cpu cycles. Could you provide more details about what package without an init script uses /var/run? The only other case that I can think of is packages that create transient UNIX-domain sockets. policykit is such an example. Potentially as D-Bus system bus activated system services are affected by this, because they (usually) don't ship any init script. $ grep -A4 'start)' /etc/init.d/policykit start) mkdir -p /var/run/PolicyKit chown root:polkituser /var/run/PolicyKit chmod 770 /var/run/PolicyKit ;; $ That's what I have on an Ubuntu system; why can't the Debian package do the same? (Yes, this is the only function of this init script. But still, either you create the directories on boot or you have to clean all the files on boot.) We will se such services more and more in the future (like it or not). No. Services that work that way are Doing It Wrong, and we should not accept this as inevitable. I provided a list of cons of tmpfs (you could probably also add, that it breaks selinux). Is there actually a list of pros? Probably? In what case does this break selinux? Personally, I'm not inclined to revert this change. I think it's correct and continues to be correct, and I'd rather not undo the work that's already been put into making it work. This was added to Policy in part because of various bug reports against packages not working as expected, so removing it from Policy won't make those bug reports go away again. And I think it's better to fix the packages than to add something to preserve /var/run directories across boot, which seems like a hack to me. Not more of a hack than adding init scripts which do nothing else then creating /var/run/foo, with the added benefit that only the users (minority) which actually use RAMRUN would have to live with this hack. I would like to see /var/run become the default on Debian as well, eventually... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)
[Michael Biebl] I believe the original motivation for tmpfs /var/run in Solaris was that it was pointless to maintain scripts that try to clean /var/run (or /tmp or any other defined-transient directory) on boot, which can be dangerous and tricky if you don't write them carefully, when you can just put them But this functionality is already there as Debian supports a static /var/run and support for that is not going away. Maybe Petter can comment if this ever posed any (security) problems. Not quite sure what the question is. As far as I know, Debian supported tmpfs mounted /var/run when I become co-maintainer of sysvinit, and I have tried to keep it this way. The only recent changes it that it has become easier to enable it. Very good to notice that this now is documented in the policy. If you wonder what the advantages of tmpfs in /var/run is, I know of several, but do not really have time to track down them all. One of them I care specially about is the fact that it allow a computer to boot with a read-only local file system (think diskless workstations and thin clients booting LTSP, machines with flash disks and files with problems with their file systems), and I believe this is a clear advantage. Having tmpfs there also make it more obvious that the content of /var/run/ will be erased at boot. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
