Slashdot Mirror
Booting Linux Faster
krony writes "IBM's DeveloperWorks explains how to decrease boot times for your Linux box. The concept is to load system services in parallel when possible. Most surprising to me is the use of 'make' to handle dependencies between services." The example system shown is able to cut its boot time in half, but the article stresses the effectiveness can vary widly from machine to machine.
"Who cares how long it takes to boot Linux? My uptime is 400 days!!!"
Yup.. just keep talking about that and wonder why Linux never becomes mainstream.
Like any Linux user is gonig to reset their uptime just to see if they can boot faster!
Height: 38U, Weight: 0 Newtons, Eyes: #0000FF, OS: Gray Matter 1.0 (Alpha)
you insensitive clod!
You can lead a horse to water, but you can't make it dissolve.
Anyone ever wonder how we got ourselves into a situation where we spend so much time saving ourselves time?
Most surprising to me is the use of 'make' to handle dependencies between services."
Really? That's an odd statement. How surprising that they choose to use an open-source software application that is designed to compactly represent dependencies for representing dependencies.
Perhaps they should have drawn Visio diagrams instead!?
John.
I did that on an old slow laptop, and it cut the boot time quite a bit. There is plenty of stuff that you might not need to run like kudzu, lpd, portmap, sendmail, sshd, or clock syncing stuff.
Personally, I dont give a shit about how long my linux machines take to boot up, because they dont go off once they're up.
.
someone has a use for this
You bet.
How long are you willing to wait for your stereo receiver to boot up, your TV, or your TiVo?
This is a really important issue for embedded devices like consumer electronics built on Linux.
"Provided by the management for your protection."
If Douglas Adams is so damn smart, why is he dead?
Serel does this too, for RedHat and Debian. It actually works; it's not just a proof-of-concept, although it does have a number of bugs.
> I rarely have to boot ever after the first boot and patch!
Probably true. But one goal of linux is to become the predominant desktop/laptop OS.
I work for a public school system. I'd rather not have all these computers eating up power all night when they're not being used.
In most work environments, pc's get turned off over night, and sometimes even at lunch.
This is one more way someone is helping to make Linux a better candidate for your casual end user.
I see there are already a ton of linux fanboys and girls posting about the incredible uptime of their linux boxes, and claiming that a) boot time doesn't matter because linux doesn't go down or b) linux boots very fast.
They are wrong. Boot time matters.
It matters for perception. Boot time is one of the periods where a user spends the most time looking at a screen not being able to do anything (even if that happens rarely). A faster boot time leads to a sense that the whole system is faster, because it is a first impression, and a significant impression. If linux bliped on from a cold start in 5 seconds, I'd be studies would show it appeared faster.
Boot time matters because not everyone (in fact, very few people) leave their systems on all the time. Slashdot fan boys living at home may not agree, but they are wrong.
Think about business systems. At my place of work, everyone turns their computer off at the end of the day, and on at the beginning of the next. My mother doesn't leave her computer running 24/7, she turns it OFF when she is done using it. My roomates do the same thing. Even I do it sometimes.
Boot time matters because power management is still evolving under linux. As power management requires the cooperation of a number of pieces of a system, power management is still a work in progress. Once power management with every peripheral is flawless, then we can start to dial back boot time worries (only a little).
Boot time matters server side too. I know folks are going to complain that I focus on the user too much. But boot time matters server side as well. We have UPS units on our servers. They have however a limited lifetime. So when the power drops for a few minutes (which it does here somewhat often) automatic shutdown process starts.
When the power comes back on, people power up their computers. These being Windows XP machines they actually start pretty quickly (or never went off if on a UPS). If folks were in the middle of something, they expect that with the power their logon and other services will be back in action. Then all the individual computers start timing out / locking up, generating help calls.
On the server side, if there was an emergency security patch, or we were coming up from a power outage, the faster the boot time the better, if I can beat out even 20% of the client connect attempts.
Boot time matters, a big bravo to the folks working to improve this.
I'm afraid that if you have a laptop, boot time is quite important. Doing suspend/resume with X running is not reliable. While I certainly agree that fixing this is the long term solution, a quicker boot-up is a reasonable fix in the meanwhile
The Raven
As someone who uses linux on a laptop, running SuSE 8.2 I *DEFINITELY* have a use for this. I use my laptop in a professional capacity to do quite a lot of things, and while I can run on batteries I do generally turn it off and on at least a couple times a day. Further - because I am occasionally forced to dual boot, sometimes that can be even more often. It is a good 3-4 minutes between power on and KDE desktop. This is on an 800mhz P3 with 512 megs of RAM.
Do I want a faster boot?
You bet your ass I do.
Since you have to work out the dependices yourself, why not imbed the dependices in the startup scripts themselves? So for example, the nfs startup script would block until the network script got started. The status can be checked by parsing /etc/rc.d/init.d/network status. You may want a timeout on the blocking. If you do this you could just start all the scripts at once.
This was three years or more ago, but I remember one of the PPC Linux developers "converted" all his system boot scripts in init.d to compiled C.
.no "glory". Fixing this would be like someone fixing fdisk... no one wants to touch the damn stuff...
Boot times went from about 2 minutes, to 35 seconds.
(It took "so long" because it was an old PPC 601 60MHz or something like that).
Distributions such as Mandrake and Gentoo claim they go the extra mile for "performance". I've wondered why neither has cleaned up their boot process.
You wouldn't think Bash is slow from interactive use, but it really it. Piggyback on that speed problem that too many "functions" (OK, *commands*) are standalone executables... greate sub-process, collect result, destroy, rinse repeat.
This is pretty interesting stuff, and I applaud this guys efforts. INIT script achitecture is pretty thankless stuff..
I think this will be useful only for desktops actually. Embedded devices do not usually run as many services as desktops. And the embedded Linux implementations seem to boot plenty fast as it is.
For example, my Linksys WAP boots up in about 10 seconds.
For a better embedded example, look at a Compaq iPAQ H3650 circa 3 years ago running Familiar Linux with the Opie desktop. It boots up in about 8 seconds. Then it's "instant" on/off unless you hard reset the device. It's also running more services than the default install.
Bah. Mac OS X's done this since Jaguar.
s /sanchez/sanchez_html/). Then SystemStarter makes a dependency graph and starts them up in parallel whenever possible (http://developer.apple.com/documentation/MacOSX/C onceptual/SystemOverview/BootingLogin/chapter_4_se ction_2.html).
The big question is "how do you specify dependencies?" The article uses makefiles. In Mac OS X, each startup item has a properties file (associative array) that names the item and specifies all the items that it depends on (http://www.usenix.org/events/bsdcon02/full_paper
I'm surprised someone hasn't pointed this out already. NetBSD's rc.d.has had support for dependencies for sometime.. html
http://www.netbsd.org/guide/en/chap-rc
Additionally, there's an article here. http://www.daemonnews.org/200108/rcdsystem.html
I've got a dual Athlon 2000+. The boot time improvement is next to inexistent. Overall it boots slower, due to the initial delay (about half a minute) to initialize ECC RAM, and the second or two Linux needs to initialize SMP.
Now, it's definitely a really big improvement over a 1 CPU system.
It's really smooth, and I can:
Burn CDs at 24x and play Quake 3
Compile programs using both CPUs and play videos at the same time.
Kill high priority programs (like sound daemons) that went mad for some reason and got into an infinite loop. This happened me with KDE a few months ago. With 1 CPU my computer froze for minutes until it could react to my request to kill the daemon. With SMP, no problem, I still have an idle CPU.
It's really nice for Gentoo. KDE compiles in several hours, and my computer isn't slowed down noticeably by the compilation. The basic Gentoo installation is done in a day, I can get all the necessary programs compiled during the second day.
The hardware is really stable too. Never locks up, never crashes. ECC RAM gives great peace of mind, too.
One of the things Apple did in Jaguar to speed up Mac OS X booting was to start services in parallel.
Apple uses a different startup script system (see the references below) than other UNIX flavors, but it's a really cool system. It uses dependency information rather than carefully-assigned integers to determine load order, so when they decided to add parallel service starting it was easy .. the dependency information was already there.
I'd love to see Linux or *BSD distributions adopt this system, as it's really cool to type SystemStarter start foo and have it automatically load all the dependencies for foo before starting foo itself. Plus adding services means just copying a directory into place .. no worrying about making links in /etc/rc?.d or getting the ordering right.
Relevant documentation:
-- Tim Buchheim
Remember to turn back the uptime when you sell your computer.
How small a thought it takes to fill a whole life
Pah. Mac OS X have done this since 10.2.
The large question is "how do you specify inter dependencies?" The article uses makefiles. In Mac OS X Jaguar, each startup item has a properties file (associative array, the indexes are strings) that lists the item and defines all the other parts that it depends on. Thereafter SystemStarter makes a dependency tree and starts them up in parallax whenever possible or when it feels like.
How small a thought it takes to fill a whole life
I have started a discussion on Debian Devel about this quite a long while ago.
:)
It sure is nice to see that my idea is being implemented...
However, as others mentioned there are quite a few problems with this approach.
One, is that it is very difficult to use make to perform the reverse (shutdown) using the same input data as the boot.
Another problem, one that I had no time to solve, and seems to not be addressed at all by the article, is that running services in parallel also logs things in parallel. Intermixed logs are quite unfriendly to read.
The plan a few of us at Debian Devel devised was a mini-text-window-manager for the output logs, but noone got around to implementing it.
Lastly, the most serious problem with this approach, was legacy support. Inserting this system into Debian, at least, required that all service package maintainers provide extra dependency information about their packages. This problem was the least feasible to solve.
Thus, my little project died then - and seems to now be revived by IBM
See www.fefe.de/minit/ for info about the project.
It's a tiny statically linked init that besides offering make-like dependencies to load services in parallel also offers ways to avoid spawning a thousand shell and utility processes in the boot process.
On my notebook, it takes less than a second from the start of init to a login prompt. In fact the latency is so small that I have never used the APM or ACPI suspend mode any more, I just turn the notebook off and on again. That's actually faster than the BIOS suspend-to-disk feature.
minit also has other benefits over standard init: you can ask init for the PID of services like sshd without PID files and thus even on read-only media like a CD-ROM without initial RAM disk or shmfs.
It's Linux only, though. And you need the diet libc for full effect (52k memory footprint for init on my desktop, including shared read-only pages).
My first linux Mandrake box, I went through and parallelized my rc directories. The trick was to have fake S** entries that spawn off what can be done in parallel.
:-P)
Albeit makefile based (done by hand), but I was getting my boot times down to 23 seconds on an aging Pentium MMX, with tons of unnecessary services. (I know better know,
Too bad there wasn't any way I could have done that to Windows 98. It was a DOG!
XP is much better, but it doesn't boot much faster than that fast on my new box even today.
Fuck Beta. Fuck Dice
Richard Gooch published an interesting implementation of parallel init scripts almost a year ago: http://www.atnf.csiro.au/people/rgooch/linux/boot- scripts
For the last N years, laptops have had a sleep/wakeup power-save feature. For the last N-2 years, it's generally worked well enough to be worth using all the time :-) Linux probably knows enough about power management for it to work on most laptops by now. Instead of shutting the machine down and rebooting it, you just close the lid and it saves its status and goes into some standby mode, and when you open the lid it wakes up again, where it left off, no need for reboot. On some machines, it also succeeds in doing this when the battery gets below X%.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Back in 1999 I rewrote all the init scripts entirely from scratch. I did this after having spent a few years before hacking at init scripts in BSD/OS, OpenBSD, Redhat, Slackware, and Solaris. I experienced all the crankiness of these systems (Redhat and Solaris were the worst) and this time decided to avoid all that. I gave the scripts entirely different names so as not to conflict with existing scripts (was Slackware at this time). That way I could switch between them with just a change of /etc/inittab. It took a few hours, but I had a running fully functional system by the end of the day, and have been running on those scripts, as subsequently better debugged and tweaked, ever since. They booted up noticeably faster than even the Slackware scripts (which were about as fast as the OpenBSD scripts).
Irontically, I didn't do this to get the boot speed. The init scripts are fast enough now that the kernel initialization time is longer, anyway. What I did this for was because I hated having a bunch of separate directories with symlinks in them for each run level. I didn't like having to use specialized tools to manipulate the system (I wanted to routinely use the tools I would have available if I were running from a rescue floppy trying to fix it). That meant doing things with a basic set of shell commands. Yet I didn't want to abandon having separate scripts for each service/daemon being started (or stopped as the case may be). What I ended up doing was creating a single subdirectory for all the individual service scripts, and making the script name have a pattern that included both the startup sequence (stop sequence simply ran backwards), as well as the run levels. Here's what the names in /etc/sys on my system look like:
Figuring out which run level each service starts in is left as an exercise for the reader. BTW, I think most of the speed comes from the fact that I didn't add a lot of fat to my script system. That's easier to do when you do your own design.
now we need to go OSS in diesel cars
I did it and noticed a decrease in the boot time, probably 15-20 sec. give or take. YMMV.
-- Two in the pink, one in the sink.