Improper filesystem unmount order (swap on files)

Bug #48517 reported by Adomas Paltanavičius
18
Affects Status Importance Assigned to Milestone
sysvinit (Debian)
Fix Released
Unknown
sysvinit (Ubuntu)
Fix Released
Wishlist
Unassigned

Bug Description

Binary package hint: initscripts

When turning off my computer, I noticed one `failed' status line. It was:
  * Unmounting local filesystems [fail]
Followed by:
  * Deactivating swap [ok]

Since I use ordinary files instead of dedicated partitions for swap, I found that very natural. I also think it is more than just a valid usage pattern (no problems with resizing partitions etc) and with regards to that, suggest the following patch to /etc/init.d/umountfs:

20,40c20
< # List all mounts, deepest mount point first
< LANG=C sort -r -k 2 /etc/mtab |
< (
< DIRS=""
< while read DEV DIR TYPE REST ; do
< if [ "x$TYPE" == "xtmpfs"]; then
< DIRS="$DIRS $DIR" # Unmount tmpfs before turning off swap
< fi
< done
< umount -r -d $DIRS
< )
<
< # Make sure tmpfs file systems are umounted before turning off
< # swap, to avoid running out of memory if the tmpfs filesystems
< # use a lot of space.
< log_action_begin_msg "Deactivating swap"
< swapoff -a
< log_action_end_msg $?
<
< # Umount all filesystems now
---
> # Umount all filesystems except root and the virtual ones
63a44,50
>
> # Make sure tmpfs file systems are umounted before turning off
> # swap, to avoid running out of memory if the tmpfs filesystems
> # use a lot of space.
> log_action_begin_msg "Deactivating swap"
> swapoff -a
> log_action_end_msg $?

It firstly unmounts tmpfs, then deactivas swap and remaining
filesystems lastly. I'd like to hear if there are any reasons for not
applying this patch, if any.

Revision history for this message
In , Marcel Sebek (sebek64) wrote :

On Fri, Sep 16, 2005 at 10:55:37AM +0200, johannes wrote:
> hi all,
>
> i'm using a swapfile in a file on a local filesystem "/data/swapfile" (not a swap partition!)
> during shutdown /etc/init.d/umountfs first tries to unmount all local filesystems and then deactivates all swap
> but unmounting of the partitition wich has the swapfile "/data" fails because the swapfile is still active
>
> if i change /etc/init.d/umountfs in such a way that it first calls swapoff and then unmounts the local filesystems it works correctly
>

I think it should unmount all tmpfs'es (except /dev and similar) first.
Then it can safely turn off swapping. Doing it in reverse order could
cause trouble in some configurations (eg. /tmp as tmpfs).

Something like this:

do_stop () {
    # Umount all memory filesystems except /dev
    log_begin_msg "Unmounting memory filesystems..."
    LANG=C sort -r -k 2 /etc/mtab |
    (
    DIRS=""
    while read DEV DIR TYPE REST ; do
        case "$TYPE" in
        tmpfs)
            ;;
 *)
            continue
            ;;
        esac

        case "$DIR" in
        /dev)
            continue
            ;;
        esac
        DIRS="$DIRS $DIR"
    done
    umount -r -d $DIRS
    )
    log_end_msg $?

    log_begin_msg "Deactivating swap..."
    swapoff -a
    log_end_msg $?

    # Umount all filesystems except root and the virtual ones
    log_begin_msg "Unmounting local filesystems..."

    # List all mounts, deepest mount point first
    LANG=C sort -r -k 2 /etc/mtab |
    (
    DIRS=""
    while read DEV DIR TYPE REST ; do
 case "$DIR" in
 /|/proc|/dev|/.dev|/dev/pts|/proc/*|/sys)
     continue # Ignoring virtual file systems needed later
     ;;
 esac

        case $TYPE in
        proc|procfs|linprocfs|devfs|sysfs|usbfs|usbdevfs|devpts)
     continue # Ignoring non-tmpfs virtual file systems
            ;;
        esac
 DIRS="$DIRS $DIR"
    done
    umount -r -d $DIRS
    )
    log_end_msg $?
}

--
Marcel Sebek

Revision history for this message
In , Miquel van Smoorenburg (miquels) wrote : Re: Bug#328582: /etc/init.d/umountfs: swapoff should be called before unmounting localfs and not after?

On Fri, 2005-09-16 at 13:47 +0200, Marcel Sebek wrote:
> On Fri, Sep 16, 2005 at 10:55:37AM +0200, johannes wrote:
> > hi all,
> >
> > i'm using a swapfile in a file on a local filesystem "/data/swapfile" (not a swap partition!)
> > during shutdown /etc/init.d/umountfs first tries to unmount all local filesystems and then deactivates all swap
> > but unmounting of the partitition wich has the swapfile "/data" fails because the swapfile is still active
> >
> > if i change /etc/init.d/umountfs in such a way that it first calls swapoff and then unmounts the local filesystems it works correctly

It already does that, in the (misnamed) umountnfs.sh script which runs
before umountfs.... read it.

Mike.

Revision history for this message
In , johannes (qaz99af) wrote : Re: Bug#328582: /etc/init.d/umountfs: swapoff should be called before unmounting localfs and not after?

On Wednesday 28 September 2005 00:59, you wrote:
>
> It already does that, in the (misnamed) umountnfs.sh script which runs
> before umountfs.... read it.
>
> Mike.

hi mike,

i fail to see how umountnfs.sh could call swapoff

johannes

==========================
my umountnfs.sh:

#! /bin/sh
### BEGIN INIT INFO
# Provides: umountnfs
# Required-Start: sendsigs
# Required-Stop:
# Default-Start: 6
# Default-Stop:
# Short-Description: Unmount all network filesystems except the root file
system.
# Description: Also unmounts all virtual filesystems (proc, devfs,
# devpts, usbfs, sysfs) that are not mounted at the
# top-level.
#
# Also unmounts all virtual filesystems (proc,
# devfs, devpts, usbfs, sysfs) that are not mounted
# at the top-level.
### END INIT INFO
#
# Version: @(#)umountnfs 2.85-23 29-Jul-2004 <email address hidden>
#

PATH=/sbin:/bin:/usr/sbin:/usr/bin

. /lib/lsb/init-functions

KERNEL=`uname -s`
RELEASE=`uname -r`

case "${KERNEL}:${RELEASE}" in
 Linux:[01].*|Linux:2.[01].*)
  FLAGS=""
  ;;
 Linux:2.[23].*|Linux:2.4.?|Linux:2.4.?-*|Linux:2.4.10|Linux:2.4.10-*)
  FLAGS="-f"
  ;;
 *)
  FLAGS="-f -l"
  ;;
esac

do_stop () {
 # Write a reboot record to /var/log/wtmp before unmounting
 halt -w

 # Remove any .clean files in auto-clean dirs.
 rm -f /tmp/.clean /var/lock/.clean /var/run/.clean

 log_begin_msg "Unmounting remote and non-toplevel virtual filesystems..."

 #
 # Read mtab file and add the directories we want to
 # unmount in reverse to a list.
 #
 (
 DIRS=""
  while read DEV DIR TYPE REST
  do
   case "$DIR" in
    /|/proc|/dev|/dev/pts|/proc/*|/sys)
     continue
     ;;
   esac
   case "$TYPE" in
    nfs|nfs4|smbfs|ncp|ncpfs|cifs|coda|ocfs2|gfs)
     DIRS="$DIR $DIRS"
     ;;
    proc|procfs|linprocfs|devfs|devpts|usbfs|usbdevfs|sysfs)
     DIRS="$DIR $DIRS"
     ;;
   esac
  done
  exec </dev/null
  if [ -n "$DIRS" ]
  then
   umount $FLAGS $DIRS
  fi
 ) </etc/mtab

 log_end_msg 0
}

case "$1" in
    stop)
     do_stop
 ;;
    *)
        ;;
esac

: exit 0

Revision history for this message
In , Debbug-328582 (debbug-328582) wrote : call swapoff before umount please

Hi, for what it's worth, I'm experiencing the same problem
on several boxes with swap files (not partitions),
which seems to cause a journal playback on next boot every
time since the file system was not cleanly unmounted.

The S40umountfs from Sarge does not exhibit this problem
since it does (basically)
umount -ttmpfs -a -r; swapoff -a; umount -a

Why was this changed?
Also, the umountfs files from sarge and sid have
the same version tag ("umountfs 2.85-16 03-Jun-2004 <email address hidden>")
when they are obviously not the same version at all.

Revision history for this message
In , Petter Reinholdtsen (pere-hungry) wrote : Re: /etc/init.d/umountfs: swapoff should be called before unmounting localfs and not after?

I believe the swapoff/umount order was changed to solve bug #84782,
making sure tmpfs file systems are umounted before swap is turned off
and thus improving the chance of not running out of memory for
low-memory machines.

I'm not sure how to modify umountfs to solve both problems.

I agree that it should be possible to use swap files without having to
run fsck at every boot, and that it should be possible to use tmpfs on
some filesystems with fairly large data sets without having problems
shutting down.

Revision history for this message
In , johannes (qaz99af) wrote : Re: Bug#328582: /etc/init.d/umountfs: swapoff should be called before unmounting localfs and not after?

On Saturday 12 November 2005 13:14, Petter Reinholdtsen wrote:
> I believe the swapoff/umount order was changed to solve bug #84782,
> making sure tmpfs file systems are umounted before swap is turned off
> and thus improving the chance of not running out of memory for
> low-memory machines.
>
> I'm not sure how to modify umountfs to solve both problems.
>
> I agree that it should be possible to use swap files without having to
> run fsck at every boot, and that it should be possible to use tmpfs on
> some filesystems with fairly large data sets without having problems
> shutting down.

would this solve the problem?

first unmount tmpfs
then call swapoff
finally unmount normal filesystems

Revision history for this message
In , Thomas Hood (jdthood-yahoo) wrote : retitle

retitle 328582 tmpfs should be umounted and swapoff done before unmounting local filesystems
stop

Revision history for this message
In , Thomas Hood (jdthood-yahoo) wrote : pending

tags 328582 pending
stop

Revision history for this message
In , Petter Reinholdtsen (pere-debian) wrote : Fixed in upload of sysvinit 2.86.ds1-7 to experimental
Download full text (6.9 KiB)

tag 116366 + fixed-in-experimental
tag 160329 + fixed-in-experimental
tag 189356 + fixed-in-experimental
tag 213028 + fixed-in-experimental
tag 220025 + fixed-in-experimental
tag 237074 + fixed-in-experimental
tag 238861 + fixed-in-experimental
tag 272066 + fixed-in-experimental
tag 275680 + fixed-in-experimental
tag 286082 + fixed-in-experimental
tag 286479 + fixed-in-experimental
tag 316423 + fixed-in-experimental
tag 323749 + fixed-in-experimental
tag 328582 + fixed-in-experimental
tag 330155 + fixed-in-experimental
tag 331397 + fixed-in-experimental
tag 332309 + fixed-in-experimental
tag 333836 + fixed-in-experimental
tag 336172 + fixed-in-experimental
tag 339023 + fixed-in-experimental
tag 339979 + fixed-in-experimental
tag 340017 + fixed-in-experimental
tag 341097 + fixed-in-experimental
tag 343596 + fixed-in-experimental
tag 55143 + fixed-in-experimental
tag 89481 + fixed-in-experimental
tag 95390 + fixed-in-experimental

quit

This message was generated automatically in response to an
upload to the experimental distribution. The .changes file follows.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Sat, 17 Dec 2005 21:26:03 +0100
Source: sysvinit
Binary: sysv-rc sysvinit initscripts
Architecture: source i386 all
Version: 2.86.ds1-7
Distribution: experimental
Urgency: low
Maintainer: sysvinit maintainers <email address hidden>
Changed-By: Petter Reinholdtsen <email address hidden>
Description:
 initscripts - Scripts for initializing and shutting down the system
 sysv-rc - System-V-like runlevel change mechanism
 sysvinit - System-V like init utilities
Closes: 55143 89481 95390 116366 160329 189356 213028 220025 237074 238861 272066 275680 286082 286479 316423 323749 328582 330155 331397 332309 333836 336172 339023 339979 340017 341097 343596
Changes:
 sysvinit (2.86.ds1-7) experimental; urgency=low
 .
   [ Petter Reinholdtsen ]
   * Add commented-out code to /etc/init.d/rc for sourcing
     *.sh scripts for runlevel 'S'. This is preparation for fixing
     #339955. Actually fixing it has to wait until other packages
     remove "exit" from their .sh scripts.
   * Implement progress bar support for splash screen. Enabled when
     usplash_write is in PATH. Patch from Scott James Remnant and Ubuntu.
 .
   [ Thomas Hood ]
   * *.sh: Make sure that these do their thing when they aren't given any
     command line arguments (as is the case when they are sourced)
   * initscripts: Improve use of log_* functions
     (Closes: #55143, #116366, #323749)
   * bootclean.sh: Do not delete symlinks-to-directories from /var/run/
     (Closes: #272066)
   * checkroot.sh: Fix double printing of 'Done checking root file system';
     mountall.sh: Fix chopped-up printing of mount information
     (Closes: #339979, #331397, #341097 and presumably closes: #332309)
   * checkroot.sh, checkfs.sh: Save fsck logs (Closes: #189356)
     Thanks to Theodore Y. Ts'o.
   * checkroot.sh, mountvirtfs: Eliminate use of dir_writable in order to
     try to please selinux (Closes: #333836)
   * checkroot.sh: Only run findfs for mount on / (Closes: #275680)
     Thanks to Cameron Hutchison for the patch.
   * mountall.sh...

Read more...

Revision history for this message
In , Petter Reinholdtsen (pere-debian) wrote : Bug#328582: fixed in sysvinit 2.86.ds1-11
Download full text (14.4 KiB)

Source: sysvinit
Source-Version: 2.86.ds1-11

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:

initscripts_2.86.ds1-11_i386.deb
  to pool/main/s/sysvinit/initscripts_2.86.ds1-11_i386.deb
sysv-rc_2.86.ds1-11_all.deb
  to pool/main/s/sysvinit/sysv-rc_2.86.ds1-11_all.deb
sysvinit_2.86.ds1-11.diff.gz
  to pool/main/s/sysvinit/sysvinit_2.86.ds1-11.diff.gz
sysvinit_2.86.ds1-11.dsc
  to pool/main/s/sysvinit/sysvinit_2.86.ds1-11.dsc
sysvinit_2.86.ds1-11_i386.deb
  to pool/main/s/sysvinit/sysvinit_2.86.ds1-11_i386.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 <email address hidden>,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Petter Reinholdtsen <email address hidden> (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 <email address hidden>)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Sun, 22 Jan 2006 22:17:38 +0100
Source: sysvinit
Binary: sysv-rc sysvinit initscripts
Architecture: source i386 all
Version: 2.86.ds1-11
Distribution: unstable
Urgency: low
Maintainer: sysvinit maintainers <email address hidden>
Changed-By: Petter Reinholdtsen <email address hidden>
Description:
 initscripts - Scripts for initializing and shutting down the system
 sysv-rc - System-V-like runlevel change mechanism
 sysvinit - System-V-like init utilities
Closes: 55143 89481 95390 116366 160329 186880 189356 213028 220025 227540 237074 238861 242957 258290 272066 275680 286082 286479 316423 323749 327865 328582 328764 330155 331397 332309 333836 336172 338736 338801 339023 339979 340017 341075 341097 342160 342744 343596 343862 343863 343993 344001 344089 344547 344547 345267 345269 345272 345273 345321 345370 345719 345968 346139 346415
Changes:
 sysvinit (2.86.ds1-11) unstable; urgency=low
 .
   [ Thomas Hood ]
   * rcS(5): Improve
   * sulogin(8): Improve; mention -t option (Closes: #186880)
   * bootlogd(8): Improve; mention need for PTY support
   * initscripts postinst: Update to reflect script name changes
   * initscripts: Harmonize PATH settings
   * checkroot.sh: Don't check for need to start /sbin/update.
     We don't support pre-2.4 kernels any more.
   * checkroot.sh, mountall.sh: Run swapon with -v if VERBOSE!=no
   * Remove obsolete lintian overrides
   * Previous release also
     closes: #258290 "bootlogd: Bad file descriptor"
     closes: #327865 "bootlogd stopped working"
     closes: #328764 "bootlogd fails to start"
 .
   [ Petter Reinholdtsen ]
   * Time to upload all these changes into unstable (Closes: #341075)
   * Revert default VERBOSE value to "yes" to reduce the amount of
     user visible changes in this upload.
 .
 sysvinit (2.86.ds1-10) experimental; urgency=low
 .
   [ Thomas Hood ]
   * bootclean: Adapt from old bootclean.sh; handle return status mor...

Revision history for this message
Adomas Paltanavičius (admp) wrote :

Binary package hint: initscripts

When turning off my computer, I noticed one `failed' status line. It was:
  * Unmounting local filesystems [fail]
Followed by:
  * Deactivating swap [ok]

Since I use ordinary files instead of dedicated partitions for swap, I found that very natural. I also think it is more than just a valid usage pattern (no problems with resizing partitions etc) and with regards to that, suggest the following patch to /etc/init.d/umountfs:

20,40c20
< # List all mounts, deepest mount point first
< LANG=C sort -r -k 2 /etc/mtab |
< (
< DIRS=""
< while read DEV DIR TYPE REST ; do
< if [ "x$TYPE" == "xtmpfs"]; then
< DIRS="$DIRS $DIR" # Unmount tmpfs before turning off swap
< fi
< done
< umount -r -d $DIRS
< )
<
< # Make sure tmpfs file systems are umounted before turning off
< # swap, to avoid running out of memory if the tmpfs filesystems
< # use a lot of space.
< log_action_begin_msg "Deactivating swap"
< swapoff -a
< log_action_end_msg $?
<
< # Umount all filesystems now
---
> # Umount all filesystems except root and the virtual ones
63a44,50
>
> # Make sure tmpfs file systems are umounted before turning off
> # swap, to avoid running out of memory if the tmpfs filesystems
> # use a lot of space.
> log_action_begin_msg "Deactivating swap"
> swapoff -a
> log_action_end_msg $?

It firstly unmounts tmpfs, then deactivas swap and remaining
filesystems lastly. I'd like to hear if there are any reasons for not
applying this patch, if any.

Changed in sysvinit:
importance: Medium → Wishlist
status: Unconfirmed → Confirmed
Revision history for this message
Rolf Leggewie (r0lf) wrote :

Scott, why did you decrease the importance of this bug when it should really have been increased to at least critical? Everybody knows that uncleanly and unmounted partitions can lead to data loss (man e2fsck). I have had this happen in the past and was luckily saved by a backup.

PLEASE increase the importance of this bug and put a high prio on fixing this.

Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

We absolutely, unequivocably, do not support systems using swap files instead of swap partitions.

Therefore this is merely a wishlist for that to become supported.

Revision history for this message
tz (thomas-mich) wrote :

So by "not supporting" you mean you will purposely leave bombs which might destroy the filesystem?

Fine, disable swapfiles, or issue big ugly warnings that it will destroy your system if you activate one under ubuntu, but if you aren't going to do that, this should be a higher priority.

It isn't not obvious that creating a swapfile risks damaging your system, but that is what the condition is.

I have four bootable partitions (Win/DOS/Mac/Linux) and I can't create a 5th due to DOS limitations. So for me it is a swapfile or NO swap. I have plenty of memory so don't need to use one but it is nice for the exceptional case.

Revision history for this message
Rolf Leggewie (r0lf) wrote :

> We absolutely, unequivocably, do not support systems
> using swap files instead of swap partitions.

Who is we? Where is this documented? If indeed you do not support this, then the situation changes, but the priority remains the same. If this is unsupported, then do NOT support it properly by completely disabling this functionality. Either way, this is absolutely a critical bug, nothing else. Quoting from the classification used by Debian BTS (taken from reportbug)

1 critical makes unrelated software on the system (or the whole system) break, or causes
                  serious data loss, or introduces a security hole on systems where you install the
                  package.

This is a bug of the HIGHEST priority, there is absolutely nothing that you can argue that away with.

Revision history for this message
Rolf Leggewie (r0lf) wrote :

quoting from the original report.

> I'd like to hear if there are any reasons for not
> applying this patch, if any.

I would like to hear about that, too.

Scott, please deal with the seriousness of this issue properly by either applying the patch or bringing forth arguments why it is broken. Just saying "We don't give a f*** about your data" is a disgrace.

Revision history for this message
tz (thomas-mich) wrote :

For me, you can either apply the patch or do something similar.

There is a larger problem here and this would be a THIRD proposed fix (the first two are 1. a patch, or 2. something that would disable or warn on creating a swapfile in the first place)

Filesystems that refuse to umount - for any reason - should abort the shutdown or go into single-user mode. Individuals would then have an indication or could take action manually to fix things - once for the instance, then to go out and find the patch if it is systemic.

In this case, you have something known to cause a condition which can result in data loss which is serious.

Secondly, to be robust, swapoff and umount -a could be done repeatedly until nothing happened on both (followed up by mount ... -o ro for anything left). Or umount needs a "swapoff to" option.

Consider the case of a loopback disk image on an external USB drive. That might also stick.

I can come up with scripts or utilities that would accomplish this (basically the above patch extended to the general case plus a shutdown interruption if I can manage it).

I'm only going to write them if they would actually make it into the distribution. I know enough to fix my own system but I'm not going to bother coming up with a very clean and well tested solution for one or two computers while everyone else loses data.

Revision history for this message
Rolf Leggewie (r0lf) wrote :

According to https://wiki.ubuntu.com/Bugs/Importance this is a bug of High importance, nothing less. It has a severe impact on a small portion of users.

Really, fix it or disable it.

Revision history for this message
Rolf Leggewie (r0lf) wrote :

Just wanted to point out that debbug 328582 that was recently added has been fixed about a year ago and indeed I never encountered this problem while running Debian.

So, it seems this should be not too hard to fix. There is a patch here in the BTS and Debian can do it so we can use them as reference.

Changed in sysvinit:
status: Unknown → Fix Released
Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

<Laibsch> Keybuk: May I kindly request you upgrade https://bugs.launchpad.net/distros/ubuntu/+source/sysvinit/+bug/48517 from Wishlist to High Importance?
<Keybuk> Laibsch: no; as mentioned in that bug, we've never supported swap on files
<Laibsch> Keybuk: As mentioned in the replies, please read https://wiki.ubuntu.com/Bugs/Importance
<Laibsch> This cannot be anything but High.
<Laibsch> The fix you choose is up to you. But I cannot see there is any doubt about the importance of this one.
* Hobbsee notes that the importance doesnt really matter - it's whether it gets fixed or not
<Keybuk> Laibsch: of course it can
<Keybuk> it's wishlist
<Keybuk> we have never supported this configuration
<Keybuk> we provide no tools to put your system into this configuration
<Laibsch> Keybuk: Also, what about the patch that is supplied? No good?
<Keybuk> this configuration has never worked (unless by accident)
<Keybuk> it certainly does not work in dapper
<Keybuk> therefore this is not a regression either
<Laibsch> Keybuk: nano is not supported?
<Keybuk> Laibsch: you can nano /dev/hda1 and write garbage -- that doesn't mean we should support you when you can't mount your filesystem
<cjwatson> Laibsch: for future reference, patches should be submitted as unified diffs (diff -u)
<Keybuk> from the page you quote ...
<Keybuk> Wishlist: a request to add a new feature to one of the programs in Ubuntu
<cjwatson> the normal diff format is practically useless
<Keybuk> "new feature" => supporting swap files (instead of partitions)
<Laibsch> cjwatson: I would change the patch if I knew how. I had trouble applying it myself.
<Keybuk> please don't get too religious about the importance of a bug
<Keybuk> the importance is a guide for the developer, rather than the user
<Keybuk> it doesn't actually mean your bug is getting any less consideration
<Keybuk> in fact, for feisty I'm attempting to fix more wishlist bugs than critical ones (yes, that sounds weird)
<Laibsch> Well, this one is easy to fix. A user has said he would work in it to fix it. Still it has been sitting around for ages. (and it is important IMNSHO ;-))
* rob (i=RobertSt@freenode/staff/rob) has joined #ubuntu-devel
<Laibsch> on it
<Keybuk> Laibsch: how easy a bug is to fix, or how long it has been open, have no bearing on things
<mjg59> Laibsch: This bug isn't the only thing blocking swapfile support
<mjg59> Using swapfiles currently breaks hibernate
<cjwatson> Laibsch: given that most of our initscripts are going to be thrown away and totally redone from scratch in an entirely different way in feisty ...
<Laibsch> Keybuk: Why not accept the input from the user who said he would help out?
<Keybuk> you'll note that release goals for the last three ubuntu releases have included major changes to the startup and shutdown sequences, as well as the method of mounting filesystems
<Keybuk> this is, as a whole, something that is being worked on (tm)
<Keybuk> Laibsch: because as Colin points out, we've pretty much throwing away all the init scripts for feisty -- spending time now to try and fix that in the current initscripts system would reduce the amount of time to write the new stuff

Revision history for this message
Rolf Leggewie (r0lf) wrote :

It is a disgrace that ubuntu devs hold such a low esteem of their users' and their data. Especially, when a fix is readily available and all you hear is "it is being worked on" over a year ago.

Abyssmal is all I can say.

Revision history for this message
Rolf Leggewie (r0lf) wrote :

bump!

Revision history for this message
tz (thomas-mich) wrote :

In intrepid, /etc/init.d/umountfs will unmount tmpfs, then swap, then local filesystems, so I assume it is fixed, albeit in a major refactoring.

I haven't verified loop devices or other things that might gridlock a umount so it may still have that variant of the bug.

It does attempt to remount read-only and release loop devices given the options.

umount itself has a "lazy" option but that is not used in the script (but would resolve the problem, e.g. if /dev/sdb1 has a loopback mounted, it will be detached and marked, and when umount gets to the loopback and unmounts it, /dev/sdb1 will follow automatically. In the umount manpage it mentions the case of umount opening libc and specifically suggests the lazy umount (kernels 2.4.11 or later, but that should include most).

The lazy umount option if added should take care of any swapfile problem (i.e. when the swapfile is turned off, the pending umount will complete), though as I've noted it appears solved.

One other method if possible, it should umount in the reverse order of mounting (since a drive would need to be mounted before the fsimage file could be loopbacked) and I'm not sure if the scriptography employed in getting the list of mounts in umountfs does this.

another is simply to repeat the umount until nothing changes.

Revision history for this message
Rolf Leggewie (r0lf) wrote :

This has been fixed a long time ago in version 2.86.ds1-11 in Debian.

Changed in sysvinit (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.