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.
Develop a better initialization sequence. Relying on a scripting language, such as bash, to initialize each system component slows down bootup time. Instead design a standard such that daemons can be stop/started/restarted with a standardized set of command line options.
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.
I had a conversation with my Dad about Linux start times yesterday that went something like:
Dad: But it takes so long to start up.
Me: Yeah, but you only have to do it once.
-Peter
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.
.
to reboot without rebooting, such that uptime remains the same but kernel upgrades can take place?
I remember reading about it somewhere, but it was skimpy on details, sufficing to say that it was a "bad idea".
You can't judge a book by the way it wears its hair.
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."
What definitely does take longer is starting all the system services. I know that an out-of-box RedHat installation starts an insane number of (mostly useless) services on startup. The first thing I always do when installing a RH box is run 'ntsysv' and disable all the crud.
The 'kudzu' utility is the worst offender. It checks the system for any new hardware or peripherals. There's no need for this to run on every single boot!
And BTW... Why are you rebooting a Linux box anyway? ;-)
Because it must be asked....
How much time is saved when booting up a beowulf cluster?
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.
9 second boot time from power-up to X-windows
Isn't this basically the same thing (different implementation though).
http://www.fastboot.org/
> 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.
You should be able to extract the word document using a zip utility.
It describes in quite a lot of detail how they reduced boot time in XP (not only starting stuff in parallel but also prefetching and other tricks).
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
What? You don't have a battery?
Geeze. How the Hell do you set the clocks in your house? Call time?
Big Brother Bush is doubleplus ungood.
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
Gentoo can do that too, just edit /etc/conf.d/rc:
RC_PARALLEL_STARTUP="yes"
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
And if you stick around long enough at DeveloperWorks, you'll make a grid out of those PCs and offer the district more compute power than they ever realized they had.
Intelligent Life on Earth
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
JIFFIES
This is an extremely simple patch for the 2.4 kernel. It creates a read/writable entry /proc/sys/kernel/jiffies, where you can get and set the current jiffies. To fake your systems uptime, write the required number of jiffies to this file :
# echo 100000 > /proc/sys/kernel/jiffies
Nice way to solve this problem. You really must have a refined sense of good taste, because only choosy mothers choose jiffies.
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
My best times were power on to init in about 2.7 seconds. By the time we got the "authentication code" and what not in it was closer to 30 seconds.
Take all that BIOS stuff out and create a truely lean and mean setup with minimal init scripts and you can blaze. Longest step was copying the kernel from slow-mo flash memory in to RAM...
> 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.
Gentoo has been working that way for years, and if Gentoo does it, there are certainly other distros that work that way as well.
-- B.
This sig does in fact not have the property it claims not to have.
Richard Gooch published an interesting implementation of parallel init scripts almost a year ago: http://www.atnf.csiro.au/people/rgooch/linux/boot- scripts
Kernel vulnerabilities are fairly rare. A new kernel is the only thing that mandates a complete system restart when upgraded. Linux and the BSDs got this right; it's the one overall thing I don't like about OS X. At most, OS X should only have to restart the GUI and close apps for most system patches....but nnnnooooo. Sheesh guys, you trumpet "the Power Of Unix"; use some of it.
The traditionaly Sys V init is archaic, crude, and disgusting. What, 6 hardcoded numeric runlevels? Wow, how useful is that. And I love ordering my startup scripts with two digit integers.
*nix needs a major boot/shutdown system upgrade. I have migrated to minit, but that is primarily for low memory usage. It allows a rudimentary mechanism for specifying dependencies, but is geared mostly to be minimalistic. This 2003, I think we can come up with something better than Sys V init.
Features of a next gen boot/shutdown service manager:
* uses real dependency traversal on startup and shutdown (maybe using a small theorem prover like CML2, or maybe something like make)
* allows configuration of arbitrary and unlimited sets of services, which can be named by arbitrary string literals - no longer chained to 7 numeric choices. e.g. "roaming laptop", "docked server", "minimal services", etc.
* built-in service start/stop/restart/status/enable/disable tools, and standard service API with bindings for various languages (what, native services? imagine that...we do so for Windows NT+, e.g. apache) as well as Plain Old Shell Scripts. So every freakin' flavor/distro of *nix doesn't have its own fscking way to start/stop/enable/disable services.
A lot of the garbage that goes on during startup (have you looked at the standard redhat scripts?) mounting drives and file systems, setting network and hardware parameters, etc., could probably use being standardized also, and either pulled into drivers or services or something, in a standardized fashion. Ideally all these APIs could be exposed both through command line tools, but also through desktop-integrated GUI tools, so that modifications don't entail digging up some ad hoc script on disk and modifying it and hoping you remember what the fuck you did a year ago in some system script.
It's 10 PM. Do you know if you're un-American?
rm it.
If you can stand it, add "noatime" to /etc/fstab
for your Linux partitions. You will always
have 'new mail' mail instead of just 'mail', but
if things are just reading from the drive, the
drive can actually spin down instead of having
to write just to say what it read.
Windows XP is probably the current technology leader in terms of reducing boot time. Oh yes, I can hear you scoffing loudly already, but it's true! NT loads drivers in parallel, let alone services, though NT is bad about allocating memory, so having more memory makes it boot a lot faster. Believe it or not, my XP boot time was cut in half when I went from 512MB to 1GB of memory.
XP also will defrag your disk automatically in such a way as to optimize boot. In other words, files accessed at every boot are placed together, so you don't have to do a lot of seeking at boot time. Now THAT is cool.
I was just bitching about how annoyed I am with the state of windows, what a pile of crap code it must be. Someone told me that windows was great because it hardly crashed these days, and I was pointing out that having to reboot it weekly or more often does not constitute stability. So it doesn't crash... It just gets flaky enough to where you reboot it voluntarily. Woop de doo. I know many people don't have this problem, but they're probably not doing much customization or running very many apps for the most part, or they like to shut down at night.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
as far as I know you don't have to reboot a linux machine to patch it. You can even reload a new kernel without patching it.
If you are talking about a module, maybe, but not a completely new kernel version. Many (if not most) of us are using RH 'official' kernels instead of building our own now. Since most of the non-essentials are modules anyway, they are actually pretty efficient kernels. I do build my own kernels on VERY specific application servers, but really its just so I remember how to. Since this article is about cutting boot times, its not really relevant to servers anyway.
Most of my servers spend more time POSTing than booting (Dell and IBM) so cutting the time in 1/2 that the init scripts loads will only save 10%-20% of the boot time. Not that important for a box I install a new kernel on, then schedule a reboot (not wise) or just get to work early and reboot first thing in the morning while the coffee brews. Not getting hits/traffic/use at 7am, and only have to do maybe twice a year, since not every kernel bug affects every server.
Tequila: It's not just for breakfast anymore!
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
Not trying to be a Gentoo evangelist, but a Gentoo rc script has specifiers for what a service depends on, so they can do away with static service level numbers.
The dependency calculation is regenerated and cached, so bootup is faster. Now if someone could take gentoo service script as input and build a parallel service starter -- that would be a nice project.
Btw, I have a Windows 2000 Server at work which I use for desktop use, and it takes *MUCH* longer to boot than a fully configured redhat 9 system. Why? Dunno, must be all the services and integrity checks that a "server" must have.
Windows XP on the other hand takes about 30 seconds to boot.
Kashif
Some people like to conserve energy when possible. Just do it! It's good for the environment!
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
.. and it isn't the quickest to reboot either! Mind you, I don't find I'm rebooting that frequently compared to my Windows machine.
You can't unmount a filesystem until all of the
processes that are using it are dead.
Those processes may have vital data to write out
before they exit, so shutdown gives them time
to do so.
Once all the processes that would usually be using
the filesystems are dead, the filesystems are
unmounted, and the system is halted.
-I like my women like I like my tea: green-
Ok, I agree that boot time is important in many specific cases. However, you say
/etc/rc3.d and find a whole bunch of services whose names you don't know, just remember that they might actually extend functionality beyond what you could get with another OS. If you ever truly do make your installation sleek and tiny, then give it another test and see what you find.
I see... fanbody and girls... claiming that... b) linux boots very fast. They are wrong.
This seems to be the prevailing wisdom here, so this is for everybody. I just have to disagree. A standard GNU/Linux distro (like Mandrake, for instance) will startup a buttload of services (depending on what you select at install time), and do far more than a standard Windows install (for instance). It will in fact run at startup every service that you've told it to install (again depending on if you tell it to, but I believe it will do this by default). Often this includes one or more databases (postgres, mysql), a web server (apache), perhaps a few file sharing services (samba, nfs, ftp), a few remote command services (ssh, telnet), and its usual collage of helpful newbie services (autodetect hardware, boot numlock, etc). Now, with all of this crap running on my antique P Pro 200-64mb, I boot in less than a minute from lilo to login prompt (and X is about 5 seconds more). I think XP home would barely beat that time on a system that old, and it can't serve things. And yes, faster systems scale nicely; my Debian system is extremely fast lilo->kdm; as good as my XP pro in fact, and it still has all the server trimmings.
Now, on the other hand (for a fair comparison), if you've ever experienced a windows 2000 server machine with active directory, you know real pain. From boot.ini to load of video drivers is fast, but after that, restoring network connections can take as long as five minutes even on a fast system.
So in conclusion, a default install of any random distro may or may not be slower starting up than another OS (read Windows), but just make sure you're making a fair comparison. If look through your
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.
I've seen the exact opposite approach taken - switching from parallel to serial to reduce startup times.
The reason this worked was that starting processes in parallel increased disk contention and the extra seeks brought the machine to a crawl.
Sure, that was on a system with very slow seek times, and not much in the way of disk caching and scheduling (an Amiga 500 with no HD). A lot of things have improved since then, but seeks are still extremely slow in machine terms, and we also have virtual memory and demand page loading which I imagine don't help the problem.
Maybe keeping data needed at startup centralised on the disk (e.g. in the boot partition) would help.
As disk accesses during startup are probably pretty predictable (consistent from one boot to the next), it may be possible to pre-load the disk cache to improve startup times.
A simple approach would be to log disk blocks accessed during startup, and then read them (in a sensible order of course, and in parallel across disks) at the start of the next boot.
I thought there is an outfit called "linuxbios" that supposed to make re-booting, especially cold-booting a very fast process.
Can anyone here tell me the recent progress of "linuxbios" ?
Thank you !
Muchas Gracias, Señor Edward Snowden !