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

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 > > leve

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

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 t

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 w

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

Michael Biebl 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 i

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 pack

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

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 eas

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 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 di

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

Vincent Bernat 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..

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 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 daem

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 wrote: > Florian Lohoff 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 >> a

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

Florian Lohoff 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 >>

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]

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

Paul Wise writes: > On Sat, Apr 4, 2009 at 7:37 AM, Michael Biebl 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.

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 doe

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, wh

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 > >

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 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 OpenMok

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

Raphael Geissert 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 ot

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 t

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,

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

Michael Biebl 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 (th

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

Russ Allbery wrote: > Michael Biebl writes: >> Russ Allbery wrote: >>> Michael Biebl 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 d

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

Michael Biebl writes: > Russ Allbery wrote: >> Michael Biebl 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

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

Russ Allbery wrote: > Michael Biebl 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,

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

Russ Allbery wrote: > Michael Biebl 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

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

Michael Biebl 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) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

Michael Biebl 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 (b) well-e

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 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. >> Co

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

Russ Allbery wrote: > Michael Biebl 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 i

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

Michael Biebl 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 manua

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 benefi