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
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,
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
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
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
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
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
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
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
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,
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.
--
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
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
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
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
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
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
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
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.)
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
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.
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
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
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
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
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
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
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
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
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
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
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
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,
[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
34 matches
Mail list logo
