Debian Bug report logs - #630615
RAMTMP should default to no

version graph

Package: initscripts; Maintainer for initscripts is Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>; Source for initscripts is src:sysvinit.

Reported by: Michael Biebl <biebl@debian.org>

Date: Wed, 15 Jun 2011 15:39:01 UTC

Severity: important

Merged with 665406, 665631, 665634, 666096, 666696

Found in versions sysvinit/2.88dsf-13.10, sysvinit/2.88dsf-18, sysvinit/2.88dsf-22

Fixed in version sysvinit/2.88dsf-26

Done: Roger Leigh <rleigh@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>:
Bug#630615; Package initscripts. (Wed, 15 Jun 2011 15:39:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michael Biebl <biebl@debian.org>:
New Bug report received and forwarded. Copy sent to Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>. (Wed, 15 Jun 2011 15:39:04 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Michael Biebl <biebl@debian.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: RAMTMP should default to no
Date: Wed, 15 Jun 2011 17:35:08 +0200
Package: initscripts
Version: 2.88dsf-13.10
Severity: important
File: /usr/share/initscripts/default.rcS

Hi,

the default for new installations is to use RAMTMP=yes.
I think having RAMTMP as optional feature is great, but it should
default to no, because this is the safer default:
- virtual machines are usually provisioned with only the minimal
  required amount of RAM.
- a typical hard disk is much bigger than RAM and thus /tmp on a typical
  installation provides much more space then RAM.
- software using /tmp to store large amounts of data, like backup
  programs, download managers etc.


Cheers,
Michael

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.39-2-486
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages initscripts depends on:
ii  coreutils                  8.5-1         GNU core utilities
ii  debianutils                4.0.2         Miscellaneous utilities specific t
ii  libc6                      2.13-7        Embedded GNU C Library: Shared lib
ii  lsb-base                   3.2-27        Linux Standard Base 3.2 init scrip
ii  mount                      2.17.2-9.1    Tools for mounting and manipulatin
ii  sysv-rc                    2.88dsf-13.10 System-V-like runlevel change mech
ii  sysvinit-utils             2.88dsf-13.10 System-V-like utilities

Versions of packages initscripts recommends:
ii  e2fsprogs                     1.41.12-4  ext2/ext3/ext4 file system utiliti
ii  psmisc                        22.13-1    utilities that use the proc file s

initscripts suggests no packages.

-- no debconf information




Information forwarded to debian-bugs-dist@lists.debian.org, Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>:
Bug#630615; Package initscripts. (Wed, 15 Jun 2011 16:00:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Petter Reinholdtsen <pere@hungry.com>:
Extra info received and forwarded to list. Copy sent to Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>. (Wed, 15 Jun 2011 16:00:03 GMT) Full text and rfc822 format available.

Message #10 received at 630615@bugs.debian.org (full text, mbox):

From: Petter Reinholdtsen <pere@hungry.com>
To: Michael Biebl <biebl@debian.org>, 630615@bugs.debian.org
Subject: Re: [Pkg-sysvinit-devel] Bug#630615: RAMTMP should default to no
Date: Wed, 15 Jun 2011 17:56:59 +0200
[Michael Biebl]
> the default for new installations is to use RAMTMP=yes.

Hm, do not remember doing this change.  Anyone know when it happened?

> I think having RAMTMP as optional feature is great, but it should
> default to no, because this is the safer default:
> - virtual machines are usually provisioned with only the minimal
>   required amount of RAM.
> - a typical hard disk is much bigger than RAM and thus /tmp on a typical
>   installation provides much more space then RAM.
> - software using /tmp to store large amounts of data, like backup
>   programs, download managers etc.

Given that /var/tmp/ should be used for large files, and /tmp/ should
only be used for smaller temporary files that should go away when a
machine is rebooted, your argument do not really have much weight.
Those storing large files in /tmp/ is doing it wrong, and should be
changed to use /var/tmp/ instead.

Personally, I believe having /tmp/ as tmpfs by default is a good idea
and always use it my self.  Those that do not want it can disable it.

Happy hacking,
-- 
Petter Reinholdtsen




Information forwarded to debian-bugs-dist@lists.debian.org, Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>:
Bug#630615; Package initscripts. (Wed, 15 Jun 2011 16:36:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Roger Leigh <rleigh@codelibre.net>:
Extra info received and forwarded to list. Copy sent to Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>. (Wed, 15 Jun 2011 16:36:09 GMT) Full text and rfc822 format available.

Message #15 received at 630615@bugs.debian.org (full text, mbox):

From: Roger Leigh <rleigh@codelibre.net>
To: Petter Reinholdtsen <pere@hungry.com>, 630615@bugs.debian.org
Cc: Michael Biebl <biebl@debian.org>
Subject: Re: Bug#630615: [Pkg-sysvinit-devel] Bug#630615: RAMTMP should default to no
Date: Wed, 15 Jun 2011 17:33:59 +0100
[Message part 1 (text/plain, inline)]
On Wed, Jun 15, 2011 at 05:56:59PM +0200, Petter Reinholdtsen wrote:
> [Michael Biebl]
> > the default for new installations is to use RAMTMP=yes.
> 
> Hm, do not remember doing this change.  Anyone know when it happened?

This was done as part of the /run work a couple of months back.

This was done following the discussion about default size limits
for the various tmpfses in use (/run, /run/lock, /run/shm, and
/tmp) on the debian-devel list, and also on #debian-devel.  At
the time, the consensus appeared to be generally in favour of
the change.

Note that this only takes effect for new installations.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>:
Bug#630615; Package initscripts. (Wed, 15 Jun 2011 16:36:11 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michael Biebl <biebl@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>. (Wed, 15 Jun 2011 16:36:11 GMT) Full text and rfc822 format available.

Message #20 received at 630615@bugs.debian.org (full text, mbox):

From: Michael Biebl <biebl@debian.org>
To: Petter Reinholdtsen <pere@hungry.com>
Cc: 630615@bugs.debian.org
Subject: Re: [Pkg-sysvinit-devel] Bug#630615: RAMTMP should default to no
Date: Wed, 15 Jun 2011 18:34:17 +0200
[Message part 1 (text/plain, inline)]
Am 15.06.2011 17:56, schrieb Petter Reinholdtsen:
> [Michael Biebl]
>> the default for new installations is to use RAMTMP=yes.
> 
> Hm, do not remember doing this change.  Anyone know when it happened?
> 
>> I think having RAMTMP as optional feature is great, but it should
>> default to no, because this is the safer default:
>> - virtual machines are usually provisioned with only the minimal
>>   required amount of RAM.
>> - a typical hard disk is much bigger than RAM and thus /tmp on a typical
>>   installation provides much more space then RAM.
>> - software using /tmp to store large amounts of data, like backup
>>   programs, download managers etc.
> 
> Given that /var/tmp/ should be used for large files, and /tmp/ should
> only be used for smaller temporary files that should go away when a
> machine is rebooted, your argument do not really have much weight.

The distinction between /var/tmp and /tmp is about persistence, and not the size
of the data stored there.
I can't find any reference saying that /tmp is only for small files and /var/tmp
only for large files.

Fact of the matter is, that there is software out there using /tmp to store
large amount of temporary data (which doesn't need to survive reboots, so
/var/tmp would be the wrong place).

Cheers,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>:
Bug#630615; Package initscripts. (Wed, 15 Jun 2011 16:42:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michael Biebl <biebl@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>. (Wed, 15 Jun 2011 16:42:03 GMT) Full text and rfc822 format available.

Message #25 received at 630615@bugs.debian.org (full text, mbox):

From: Michael Biebl <biebl@debian.org>
To: Roger Leigh <rleigh@codelibre.net>
Cc: Petter Reinholdtsen <pere@hungry.com>, 630615@bugs.debian.org
Subject: Re: Bug#630615: [Pkg-sysvinit-devel] Bug#630615: RAMTMP should default to no
Date: Wed, 15 Jun 2011 18:40:21 +0200
[Message part 1 (text/plain, inline)]
Hi Roger!

Am 15.06.2011 18:33, schrieb Roger Leigh:
> On Wed, Jun 15, 2011 at 05:56:59PM +0200, Petter Reinholdtsen wrote:
> 
> This was done following the discussion about default size limits
> for the various tmpfses in use (/run, /run/lock, /run/shm, and
> /tmp) on the debian-devel list, and also on #debian-devel.  At
> the time, the consensus appeared to be generally in favour of
> the change.

As you've seen on todays discussion #debian-devel, my feeling is that there is
no general consensus on this. It's obviously hard to dig out old irc discussions
(unless you kept logs), but can you point to the relevant discussion on the
debian-devel m-l for reference?

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>:
Bug#630615; Package initscripts. (Wed, 15 Jun 2011 17:00:18 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michael Biebl <biebl@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>. (Wed, 15 Jun 2011 17:00:18 GMT) Full text and rfc822 format available.

Message #30 received at 630615@bugs.debian.org (full text, mbox):

From: Michael Biebl <biebl@debian.org>
To: Petter Reinholdtsen <pere@hungry.com>
Cc: 630615@bugs.debian.org, rleigh <rleigh@codelibre.net>
Subject: Re: [Pkg-sysvinit-devel] Bug#630615: RAMTMP should default to no
Date: Wed, 15 Jun 2011 18:59:43 +0200
[Message part 1 (text/plain, inline)]
Am 15.06.2011 18:34, schrieb Michael Biebl:

> Fact of the matter is, that there is software out there using /tmp to store
> large amount of temporary data (which doesn't need to survive reboots, so
> /var/tmp would be the wrong place).

To be a bit more specific about this. I at least remember fsarchiver (backup
utility) to use /tmp as storage during backup creating temporary files (using
several GB, depending on the size of the partition).
Some of the download managers (like downthemall) use /tmp, if they download
files in multiple streams.
I remember dvd authoring software to create several GBs of data in /tmp. I'd
need to check the CD burning tools, like brasero or k3b, but I wouldn't be
surprised if they use /tmp, too.

For this type of data /var/tmp is not the right place.

Cheers,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>:
Bug#630615; Package initscripts. (Wed, 15 Jun 2011 17:15:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Petter Reinholdtsen <pere@hungry.com>:
Extra info received and forwarded to list. Copy sent to Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>. (Wed, 15 Jun 2011 17:15:03 GMT) Full text and rfc822 format available.

Message #35 received at 630615@bugs.debian.org (full text, mbox):

From: Petter Reinholdtsen <pere@hungry.com>
To: Michael Biebl <biebl@debian.org>
Cc: 630615@bugs.debian.org
Subject: Re: [Pkg-sysvinit-devel] Bug#630615: RAMTMP should default to no
Date: Wed, 15 Jun 2011 19:13:25 +0200
[Michael Biebl]
> For this type of data /var/tmp is not the right place.

Actually, /var/tmp/ is the right place for this kind of data.

I am sure there are programs saving large files in /tmp/, but for me
this only proves that there are programs with bugs around.  Bugs that
should be fixed, not worked around.

Happy hacking,
-- 
Petter Reinholdtsen




Information forwarded to debian-bugs-dist@lists.debian.org, Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>:
Bug#630615; Package initscripts. (Wed, 15 Jun 2011 17:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michael Biebl <biebl@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>. (Wed, 15 Jun 2011 17:27:03 GMT) Full text and rfc822 format available.

Message #40 received at 630615@bugs.debian.org (full text, mbox):

From: Michael Biebl <biebl@debian.org>
To: Petter Reinholdtsen <pere@hungry.com>
Cc: 630615@bugs.debian.org, rleigh <rleigh@codelibre.net>
Subject: Re: [Pkg-sysvinit-devel] Bug#630615: RAMTMP should default to no
Date: Wed, 15 Jun 2011 19:24:51 +0200
[Message part 1 (text/plain, inline)]
Am 15.06.2011 19:13, schrieb Petter Reinholdtsen:
> [Michael Biebl]
>> For this type of data /var/tmp is not the right place.
> 
> Actually, /var/tmp/ is the right place for this kind of data.

For the examples I mentioned, those files don't need to be persistent, so
/var/tmp would not be the right place.

> I am sure there are programs saving large files in /tmp/, but for me
> this only proves that there are programs with bugs around.  Bugs that
> should be fixed, not worked around.

Well, I don't consider programs using /tmp for large temporary files as buggy as
long as someone can provide reference for it.
At least neither the FHS nor the debian-policy give justification for that.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>:
Bug#630615; Package initscripts. (Wed, 15 Jun 2011 18:15:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Petter Reinholdtsen <pere@hungry.com>:
Extra info received and forwarded to list. Copy sent to Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>. (Wed, 15 Jun 2011 18:15:03 GMT) Full text and rfc822 format available.

Message #45 received at 630615@bugs.debian.org (full text, mbox):

From: Petter Reinholdtsen <pere@hungry.com>
To: Michael Biebl <biebl@debian.org>
Cc: 630615@bugs.debian.org
Subject: Re: [Pkg-sysvinit-devel] Bug#630615: RAMTMP should default to no
Date: Wed, 15 Jun 2011 20:11:00 +0200
[Michael Biebl]
> For the examples I mentioned, those files don't need to be
> persistent, so /var/tmp would not be the right place.

I must have been unclear.  /var/tmp/ is not for persistent data.  It
is for temporary data, but not expected to disappear during boot.
/tmp/ is for temporary data which is expected to disappear during
boot.  Persistent data go in /var/lib/ or another more sensible
location. :)

> Well, I don't consider programs using /tmp for large temporary files
> as buggy as long as someone can provide reference for it.

I am not trying to convince you, I am just trying to explain how
things work.  These days, I do not have the spare time available that
is needed to try to convince you. :)

It might interest you to know that on Solaris, /tmp/ has been a RAM
file system for probably 15 years now, and any portable program need
to take the simple fact that /tmp/ is not for large files.

Happy hacking,
-- 
Petter Reinholdtsen




Information forwarded to debian-bugs-dist@lists.debian.org, Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>:
Bug#630615; Package initscripts. (Wed, 15 Jun 2011 20:48:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Roger Leigh <rleigh@codelibre.net>:
Extra info received and forwarded to list. Copy sent to Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>. (Wed, 15 Jun 2011 20:48:08 GMT) Full text and rfc822 format available.

Message #50 received at 630615@bugs.debian.org (full text, mbox):

From: Roger Leigh <rleigh@codelibre.net>
To: Petter Reinholdtsen <pere@hungry.com>, 630615@bugs.debian.org
Cc: Michael Biebl <biebl@debian.org>
Subject: Re: Bug#630615: [Pkg-sysvinit-devel] Bug#630615: RAMTMP should default to no
Date: Wed, 15 Jun 2011 21:46:20 +0100
[Message part 1 (text/plain, inline)]
On Wed, Jun 15, 2011 at 05:33:59PM +0100, Roger Leigh wrote:
> On Wed, Jun 15, 2011 at 05:56:59PM +0200, Petter Reinholdtsen wrote:
> > [Michael Biebl]
> > > the default for new installations is to use RAMTMP=yes.
> > 
> > Hm, do not remember doing this change.  Anyone know when it happened?
> 
> This was done as part of the /run work a couple of months back.
> 
> This was done following the discussion about default size limits
> for the various tmpfses in use (/run, /run/lock, /run/shm, and
> /tmp) on the debian-devel list, and also on #debian-devel.  At
> the time, the consensus appeared to be generally in favour of
> the change.

I'll follow up to the other messages in this one mail.

Discussion on -devel (all in the same thread):
http://lists.debian.org/debian-devel/2011/04/msg00554.html
http://lists.debian.org/debian-devel/2011/04/msg00615.html
http://lists.debian.org/debian-devel/2011/04/msg00703.html
Note that the dicussion at the time was not initially
proposing to make it the default, merely a configurable option,
but consenus appeared to change in favour of making it the
default as well.  I don't have any IRC logs from the time in
question I'm afraid.  It might have been mentioned in other
threads as well.

The FHS defines the persistence/lifetime for /tmp and /var/tmp.
It does not make any recommendations about size.
/tmp contents are not guaranteed to be preserved across reboots
/var/tmp contents are preserved across reboots (but may still
be cleaned after a certain time duration).

Historical practice is that /tmp is small, and /var/tmp is
rather larger.  When using Sun/Solaris systems back around 2000,
/tmp was always a tmpfs (it's the default), and /var/tmp was
disc.  Solaris tmpfs didn't have size limits (filling it would
hang the system--I remember an undergrad being told off for
trying to download a RedHat ISO image to /tmp and killing the
system).  On these systems files in /tmp were cleaned hourly,
and files in /var/tmp weekly.  Files needing longer-term storage
went in /var/preserve (cleaned every few months) or on other
storage.


There are three possibilities for /tmp:
- as a subdirectory of the root filesystem
- as a separately mounted filesystem
- as a tmpfs

All three have pros and cons.

1) Subdirectory of the root filesystem

This can be a very large filesystem if you install using just
one large filesystem, or with /home separate.  But it's not
guaranteed.

Example: rootfs contains only / and /usr:
% df /
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/ravenclaw-root
                       9611492   8364556    758696  92% /
% df /
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/hufflepuff-root
                      19223252   7026936  11219832  39% /

Allowing for the 5% reserved blocks, the first doesn't have
much free space to accommodate /tmp at all.  The second has many
gigabytes free though (despite being a much smaller system).

The point I'm trying to make here is that there are no guarantees
at all about how much free space the root filesystem has to
accomodate /tmp.  And changes in usage post-install may greatly
reduce its capacity.

2) Separately mounted filesystem

This needs manual setup: a filesystem needs making, and this needs
mounting in /etc/fstab.  Its size is exactly as large as the admin
chooses.

3) As a tmpfs

The default size is 20% of the core memory.

This may vary significantly depending upon the amount of memory
installed in the system:

% mount | grep /tmp 
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime,size=1639592k)
% df /tmp
Filesystem           1K-blocks      Used Available Use% Mounted on
tmpfs                  1639592        60   1639532   1% /tmp

% mount | grep /tmp 
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime,size=206248k)
% df /tmp
Filesystem           1K-blocks      Used Available Use% Mounted on
tmpfs                   206248         0    206248   0% /tmp

This is using the same two examples as above.  The systems have
8 GiB and 1 GiB core memory, respectively.

Customisation: just add an fstab entry like this:
  tmpfs  /tmp  tmpfs  nosuid,nodev,size=8g,mode=1777  0  0
(note, this is all documented)

This requires that you have the memory and/or swap to back the
size specified.


The bug:
The RAMTMP feature as implemented is working exactly as designed.  It
is not buggy in itself.  The question is whether it should be the
default or not.


Expectations:
What is the minimum size that an application should expect /tmp to
be, and how much of that space should an application expect to be
available to satisfy its needs?

Tricky question.  The simple fact of the matter is, however, we
don't make /any/ guarantees regarding minimum size and available
space.  Depending upon the partitioning scheme used, and the free
space on the partition containing /tmp, there may be GiB of free
space, or little or no space at all.  Other applications and users
may use all the space leaving nothing for you.

In the IRC discussion, it was mentioned that some DVD authoring
applications were using /tmp to create/store 4GiB disc images.
Also, backup software used /tmp to store multi-gigabyte backups
during its operation.  I would argue that any application expecting
to be able to store such large files in /tmp has wholly unrealistic
expectations.  The admin may configure the system such that /tmp
can meet these demands, but to expect the default to meet them is
impossible.  This isn't specific to /tmp as a tmpfs; we don't make
these guarantees with disc-backed filesystems either.  Though I will
allow that, depending upon the partitioning scheme used, a disc-
based filesystem /may/ allow for much larger file sizes (but this
is not guaranteed).

In contrast to disc-based filesystems, which may be filled up,
tmpfs does offer certain guarantees.  Because it's not shared
with other data (like if on the rootfs) it's dedicated for /tmp
usage alone.  This means that (with the default), you are
guaranteed to get a usable filesystem with a size of 20% of the
core memory, and the size is configurable.  Additionally, should
it be filled to capacity, you are not going to interfere with the
functioning of the base system.  It does have the limitation that
it might not be as big as you require by default, but you can be
certain that there will be some free space there after boot.


Initial setup:
I would like to see the Debian installer support setup of /tmp to
permit
- disabling of /tmp on tmpfs
- setting of a tmpfs size other than 20% core
- allocation of sufficient backing store (swap) during partitioning
If we wanted to guarantee a minimum tmpfs size here, we could ensure
that there's sufficient swap to up the limit from 20% to something
more, or an absolute value rather than a percentage.


I remain convinced that having /tmp on tmpfs will give us a more
reliable system than having /tmp on disc, for the reasons outlined
above.  We can certainly make the default size better though.

I would also like us to consider future goals, such as read-only root.
Having tmpfs on /tmp is mandatory when root is read-only, but it
makes sense to have it on tmpfs /anyway/.  Having /tmp somewhere
other than the rootfs reduces disc writes, and the chance of disc
corruption.  And it also means better I/O performance since programs
creating temporary files will never cause disc writes (unless swapping
is needed), so discs don't need spinning up etc.  And it's always
guaranteed to be clean on reboot.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>:
Bug#630615; Package initscripts. (Wed, 15 Jun 2011 21:42:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michael Biebl <biebl@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>. (Wed, 15 Jun 2011 21:42:06 GMT) Full text and rfc822 format available.

Message #55 received at 630615@bugs.debian.org (full text, mbox):

From: Michael Biebl <biebl@debian.org>
To: Roger Leigh <rleigh@codelibre.net>
Cc: 630615@bugs.debian.org
Subject: Re: Bug#630615: [Pkg-sysvinit-devel] Bug#630615: RAMTMP should default to no
Date: Wed, 15 Jun 2011 23:38:37 +0200
[Message part 1 (text/plain, inline)]
Hi Roger!

Thanks for answering in such detail. I'll try to comment on a few points.

Am 15.06.2011 22:46, schrieb Roger Leigh:
> On Wed, Jun 15, 2011 at 05:33:59PM +0100, Roger Leigh wrote:

> 
> The FHS defines the persistence/lifetime for /tmp and /var/tmp.
> It does not make any recommendations about size.

Yep, that's also how I read and understand the FHS.

> Historical practice is that /tmp is small, and /var/tmp is
> rather larger.  When using Sun/Solaris systems back around 2000,
> /tmp was always a tmpfs (it's the default), and /var/tmp was
> disc.  Solaris tmpfs didn't have size limits (filling it would
> hang the system--I remember an undergrad being told off for
> trying to download a RedHat ISO image to /tmp and killing the
> system).  On these systems files in /tmp were cleaned hourly,
> and files in /var/tmp weekly.  Files needing longer-term storage
> went in /var/preserve (cleaned every few months) or on other
> storage.

As a fun fact, I made the opposite experience. At university (where $HOME was
shared via NFS and had rather strict quotas) students where told to use /tmp for
larger downloads.
But then, this was not on a Solaris system.

> In the IRC discussion, it was mentioned that some DVD authoring
> applications were using /tmp to create/store 4GiB disc images.
> Also, backup software used /tmp to store multi-gigabyte backups
> during its operation.  I would argue that any application expecting
> to be able to store such large files in /tmp has wholly unrealistic
> expectations.

If I look at todays installers for Linux distros, like openSUSE, Redhat, Ubuntu
or Debian, the default option creates a large /tmp, as it is a subdirectory of
/. I don't know of any Linux distribution which uses tmpfs for /tmp.
/tmp on a separate partition is an option which not all installers offer and
needs to be chosen explicitly.

So while we don't guarantee any minimum sizes for /tmp, applications expecting a
large /tmp is not completely unrealistic.

I acknowledge that my concern is more targetted at a typical desktop/laptop
user, which certainly has different usage of software than a server installation.

> Initial setup:
> I would like to see the Debian installer support setup of /tmp to
> permit
> - disabling of /tmp on tmpfs
> - setting of a tmpfs size other than 20% core
> - allocation of sufficient backing store (swap) during partitioning
> If we wanted to guarantee a minimum tmpfs size here, we could ensure
> that there's sufficient swap to up the limit from 20% to something
> more, or an absolute value rather than a percentage.

Having RAMTMP=no and letting d-i enable it if it finds a minimum amount of ram
would be a good compromise imho.

Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>:
Bug#630615; Package initscripts. (Thu, 16 Jun 2011 19:48:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michael Biebl <biebl@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>. (Thu, 16 Jun 2011 19:48:03 GMT) Full text and rfc822 format available.

Message #60 received at 630615@bugs.debian.org (full text, mbox):

From: Michael Biebl <biebl@debian.org>
To: Roger Leigh <rleigh@codelibre.net>
Cc: 630615@bugs.debian.org
Subject: Re: Bug#630615: [Pkg-sysvinit-devel] Bug#630615: RAMTMP should default to no
Date: Thu, 16 Jun 2011 21:44:47 +0200
[Message part 1 (text/plain, inline)]
Hi Roger,

I'm wondering what the plans are regarding /etc/init.d/mountoverflowtmp and
RAMTMP. Will mountoverflowtmp be dropped if you enable RAMTMP by default?

Cheers,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>:
Bug#630615; Package initscripts. (Fri, 17 Jun 2011 09:57:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Roger Leigh <rleigh@codelibre.net>:
Extra info received and forwarded to list. Copy sent to Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>. (Fri, 17 Jun 2011 09:57:09 GMT) Full text and rfc822 format available.

Message #65 received at 630615@bugs.debian.org (full text, mbox):

From: Roger Leigh <rleigh@codelibre.net>
To: Michael Biebl <biebl@debian.org>
Cc: 630615@bugs.debian.org
Subject: Re: Bug#630615: [Pkg-sysvinit-devel] Bug#630615: RAMTMP should default to no
Date: Fri, 17 Jun 2011 10:55:42 +0100
[Message part 1 (text/plain, inline)]
On Thu, Jun 16, 2011 at 09:44:47PM +0200, Michael Biebl wrote:
> I'm wondering what the plans are regarding /etc/init.d/mountoverflowtmp and
> RAMTMP. Will mountoverflowtmp be dropped if you enable RAMTMP by default?

It will still be needed as a fallback if the admin chose to
disable RAMTMP, or configured it to be too small.  So I think
it can probably remain as is--in the common case it would just
be ignored.

BTW, I'll reply to your other reply soon--I've been asking the
installer team about the issue, so I'll follow up once I have
some feedback about that.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>:
Bug#630615; Package initscripts. (Sat, 09 Jul 2011 11:33:33 GMT) Full text and rfc822 format available.

Acknowledgement sent to Roger Leigh <rleigh@codelibre.net>:
Extra info received and forwarded to list. Copy sent to Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>. (Sat, 09 Jul 2011 11:33:37 GMT) Full text and rfc822 format available.

Message #70 received at 630615@bugs.debian.org (full text, mbox):

From: Roger Leigh <rleigh@codelibre.net>
To: Michael Biebl <biebl@debian.org>, 630615@bugs.debian.org
Subject: Re: Bug#630615: RAMTMP should default to no
Date: Sat, 9 Jul 2011 12:28:04 +0100
[Message part 1 (text/plain, inline)]
On Wed, Jun 15, 2011 at 05:35:08PM +0200, Michael Biebl wrote:
> the default for new installations is to use RAMTMP=yes.
> I think having RAMTMP as optional feature is great, but it should
> default to no, because this is the safer default:

To follow up on this issue, I discussed this a week ago with
the debian-installer folks on #debian-boot, and I've now
opened #633299 which is a feature request for the installer
to make configuration of this option possible during
installation.

If you have any thoughts on how best to allow configuation
within the installer, following up to the d-i bug would be
appreciated.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>:
Bug#630615; Package initscripts. (Sat, 24 Mar 2012 20:42:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Joey Hess <joeyh@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>. (Sat, 24 Mar 2012 20:42:03 GMT) Full text and rfc822 format available.

Message #75 received at 630615@bugs.debian.org (full text, mbox):

From: Joey Hess <joeyh@debian.org>
To: 630615@bugs.debian.org
Cc: Roger Leigh <rleigh@debian.org>, Steve Langasek <vorlon@debian.org>
Subject: Re: #630615: RAMTMP should default to no
Date: Sat, 24 Mar 2012 16:38:39 -0400
[Message part 1 (text/plain, inline)]
The major flaw in Roger's reasoning in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=630615#50
is that he does not consider the straight-line default install.
That default is to make one large filesystem for /, with only a small
additional partition for swap (and in some cases one for /boot).

So the default on Debian systems for basically forever (at least since
there has been a d-i) has been for a large amount of space available for
/tmp. Every single person who has run into problems with a too small
/tmp, then, has made an active decision that resulted in their problems.
Before, we gave them enough rope, but we did not force them to tie a knot
in it. Now we've got the noose cleverly positioned just above the pillow
they're sleeping on.

In other words, the release of Wheezy threatens to reduce what has
increased over time from typically 20 gb, 80 gb, 200 gb, or 1+ tb
of space available for /tmp; to sizes that range from 5 mb to 800 mb.

I've taken the liberty of assigning several bugs to initscripts that
point to real user experiences where the tmpfs /tmp causes problems.
(#665634, #665635, #665631, #665406)
(Conceivably these bugs could be instead assigned to all the programs
that are using /tmp. Or they could be merged into this one.
Any preference for future bugs?)

The choice to not make this change on upgrade has essentially prevented
us from testing and quantifying the problems that result. So we can
expect a great deal many more problems to turn up as more and more less
and less experienced users are exposed to Wheezy in new installs.

Roger's interest in having d-i provide configurability of the tmpfs is
admirable, but unfortunatly d-i has few developers, especially partman
developers. And #633299 seems to be all about providing configurability,
rather than affecting the installation defaults. Also, there is not
really a lot of time to develop d-i left.

I feel that the only sane option at this point is to revert the change,
or have d-i force it *off*, perhaps on all except the largest memory
systems. (Or Steve suggested, take it to the technical committee.)

-- 
see shy jo
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>:
Bug#630615; Package initscripts. (Wed, 28 Mar 2012 17:03:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Joey Hess <joeyh@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>. (Wed, 28 Mar 2012 17:03:03 GMT) Full text and rfc822 format available.

Message #80 received at 630615@bugs.debian.org (full text, mbox):

From: Joey Hess <joeyh@debian.org>
To: 630615@bugs.debian.org
Subject: Re: #630615: RAMTMP should default to no
Date: Wed, 28 Mar 2012 13:01:44 -0400
[Message part 1 (text/plain, inline)]
Two more breakages to report. One is bug #666096, apparently involving
flash or html5 video breaking due to the buffered video filling /tmp.

The other is that multiple people have reported that tmpfs /tmp broke
sort(1). Since sort can be fed any size input, when it exceeds its 
memory buffer size, a temp file is used. Breaking sort is a real WTF.

-- 
see shy jo
[signature.asc (application/pgp-signature, inline)]

Marked as found in versions sysvinit/2.88dsf-18 and sysvinit/2.88dsf-22. Request was from Roger Leigh <rleigh@codelibre.net> to control@bugs.debian.org. (Mon, 16 Apr 2012 21:42:14 GMT) Full text and rfc822 format available.

Merged 630615 653329 665406 665631 665634 666096 666696 Request was from Roger Leigh <rleigh@codelibre.net> to control@bugs.debian.org. (Mon, 16 Apr 2012 21:42:20 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>:
Bug#630615; Package initscripts. (Mon, 16 Apr 2012 22:57:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Roger Leigh <rleigh@codelibre.net>:
Extra info received and forwarded to list. Copy sent to Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>. (Mon, 16 Apr 2012 22:57:03 GMT) Full text and rfc822 format available.

Message #89 received at 630615@bugs.debian.org (full text, mbox):

From: Roger Leigh <rleigh@codelibre.net>
To: 630615@bugs.debian.org, 666696-submitter@bugs.debian.org, debian-user@lists.debian.org
Subject: Re: Defaults of tmpfs on /tmp redux
Date: Mon, 16 Apr 2012 23:56:01 +0100
I have done a significant reworking of the handling of tmpfs
on /tmp.  Please have a look at the packages here:

http://people.debian.org/~rleigh/sysvinit/

I would be very grateful for any feedback regarding these
changes.  While these don't disable tmpfs on /tmp by default,
they do increase the default limits.  Further increases are
possible.

The full list of changes is here:
http://people.debian.org/~rleigh/sysvinit/sysvinit_2.88dsf-23_amd64.changes

Summary:
- All tmpfs settings moved to /etc/default/tmpfs; it is of course
  possible to continue to use /etc/fstab to override them.
  /etc/default/rcS is no longer used.
- overflowtmp handling, which was unobvious and inflexible, has
  been merged with the RAMTMP handling, and the limit for its
  use is settable, and it is documented in tmpfs(5).
- one can configure the tmpfs size as a percentage of the VM size
  (including swap) rather than of the RAM size.  Just use %VM in
  place of %.  /tmp and /run/shm default to 20%VM rather than
  20% [RAM].  This should lead to a large increase if you have
  a decent amount of swap available.  Note: %VM does not work in
  fstab, though patching the kernel to do this looks easy enough.
- if you have a small amount of RAM, tmpfs on /tmp is automatically
  disabled (modulo read only root and overflow conditions).
  Currently set at 64 MiB, but can be changed.
- if you have a separate mount for /tmp in /etc/fstab (non-tmpfs),
  there won't be a separate hidden tmpfs mount.
- improved cleanup of masked temporary files at boot.


So, what kind of feedback is needed?  After installing the updated
packages linked to above, I'd like to know if you're still running
into issues with lack of space on /tmp, and (whether or not you
have problems):

- the size and free space on the root filesystem (df /)
- the amount of system memory (cat /proc/meminfo | grep MemTotal)
- the amount of swap (cat /proc/meminfo | grep SwapTotal)
- the size of the tmpfs on /tmp (mount | grep /tmp)
- the amount of free space on /tmp (df /tmp)
- which applications and/or shell commands you were using which caused
  you to run out of space.  The size of the files created would be
  useful to know. (ls -l /tmp and du -sm /tmp/*)


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux    http://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-    GPG Public Key      F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800




Disconnected #653329 from all other report(s). Request was from Roger Leigh <rleigh@codelibre.net> to control@bugs.debian.org. (Mon, 16 Apr 2012 23:15:05 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>:
Bug#630615; Package initscripts. (Fri, 25 May 2012 02:15:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jeremy Bicha <jbicha@ubuntu.com>:
Extra info received and forwarded to list. Copy sent to Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>. (Fri, 25 May 2012 02:15:03 GMT) Full text and rfc822 format available.

Message #96 received at 630615@bugs.debian.org (full text, mbox):

From: Jeremy Bicha <jbicha@ubuntu.com>
To: 630615@bugs.debian.org
Subject: Re: Defaults of tmpfs on /tmp redux
Date: Thu, 24 May 2012 22:10:46 -0400
64 MiB seems a ridiculously low threshold. How about 512MiB instead?
I'd find it difficult to use a desktop machine with less than 1GB of
RAM and think that reserving 20% of that limited RAM for /tmp is not
going to make users happy.

Jeremy




Information forwarded to debian-bugs-dist@lists.debian.org, Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>:
Bug#630615; Package initscripts. (Fri, 25 May 2012 03:21:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Henrique de Moraes Holschuh <hmh@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>. (Fri, 25 May 2012 03:21:03 GMT) Full text and rfc822 format available.

Message #101 received at 630615@bugs.debian.org (full text, mbox):

From: Henrique de Moraes Holschuh <hmh@debian.org>
To: Jeremy Bicha <jbicha@ubuntu.com>, 630615@bugs.debian.org
Subject: Re: [Pkg-sysvinit-devel] Bug#630615: Defaults of tmpfs on /tmp redux
Date: Fri, 25 May 2012 00:17:42 -0300
On Thu, 24 May 2012, Jeremy Bicha wrote:
> 64 MiB seems a ridiculously low threshold. How about 512MiB instead?
> I'd find it difficult to use a desktop machine with less than 1GB of
> RAM and think that reserving 20% of that limited RAM for /tmp is not

tmpfs reserves nothing of the sort.  It can use UP TO that ammount of
_virtual_ memory, which is very different from "reserving".

That said, 128 or 256MiB would probably be a better threshold.

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




Information forwarded to debian-bugs-dist@lists.debian.org, Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>:
Bug#630615; Package initscripts. (Thu, 31 May 2012 01:27:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bob Bib <bobbibmpn@mail.ru>:
Extra info received and forwarded to list. Copy sent to Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>. (Thu, 31 May 2012 01:27:06 GMT) Full text and rfc822 format available.

Message #106 received at 630615@bugs.debian.org (full text, mbox):

From: Bob Bib <bobbibmpn@mail.ru>
To: 630615@bugs.debian.org
Subject: RAMTMP should default to YES
Date: Thu, 31 May 2012 04:02:54 +0400
I'm very glad to see the "/tmp in tmpfs" feature enabled by default in Wheezy.

Some notes:
1) '/etc/default/tmpfs' filename is confusing: if it's used (again in new versions) not for usual user-created tmpfs parameters, but _only_ for "system purposes", it's better to rename it to "boottmpfs", "roottmpfs", "systmpfs" etc.;
2) it's good to have an option to set the desired "/tmp in tmpfs" size (in %% of RAM/VM, B/KiB/MiB/GiB etc.) in 'rcS', 'tmpfs' (or whatever the actual one is) config file, not by creating an entry in 'fstab' (since the default value for /tmp is not set in 'fstab' at all);
3) to prevent some "out-of-memory" situations caused by "/tmp in tmpfs", a sufficient swap space (maybe, even a RAM-sized? the swap area created by Debian installer is perhaps too small) should be provided (tmpfs is not ramfs, it luckily can be swapped out).

Reply sent to Roger Leigh <rleigh@debian.org>:
You have taken responsibility. (Wed, 06 Jun 2012 22:51:06 GMT) Full text and rfc822 format available.

Notification sent to Michael Biebl <biebl@debian.org>:
Bug acknowledged by developer. (Wed, 06 Jun 2012 22:51:06 GMT) Full text and rfc822 format available.

Message #111 received at 630615-close@bugs.debian.org (full text, mbox):

From: Roger Leigh <rleigh@debian.org>
To: 630615-close@bugs.debian.org
Subject: Bug#630615: fixed in sysvinit 2.88dsf-26
Date: Wed, 06 Jun 2012 22:48:30 +0000
Source: sysvinit
Source-Version: 2.88dsf-26

We believe that the bug you reported is fixed in the latest version of
sysvinit, which is due to be installed in the Debian FTP archive:

bootlogd_2.88dsf-26_amd64.deb
  to main/s/sysvinit/bootlogd_2.88dsf-26_amd64.deb
initscripts_2.88dsf-26_amd64.deb
  to main/s/sysvinit/initscripts_2.88dsf-26_amd64.deb
sysv-rc_2.88dsf-26_all.deb
  to main/s/sysvinit/sysv-rc_2.88dsf-26_all.deb
sysvinit-utils_2.88dsf-26_amd64.deb
  to main/s/sysvinit/sysvinit-utils_2.88dsf-26_amd64.deb
sysvinit_2.88dsf-26.debian.tar.gz
  to main/s/sysvinit/sysvinit_2.88dsf-26.debian.tar.gz
sysvinit_2.88dsf-26.dsc
  to main/s/sysvinit/sysvinit_2.88dsf-26.dsc
sysvinit_2.88dsf-26_amd64.deb
  to main/s/sysvinit/sysvinit_2.88dsf-26_amd64.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 630615@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Roger Leigh <rleigh@debian.org> (supplier of updated sysvinit package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Mon, 28 May 2012 17:58:38 +0100
Source: sysvinit
Binary: sysvinit sysvinit-utils sysv-rc initscripts bootlogd
Architecture: source amd64 all
Version: 2.88dsf-26
Distribution: unstable
Urgency: low
Maintainer: Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>
Changed-By: Roger Leigh <rleigh@debian.org>
Description: 
 bootlogd   - daemon to log boot messages
 initscripts - scripts for initializing and shutting down the system
 sysv-rc    - System-V-like runlevel change mechanism
 sysvinit   - System-V-like init utilities
 sysvinit-utils - System-V-like utilities
Closes: 386368 630615 665635 666698 674208 674460 674517
Changes: 
 sysvinit (2.88dsf-26) unstable; urgency=low
 .
   [ Roger Leigh ]
   * initscripts:
     - /run/shm is mounted noexec.  Closes: #386368.
     - The RAMSHM and RAMTMP settings in /etc/default/rcS are used if
       present, though the replacement settings in /etc/default/tmpfs
       will override these, if enabled.
     - Revert RAMTMP setting to be disabled by default.
       Closes: #630615, #665635, #666698, #674517.
     - Don't prompt the user on upgrade if rcS was not modified by
       the admin.  Closes: #674460.
   * sysvinit-utils:
     - Fix typo in fstab-decode(8).  Thanks to Bjarni Ingi Gislason.
       Closes: #674208.
Checksums-Sha1: 
 3c82521046fe0bc28aa23f0d4a34271bad6f9a53 2342 sysvinit_2.88dsf-26.dsc
 2652be7e905b67b5a6e8da86a794b98a1a1f0738 201474 sysvinit_2.88dsf-26.debian.tar.gz
 d29edc85b963aaefc4a6171cbfb084ee7ab34723 130062 sysvinit_2.88dsf-26_amd64.deb
 61670601d0b467d078578a4b944077767e6f3c18 96020 sysvinit-utils_2.88dsf-26_amd64.deb
 81de4371959b1339c1aead437d34d3bcea182567 74976 sysv-rc_2.88dsf-26_all.deb
 3932b1b997387d7c28a283125ea19c2cca629b31 87720 initscripts_2.88dsf-26_amd64.deb
 be47b5a4e7b12b52e34fb1df9fbc62e2f6822e39 52116 bootlogd_2.88dsf-26_amd64.deb
Checksums-Sha256: 
 ee6385d301943c4aeb35b037a46ab8c9792707deadcdd32c4274e80389409d87 2342 sysvinit_2.88dsf-26.dsc
 86cc67267ad0d76143aabd10084e93d95c6d4ee4de5fc3d49f073695ca0b9d87 201474 sysvinit_2.88dsf-26.debian.tar.gz
 13863704c20c519c768e74501d7410122b4bdd8197822710a381a4f8caebd0e6 130062 sysvinit_2.88dsf-26_amd64.deb
 1ca84a97924e87200cbe4a99dc5a655ea14ff732a1722b516f47bb5873833b0b 96020 sysvinit-utils_2.88dsf-26_amd64.deb
 7034a86747cc2eefa0a4ea6879371f5f5219a58584489bbc555f6907bae362a6 74976 sysv-rc_2.88dsf-26_all.deb
 ea9ca8dab36bd61a1d61049c291e87ad9696d2426e60d03afeab209abde4ce5a 87720 initscripts_2.88dsf-26_amd64.deb
 2300e379d3ee055625a78ddd5e574ae713b86a577689addf0181dccf0bf4a71f 52116 bootlogd_2.88dsf-26_amd64.deb
Files: 
 60ec6cbc959ca118e00cffbaef5861e3 2342 admin required sysvinit_2.88dsf-26.dsc
 1cf2ebc37120e3d4e7d50fb80588355d 201474 admin required sysvinit_2.88dsf-26.debian.tar.gz
 bea6e21164dc526215269394552362ae 130062 admin required sysvinit_2.88dsf-26_amd64.deb
 3312dc77c0cadff02c69c1ce5c3c41fa 96020 admin required sysvinit-utils_2.88dsf-26_amd64.deb
 b4108cfe9f64c5021171bd56d1122db2 74976 admin required sysv-rc_2.88dsf-26_all.deb
 e284939ba57576e674d64c61507ac030 87720 admin required initscripts_2.88dsf-26_amd64.deb
 e4a725feb457c9d603df328007f1a56e 52116 admin optional bootlogd_2.88dsf-26_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCgAGBQJPz9lVAAoJEOJSSsUKn1xZcTkQAItYpP6zhOhgHP9EERqjG2M0
uJ2wOJGyGz23tPaYah4jOt1On9ih30EXyoz/1Vk5e56UrBe1V14guw4Qg4nimf1u
SfknjG4xzGf41kus4EpR8OzZXY9GQMtTGBDJsG75UaLZUXEw14bszaRlIZ/Acf6y
x2Q2Sszg0HW5B5Hr32kywo2zlC494XD77y356IWG9VWAxccUY7F+kgKOcQT8wOwL
62TP6ItzH+2d1CpjlFW1RXNXBGyo2U5t8f/rdoSuWVgT0ANHKGoFhyDJ2w/vK656
vNW/JM9HWC+f6lr6HsY4th1B7ZMpImB13WVGIzFsrB+TcFADJ48ikTgOA2jnBlRo
91AYH3sxuBw+iqJMzZsHuZ3cL2Ua4Dwd+/o8o8JYHWpLuY0X5elXIeyZR88KseZx
MYoyixJy1AgiWvre4gut4U5pHq+MUkV/9z3RywDL8S6IfvSnWhhNibeAqcv1ThDB
Ey3YxyY5X3a75hhNtufW4avFWyr4Q+7EGQVQgD08QI0cYIDQN2gZwTUvH9RhXq6T
03h+PT008cwu9GY+2BIxpPWhKgz2jD3h0ke+bP9zXa8BRYDdWNfMHlk30PoUkpoX
X+QNPl4gNbEINrniSL8WkE5Z4pL3qs+UKVn3oIx6FEC9LKi/ut932fgQtZXzfL+M
kk9A39T0ujTHw2mUoXD/
=gNVP
-----END PGP SIGNATURE-----





Reply sent to Roger Leigh <rleigh@debian.org>:
You have taken responsibility. (Wed, 06 Jun 2012 22:51:07 GMT) Full text and rfc822 format available.

Notification sent to Guido Günther <agx@sigxcpu.org>:
Bug acknowledged by developer. (Wed, 06 Jun 2012 22:51:07 GMT) Full text and rfc822 format available.

Reply sent to Roger Leigh <rleigh@debian.org>:
You have taken responsibility. (Wed, 06 Jun 2012 22:51:08 GMT) Full text and rfc822 format available.

Notification sent to Joey Hess <joeyh@debian.org>:
Bug acknowledged by developer. (Wed, 06 Jun 2012 22:51:08 GMT) Full text and rfc822 format available.

Reply sent to Roger Leigh <rleigh@debian.org>:
You have taken responsibility. (Wed, 06 Jun 2012 22:51:08 GMT) Full text and rfc822 format available.

Notification sent to Joey Hess <joeyh@debian.org>:
Bug acknowledged by developer. (Wed, 06 Jun 2012 22:51:08 GMT) Full text and rfc822 format available.

Reply sent to Roger Leigh <rleigh@debian.org>:
You have taken responsibility. (Wed, 06 Jun 2012 22:51:09 GMT) Full text and rfc822 format available.

Notification sent to Joey Hess <joeyh@debian.org>:
Bug acknowledged by developer. (Wed, 06 Jun 2012 22:51:09 GMT) Full text and rfc822 format available.

Reply sent to Roger Leigh <rleigh@debian.org>:
You have taken responsibility. (Wed, 06 Jun 2012 22:51:10 GMT) Full text and rfc822 format available.

Notification sent to Moray Allan <moray@debian.org>:
Bug acknowledged by developer. (Wed, 06 Jun 2012 22:51:10 GMT) Full text and rfc822 format available.

Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Sat, 01 Sep 2012 07:25:48 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Wed Apr 16 17:15:16 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.