[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#669726: marked as done (release-notes: Please document tmpfs filesystem changes for wheezy)

Your message dated Wed, 24 Apr 2013 20:48:50 +0100
with message-id <1366832930.18536.15.camel@jacala.jungle.funky-badger.org>
and subject line Re: Bug#669726: release-notes: Please document tmpfs filesystem changes for wheezy
has caused the Debian Bug report #669726,
regarding release-notes: Please document tmpfs filesystem changes for wheezy
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org

669726: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=669726
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: release-notes
Severity: normal
Tags: patch

Proposed text:

Changes to the configuration and defaults of tmpfs filesystems

In previous releases, tmpfs filesystems were mounted on /lib/init/rw,
/dev/shm and optionally on /var/lock and /var/run.  /lib/init/rw has
been removed, and the others have been moved under /run.  /var/run and
/var/lock were configured using RAMRUN and RAMLOCK in
/etc/default/rcS.  All tmpfs filesystems are now configurable using
/etc/default/tmpfs; the old settings are not migrated automatically.

                            Old setting       New setting
Old location  New location  /etc/default/rcS  /etc/default/tmpfs
/lib/init/rw  /run          N/A               N/A
/var/run      /run          RAMRUN            N/A
/var/lock     /run/lock     RAMLOCK           RAMLOCK
/dev/shm      /run/shm      N/A               RAMSHM
N/A           /tmp          N/A               RAMTMP

The migration of data to the new locations will occur automatically
during the upgrade and will continue to be available at the old and
new locations, with the exception of /lib/init/rw.  No action is
required on your part, though you may wish to customise which tmpfs
filesystems are mounted, and their size limits, in /etc/default/tmpfs
after the upgrade is complete.  Please see the tmpfs(5) manual page
for further details.

If you have written any custom scripts which make use of /lib/init/rw,
these must be updated to use /run instead.

/tmp is now a tmpfs by default.  While this should not affect your use
of the system in any noticeable way, please note that
- the contents of /tmp are not preserved across reboots;
- /var/tmp exists for this purpose
- the maximum size of /tmp may (depending upon your specific system)
  be smaller than before.  If you find that there is insufficient
  free space, it is possible to increase the size limits; see
- applications which create excessively large files in /tmp may cause
  /tmp to run out of free space.  Such applications should not be
  using /tmp, and require fixing.  Please consider filing a bug report
  against the application in question if you experience such an

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (550, 'unstable'), (500, 'testing'), (400, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

--- End Message ---
--- Begin Message ---
On Tue, 2013-04-16 at 08:32 +0900, Charles Plessy wrote:
> Le Sun, Apr 07, 2013 at 09:04:16AM +0300, Andrei POPESCU a écrit :
> > On Vi, 05 apr 13, 14:48:44, Julien Cristau wrote:
> > > 
> > > Two comments:
> > > - I don't think the last two sentences are particularly helpful in the
> > >   RN, so I'd drop them
> > > - I'm confused by the bit about TMPDIR, since we don't say anything
> > >   about setting that variable anywhere, so even if an app obeys TMPDIR
> > >   if it's set, it'll still fill up /tmp by default.
> > 
> > I'd reword it slightly:
> If the last two sentences are problematic, I think that the patch is
> trivial to be edited, that is: if you decide to remove them, please
> ping me if you want me to refresh the patch.

I've committed Charles's last patch (minus the contentious sentences) as
r9767; thanks.



--- End Message ---

Reply to: