NSLU2-Linux
view · edit · print · history

HowTo.FixSlowBootup History

Hide minor edits - Show changes to markup

January 30, 2009, at 04:44 PM by Lurch -- Added success report
Added lines 24-26:

Great, these changes were enough to fix my slow bootup! :) - Lurch


October 09, 2008, at 10:44 PM by arthur92710 --
Changed lines 18-19 from:
to:
 chmod 755 /unslung/rc.quota
August 01, 2008, at 04:00 AM by LJR --
Changed lines 56-57 from:

About eight times out of ten my SLUG was taking over five minutes to boot. I attached a monitor to the serial port and discovered that the delay occurs when /sbin/rc.bootbin hangs for four minutes and 27 seconds. You can see this by waiting for the 'setting CGI_ds.conf' message and running ps while the boot process hangs there.

to:

About eight times out of ten my SLUG was taking over five minutes to boot. I attached a monitor to the serial port and discovered that the delay occurs when /sbin/rc.bootbin hangs for four minutes and 27 seconds. You can see this by waiting for the 'Starting CGI_ds.conf' message and running ps while the boot process hangs there.

August 01, 2008, at 04:00 AM by LJR --
Changed lines 56-57 from:

About eight times out of ten my SLUG was taking over five minutes to boot. I attached a monitor to the serial port and discovered that the delay occurs when /sbin/rc.bootbin hangs for four minutes and 27 seconds. You can see this by waiting for the 'setting CGIds?.conf' message and running ps while the boot process hangs there.

to:

About eight times out of ten my SLUG was taking over five minutes to boot. I attached a monitor to the serial port and discovered that the delay occurs when /sbin/rc.bootbin hangs for four minutes and 27 seconds. You can see this by waiting for the 'setting CGI_ds.conf' message and running ps while the boot process hangs there.

July 30, 2008, at 02:53 AM by LJR --
Changed lines 56-57 from:

About eight times out of ten my SLUG was taking over five minutes to boot. I attached a monitor to the serial port and discovered that the delay occurs when /sbin/rc.bootbin hangs for four minutes and 27 seconds. You can see this by waiting for the "setting CGIds?.conf" message and running ps while the boot process hangs there.

to:

About eight times out of ten my SLUG was taking over five minutes to boot. I attached a monitor to the serial port and discovered that the delay occurs when /sbin/rc.bootbin hangs for four minutes and 27 seconds. You can see this by waiting for the 'setting CGIds?.conf' message and running ps while the boot process hangs there.

July 29, 2008, at 11:03 PM by LJR --
Changed lines 56-59 from:

About eight times out of ten my SLUG was taking over five minutes to boot. I attached a monitor to the serial port and discovered that the delay occurs when /sbin/rc.bootbin hangs for four minutes and 27 seconds. You can see this by waiting for the "setting CGIds?.conf" message and running ps while the boot process is hung. There's plenty of time.

A utility called strace is available from the optware library. It can attach to a running process and provide a view of any system calls that process is making.

to:

About eight times out of ten my SLUG was taking over five minutes to boot. I attached a monitor to the serial port and discovered that the delay occurs when /sbin/rc.bootbin hangs for four minutes and 27 seconds. You can see this by waiting for the "setting CGIds?.conf" message and running ps while the boot process hangs there.

A utility called strace is available from the optware library. It can attach to a running process and provide a view of any system calls that the attached process is making.

Added lines 62-63:

strace -p <pid> where <pid> is found from running ps while hung in the loop.

Changed line 82 from:
to:

If I were more curious I would pepper the boot process with lines checking for the existence of /tmp/log.lck to find out who's the bad boy. But it seems most likely that whoever set the lock is long gone by the time rc.bootbin runs.

July 29, 2008, at 10:57 PM by LJR --
Changed line 69 from:
  1. !sh
to:
  1. !/bin/sh
July 29, 2008, at 10:56 PM by LJR --
Changed lines 62-63 from:

By creating a /unslung/rc.bootbin and putting in a line to rm /tmp/log.lck, the file is deleted before rc.bootbin is invoked and the delay is reliably gone.

to:

By creating /unslung/rc.bootbin with a line to rm /tmp/log.lck, the file is deleted before rc.bootbin is invoked and the delay is reliably gone.

/unslung/rc.bootbin

July 29, 2008, at 10:55 PM by LJR --
Deleted lines 63-66:

I haven't had to do anything like what the contributor above describes and after twenty boots I'm confident this file removal technique fixes my problem. Removing a log lock file from a tmp directory is safe because no one else should be writing to the log file at this point in the boot process. If anything bad comes of this fix I'll post additional information.

It's very easy to see if /sbin/rc.bootbin is causing the problem if you have access to the serial line and can monitor the boot.

Added lines 73-78:

I haven't had to do anything like what the contributor above describes and after twenty boots I'm confident this file removal technique fixes my problem. Removing a log lock file from a tmp directory is safe because no one else should be writing to the log file at this point in the boot process. If anything bad comes of this fix I'll post additional information.

It's very easy to see if /sbin/rc.bootbin is causing the problem if you have access to the serial line and can monitor the boot.

July 29, 2008, at 10:54 PM by LJR --
Added lines 68-76:

(:table border=0 width=100% bgcolor=#eeeeff:) (:cell:)

 
#!sh
# delete lock file that hangs rc.bootbin
rm /tmp/log.lck
return 1

(:tableend:)

July 29, 2008, at 10:52 PM by LJR --
Changed lines 62-65 from:

By creating a /unslung/rc.bootbin and putting in a line to rm /tmp/log.chk, the file is deleted before rc.bootbin is invoked and the delay is reliably gone.

I haven't had to do anything like what the contributor above describes and after twenty boots I'm confident it fixes the problem. Removing a log lock file from a tmp directory is safe because no one else should be writing to the log file at this point in the boot process. If anything bad comes of this fix I'll post additional information.

to:

By creating a /unslung/rc.bootbin and putting in a line to rm /tmp/log.lck, the file is deleted before rc.bootbin is invoked and the delay is reliably gone.

I haven't had to do anything like what the contributor above describes and after twenty boots I'm confident this file removal technique fixes my problem. Removing a log lock file from a tmp directory is safe because no one else should be writing to the log file at this point in the boot process. If anything bad comes of this fix I'll post additional information.

It's very easy to see if /sbin/rc.bootbin is causing the problem if you have access to the serial line and can monitor the boot.

July 29, 2008, at 10:49 PM by LJR -- Slow boot caused by rc.bootbin waiting for log.chk to go away
Added lines 52-65:

[LJR 20080729]

About eight times out of ten my SLUG was taking over five minutes to boot. I attached a monitor to the serial port and discovered that the delay occurs when /sbin/rc.bootbin hangs for four minutes and 27 seconds. You can see this by waiting for the "setting CGIds?.conf" message and running ps while the boot process is hung. There's plenty of time.

A utility called strace is available from the optware library. It can attach to a running process and provide a view of any system calls that process is making.

I installed and attached strace to rc.bootbin via its process id and discovered that it is spinning in a loop waiting for a file named /tmp/log.lck to disappear. Apparently some prior part of the boot creates this file and doesn't always delete it when finished. Occasionally it does delete the file and that explains why the SLUG doesn't always hang up.

By creating a /unslung/rc.bootbin and putting in a line to rm /tmp/log.chk, the file is deleted before rc.bootbin is invoked and the delay is reliably gone.

I haven't had to do anything like what the contributor above describes and after twenty boots I'm confident it fixes the problem. Removing a log lock file from a tmp directory is safe because no one else should be writing to the log file at this point in the boot process. If anything bad comes of this fix I'll post additional information.

November 19, 2006, at 05:03 PM by Armin --
Changed lines 19-20 from:

4. try a reboot an hopefully enjoy!

to:

4. try a reboot and hopefully enjoy!

November 19, 2006, at 05:03 PM by Armin --
Changed lines 48-49 from:

This remounts al partitions on /dev/sda with the noatime-option.

to:

This remounts all partitions on /dev/sda with the noatime-option.

November 19, 2006, at 05:02 PM by Armin -- Final solution found (for my problem)
Added lines 20-51:

Aparently, the solution above didn't solve my problem completely. There was a quick boot and then a couple of slow boots. Could not determine any logic behind it!

Today, I experimented a little bit on HDD spindown and added the following script ( originally found in SetSpinDownTimeOnMaxtorOneTouch, slightly changed) to /unslung/rc.local:

(:table border=0 width=100% bgcolor=#eeeeff:) (:cell:)

 
#!/bin/sh
# /unslung/rc.local
# A diversion script to remount the drive(s) without access
# times being recorded (the update of access times can
# prevent drives sleeping)

# Usually it is enough just to do /sda1 as this is the usually
# the one that holds the system.
/bin/echo "Remounting /dev/sda1 with noatime"
/bin/mount -o remount,rw,noatime /dev/sda1
/bin/echo  "Remounting /dev/sda2 with noatime"
/bin/mount -o remount,rw,noatime /dev/sda2

return 1
# EOF - include this line

(:tableend:)

This remounts al partitions on /dev/sda with the noatime-option.

Since I have this script running, there are no slow-boots anymore! Don't know why, but anyway - who cares, when it works!

November 17, 2006, at 02:45 PM by Armin --
Changed lines 6-9 from:

This might be caused by calculating quota during startup!

Just put a diversion-script called rc.quota in /unslung containing the following:

to:

Apart from an ext3- filesystem-check, this might be also caused by calculating quota during startup.

1. Remove all quota in the web-interface.

2. Put a diversion-script called rc.quota in /unslung containing the following:

Changed lines 17-19 from:

chmod the file to 755, try a reboot an enjoy!

to:

3. chmod the file to 755

4. try a reboot an hopefully enjoy!

November 17, 2006, at 02:30 PM by Armin --
Changed lines 3-7 from:

It might happen, that booting up the slug takes very long and you think youre slug will never come up. Then, after 4 to 7 Minutes, suddenly HD-activity comes back and finally, the system is up.

This might come from calculating quota durinig startup!

to:

It might happen that booting up the slug takes very long and you think your slug will never come up again anymore. Then, after 4 to 7 Minutes or so, suddenly HD-activity comes back and finally, the system is up again.

This might be caused by calculating quota during startup!

November 17, 2006, at 02:29 PM by Armin --
Added lines 1-15:

Problem with very slow Bootup

It might happen, that booting up the slug takes very long and you think youre slug will never come up. Then, after 4 to 7 Minutes, suddenly HD-activity comes back and finally, the system is up.

This might come from calculating quota durinig startup!

Just put a diversion-script called rc.quota in /unslung containing the following:

#!/bin/sh
exit 0

chmod the file to 755, try a reboot an enjoy!

view · edit · print · history · Last edited by Lurch.
Based on work by arthur92710, LJR, and Armin.
Originally by Armin.
Page last modified on January 30, 2009, at 04:44 PM