"Activating swapfile swap" takes a very long time during boot

[Ramon Casha]

Since upgrading Intrepid to Jaunty, the boot process is taking a very long time with lots of disk-grinding between the message saying "Activating swapfile swap" and "Starting AppArmor".

[Ramon Casha (rcasha)]

I traced this to S36mountall-bootclean.sh.

[laucode (laucode)]

I have the same problem.

the "Activating swapfile swap" takes a long time in the boot and then start "normally".

This does not occur since the installation. maybe some update has caused the bug.

[Ramon Casha (rcasha)]

I found out that the bootclean shell script was taking a very long time trying to search for files to delete in the /tmp directory. I solved it by deleting everything in the /tmp directory.

[Jay I. (jay-27182818)]

i confirm this bug. ubuntu jaunty amd 64, uname -r: 2.6.28-13-generic. the bug first appeared two days earlier with the previous kernel. one strange thing that i noticed is this:

right before "Activating swapfile swap" there are a couple of messages about filesystem checks. for my /dev/sda1 there's a message telling how many files are located on the disk, how many blocks are used etc. when the number of files is say N the boot process hangs for half an hour or so. after that i can boot several times with the message saying that there are approx. N/2 files and a 2 minutes hang. then once again i get number of files close to N and half-an-hour hang.

another strange thing: gparted shows that /dev/sda5 (swap) is not activated though it's mentioned in /etc/fstab

$ fdisk -l

Disk /dev/sda: 250.0 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0xcbf9cbf9

   Device Boot Start End Blocks Id System
/dev/sda1 * 1 29675 238364406 83 Linux
/dev/sda2 29676 30401 5831595 5 Extended
/dev/sda5 29676 30401 5831563+ 82 Linux swap / Solaris

my /etc/fstab:

# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
# /dev/sda1
UUID=c9eeccaa-fdf8-4e85-b219-82602022713c / ext3 relatime,errors=remount-ro 0 1
# /dev/sda5
UUID=51646e20-d689-4218-bc71-7d5a31a9cab1 none swap sw 0 0
/dev/scd0 /media/cdrom0 udf,iso9660 user,noauto,exec,utf8 0 0

this bug can be a duplicate of https://bugs.launchpad.net/ubuntu/+source/linux/+bug/219349

[antoniosanct (antoniosanct)]

I confirm this bug in Ubuntu Jaunty, kernel 2.6.28-15-generic x86_64

The issue changes position renaming S36mountall-bootclean.sh. Attach both cases.
Attach 1) with S36mountall-bootclean.sh, the last message is "Activating swapfile swap ... [OK]"
Attach 2) with K36mountall-bootclean.sh, the last message is "Activating network interfaces ... [OK]"

- Force cleaning /tmp doesn't fix the problem
- It's not a hard disk problem, because my HDD is new and only have ext4 partitions
- I would choose only 3 reasons to force the issue: VirtualBox (2.2.4 r47978), AppArmor or Kernel 2.6.28

[Soltész András (soltesz-andras)]

I also have this bug (initrd.img-2.6.28-15-generic), the disk-grinding takes about 90 seconds.

I also tried to clean /tmp but id didn't help.
I also have VirtualBox installed.

Some nice update caused it because my boot used to be very fast after the original install.

[Soltész András (soltesz-andras)]

I placed debug messages into the init scripts and it seems that the /lib/init/bootclean.sh script does something very slow.

More precisely the line "rm -f .X*-lock" in the "clean_tmp()" method.

[Soltész András (soltesz-andras)]

I have an ".X0-lock" file which seems to contain only the PID of the X server. This is a very small file.

Why would be slow to delete this?

Could be that this is an ext4 filesystem problem? Does anyone here has this problem on ext3 or ext2 (/tmp being on this kind of filesystem) ?

[Soltész András (soltesz-andras)]

If I comment-out the "rm -f .X*-lock" line, then the script will stop on this statement for a long time:

 find . -depth -xdev $TEXPR $EXCEPT ! -type d \
  -print0 | xargs -0r rm -f -- \
  || { report_err ; return 1 ; }

This also contains an "rm" command so it is possible that the first "rm" command on the /tmp filesystem takes a very long time.

[Ramon Casha (rcasha)]

I tried clearing the tmp directory - it was the find command that was taking
a long time I think, not the deletes.

Ramon Casha

2009/8/22 Soltész András <email address hidden>

> If I comment-out the "rm -f .X*-lock" line, then the script will stop on
> this statement for a long time:
>
> find . -depth -xdev $TEXPR $EXCEPT ! -type d \
> -print0 | xargs -0r rm -f -- \
> || { report_err ; return 1 ; }
>
> This also contains an "rm" command so it is possible that the first "rm"
> command on the /tmp filesystem takes a very long time.
>
> --
> "Activating swapfile swap" takes a very long time during boot
> https://bugs.launchpad.net/bugs/369291
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Soltész András (soltesz-andras)]

Clearing the /tmp folder doesn't help on my system. If I restart immediately after the clearing, I get the same slow boot with the disk-grinding.

[Soltész András (soltesz-andras)]

@Ramon
Are you running your /tmp folder on an ext4 filesystem?

[Ramon Casha (rcasha)]

No, ext3

[James Smith (james-floppy)]

Confirmed on Jaunty, Dell Inspiron 6400 laptop. BUT I have had this problem since Intrepid came out - only just managed to find time to work out what it was.

uname -a: Linux marvin 2.6.28-15-generic #49-Ubuntu SMP Tue Aug 18 18:40:08 UTC 2009 i686 GNU/Linux

Traced slowness to cleaning of /tmp in S36mountall-bootclean by adding some echo commands in the /lib/init/bootclean.sh script. This is the slow line:

[ -d /tmp ] && ! [ -f /tmp/.clean ] && { clean_tmp || ES=1 ; }

Likewise cleaning /tmp doesn't help for me, bootup still very slow. /tmp is on an ext3 filesystem (/).

Not sure yet which line inside clean_tmp is the slow one, but bootchart shows a "sh" process taking an extremely long time, just before a "find" and an "xargs". Will try to narrow it down further later on.

[James Smith (james-floppy)]

The delay in my bootchart looks exactly like comment #6 above.

[antoniosanct (antoniosanct)]

There is a possible solution to fix hang boot, but I don't know what is the origin. In my case, I checked ls -lai /tmp and cost about 2 min to display the file tree. Previously, I checked ls -lai / and /tmp/. was a huge size (about 4G).

My solution, remove totally /tmp and create new one. However, the automatic create of /tmp at boot doesn't work, it's better create manually:

$ sudo su -
$ rm -rf /tmp
$ mkdir /tmp
$ chmod 777 /tmp
$ chmod +t /tmp
$ reboot

Then, the next boot time with all processes active (sh, apparmor, mysql, etc) was 17 secs löl

It's possible that some update creates a huge file in /tmp and all sh processes from rcS.d want to clean the directory using find and xargs. Obviously, this is a ugly solution that doesn't remove the issue.

Regards!

[James Smith (james-floppy)]

In my case, "ls -lai /tmp" returns immediately once the machine is booted, and the total size of /tmp is about 32k, so a large /tmp isn't the cause. I will try recreating the directory, see if that makes any difference.

[James Smith (james-floppy)]

I can confirm that on my system, the slow line is 'rm -f .X*-lock' in clean_tmp in /lib/init/bootclean.sh, as for comment #8 above.

[Soltész András (soltesz-andras)]

Please use the "This bug affects me too" switch on the top of the page if it affects you.

Maybe it will make this bug more important for Canonical.

[A.K.Karthikeyan (mindaslab)]

For me some thing strange thing happened, I switched on my computer, it did
stop at activating swap file swap. I left it over night, by morning I had
got the username prompt, I entered the details and logged in. From that day
on, when I start my computer it hangs for only 3 minutes in activating swap
file swap! ;) Try it out!

2009/9/3 Soltész András <email address hidden>

> Please use the "This bug affects me too" switch on the top of the page
> if it affects you.
>
> Maybe it will make this bug more important for Canonical.
>
> --
> "Activating swapfile swap" takes a very long time during boot
> https://bugs.launchpad.net/bugs/369291
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

[Eivar Montenegro (e.mont01)]

I can confirm that the solution for comment #17 above works fine.

Greetings

[Soltész András (soltesz-andras)]

#17 solved it for me too (on Jaunty).

Since then I upgraded my system to Karmic and the problem hasn't resurfaced yet.

[Victor Vargas (kamus)]

could you check (if is possible) in latest version of Ubuntu Karmic if this issue is still happening? Thanks in advance.

[Ramon Casha (rcasha)]

This bug did not occur on a regular/repeatable basis. I found that it was caused by an accumulation of files in /tmp, which caused the find command to take a long time. I haven't had that accumulation of files since then.

[A.K.Karthikeyan (mindaslab)]

LinkedIn
------------

Bug,

I'd like to add you to my professional network on LinkedIn.

- Karthikeyan

Karthikeyan A K
Information Technology Consultant at Webtoday Business Solutions Pvt Ltd
Chennai Area, India

Confirm that you know Karthikeyan A K:
https://www.linkedin.com/e/-ukxx1w-h21vdk7o-2u/isd/7046353501/r0f1pZaY/?hs=false&tok=2QhThlRiLVXlc1

--
You are receiving Invitation to Connect emails. Click to unsubscribe:
http://www.linkedin.com/e/-ukxx1w-h21vdk7o-2u/qwddmaxrrP97l3p28fpqk5lrDYe2XGqL-V1N0tf/goo/369291%40bugs%2Elaunchpad%2Enet/20061/I2409683209_1/?hs=false&tok=1QNfhBmL3VXlc1

(c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.

[A.K.Karthikeyan (mindaslab)]

LinkedIn
------------

Bug,

I'd like to add you to my professional network on LinkedIn.

- Karthikeyan

Karthikeyan A K
Information Technology Consultant at Webtoday Business Solutions Pvt Ltd
Chennai Area, India

Confirm that you know Karthikeyan A K:
https://www.linkedin.com/e/-ukxx1w-h21vt3hq-71/isd/7046353501/r0f1pZaY/?hs=false&tok=3n1Hu3ulU5XBc1

--
You are receiving Invitation to Connect emails. Click to unsubscribe:
http://www.linkedin.com/e/-ukxx1w-h21vt3hq-71/qwddmaxrrP97l3p28fpqk5lrDYe2XGqL-V1N0tf/goo/369291%40bugs%2Elaunchpad%2Enet/20061/I2409740065_1/?hs=false&tok=2LRYyUpXc5XBc1

(c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.

[penalvch (penalvch)]

Ramon Casha, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available (not the daily folder, but the one at the top) following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.13-rc4

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

[Launchpad Janitor (janitor)]

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

[Christopher (soft-kristal)]

I'm not complaining about a 37 second boot time, but I am curious why most of it is these two lines:

[ 8.302274] EXT4-fs (sda9): mounted filesystem with ordered data mode. Opts: (null)
[ 26.934248] Adding 8853500k swap on /dev/sda7. Priority:-1 extents:1 across:8853500k FS

[penalvch (penalvch)]

Christopher (soft-kristal), thank you for your comment. So your hardware and problem may be tracked, could you please file a new report with Ubuntu by executing the following in a terminal while booted into a Ubuntu repository kernel (not a mainline one) via:
ubuntu-bug linux

For more on this, please read the official Ubuntu documentation:
Ubuntu Bug Control and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue
Ubuntu Kernel Team: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports
Ubuntu Community: https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs