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.

Comments

Predicted response

[Anonymous Coward]

"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.

Re:Predicted response

[Crispy Critters]

"This is the current state of the Linux community."

No it isn't. I am on a local LUG mailing list, and people are politely helping newbies all the time, going out of their way to explain things that weren't even asked, just in case it might help.

"Not only the case on Slashdot, but go to any IRC help channel and you'll find the same the majority of the time."

IRC and /. were not exactly designed for thoughtful interaction.

Re:Predicted response

[Trepalium]

In order for him to get a straight answer he had to pre-emptively insult himself "Guys, I know I'm entirely retarded, but does anyone know how to get mplayer to play X?"

Uhm, so you think that just because someone insulted himself during the post means that everyone who might provide you with free technical support on Linux is a prick? Hate to break this to you, but that's hardly Linux's fault. Regardless of what you look for support on, you'll find idiots who want to give you snide comments like RTFM, or go do it yourself. My experience is that most people will try to help you provided you show that you made some effort to solve the problem yourself (such as state what you tried that didn't work).

Lets assume that you call a vendor for support. You'd likely to have paid for the support, so the vendor will likely allow you to be somewhat abusive of their support personelle because the money you pay them is worth the inconvenience. Now, most of the support you get on newsgroups is by people not getting any income for answering your questions, so their tolerance to put up with crap is significantly decreased. If you even ask a question in such a way that makes you look like you might be one of the assholes they deal with in the support business, you will be dropped as quickly as possible. When you want something for nothing, being polite and courteous versus appearing to bark out demands is the difference between getting an answer, and getting "RTFM". BTW, this applies equally to proprietary software lists (unmanned by paid employees) as to free software lists. Lists and discussion groups with paid employees answering questions (such as microsoft.public.*) can be friendlier, but you get boilerplate responses more often, and the same answer three times over before someone finally gets that their solution doesn't work for your problem.

Re:Predicted response

[mangu]

The problem was "There is a sense of snideness in the Linux community, and trying to ask for support is one of those examples of snideness."

I think this "problem" you mention is some sort of urban legend. I have heard this same argument countless times, but I have never actually seen this happen. I have been a subscriber to a few Linux mailing lists for several years now, and I have never actually seen someone post "RTFM" as an answer to a question.

Myself, I try to sort of evaluate the person who is asking for help. If I think he has an adventurous soul, and is willing to go through a lot of documentation, I try to orient him to the relevant how-to's. In the other hand, if I feel the person is somewhat impatient, I recommend a Mandrake installation, since it's the most likely to get the user safely past the most annoying problems with minimum fuss.

Re:Predicted response

[ftzdomino]

What really sucks is the 497.1 day uptime rollover bug. Apparently it has been fixed, but that doesn't help us who booted before it.

Re:Predicted response

[AstroDrabb]

This isn't true. I am one of the moderators for Red Hat @ yahoo and I am very active in Linux @ Yahoo. Join up. We are very kind over there. We only ask that

1. No top posting
2. No broken mailers that don't thread well (Outlook/OE)
3. Learn to search www.google.com.

I never see people getting into flame wars. The same thing goes for most LUGS. Come to one of the Yahoo groups and join up : )

Re:Predicted response

[kelnos]

seriously... after reading through a bunch of these posts, i see soooo many "why do i care how long it takes to boot up? i just boot it and leave it for a year." a few are joking, but most are just ignorant idiots. sure, there are some of us (myself included) that don't turn off their machine (i probably would to save on the utilities bill, but i host websites for a few student orgs at my school, among other things). anyway, there are _plenty_ of people that could make a faster boot useful. laptop users, for one. people that only use their computers for a few short tasks a day, and turn it off. people that don't need to run it overnight for whatever reason, and actually like the idea of saving a little energy.

get a little perspective, people. ignorance is so first millennium...

Yeah, right!

[rocjoe71]

Like any Linux user is gonig to reset their uptime just to see if they can boot faster!

Re:Another way to speed up booting Linux

[pudding7]

Anyone ever wonder how we got ourselves into a situation where we spend so much time saving ourselves time?

Make?

[JohnGrahamCumming]

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.

Re:Make?

[clem.dickey]

Not having looked at the code, it seems to me that make would only handle half the problem: booting. Shutdown is the other half; the dependencies would be reversed. For example:

For boot you would tell make this:

sshd: network
rpcd: network

But for shutdown you need to tell it this:

network: sshd rpcd

Ideally one set of input data should take care of both cases.

Re:Make?

[slamb]

> > 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.

Actually, I also found it surprising, and I think I know "make" pretty well. The thing about make is that in 95% of cases almost all of the rules correspond to an actual target file that should be generated or not based on presence and timestamp. There are exceptions, like the usual "all" rule that's called a phony rule since it generates no file. (And make sure you have a ".PHONY: all" line right before it or "touch all" will break your build.) It's usually just there for the dependencies on a bunch of real targets, so you don't have to type "make this && make that && make ...".

Parts of make that they're not using here:

• logic for checking if a real target is up-to-date
• rules for creating specific targets from generic ones, like the .c.o target
• variable substitutions
• a lot of other things...look at the man/info pages; modern versions of make have a lot of functionality that makes no sense here

And they are using:

• topological sort (easy algorithm!)
• stuff for following the partial order in parallel (also surprisingly easy)
• the parser, but it's for a widely-disliked syntax that doesn't make a lot of sense here

When I say the syntax doesn't make sense here, I mean (in addition to the usual make complaints) that it's all in one file. Distributors (notably RedHat in particular) have been very serious about separating out stuff into .d directories so that packages don't need to touch each others' files.

So, I think make is the wrong tool for the job here, at least in the long term. A simple tool with separate files for each service would be a win. I don't think the author of the article really cares about that (it's just a little tip for intermediate users), but if a distribution wanted to implement this idea and maintain it, they wouldn't use make.

Re:Make?

[Feztaa]

I think it's clever, because (possibly) nobody ever thought of doing it before. Make is a tool that makes it easy to compile programs, not for booting your system.

I've heard that a program isn't truly successful until it's been used in a way unimagined by the original author. I guess make is now truly successful :)

Just turn off services you don't need

[Anonymous Crowhead]

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.

Other things to speed up boot time

[epiphani]

These may seem obvious, but if you're after a quick boot, try doing these things:

• Recompile the kernel with bare essentials only - monolithic.
  
• Turn off non-essential non-inetd services.
  
• Tweek your rc.d scripts to get rid of things like modprobe calls.
  
• Dont boot directly to xdm if you dont have to.
  

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.

Re:Hmm

[4of12]

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.

Serel

[ensignyu]

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.

Re:Serel

[gmhowell]

It may not be a proof of concept, but it seems to be a beta that hasn't been touched in a year. And debian packages (on the site I looked at) aren't available, only rpms.

Still, looks nifty.

Re:boot?

[kcurtis]

> 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.

This is actually important

[augustz]

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.

Re:This is actually important

[John Hurliman]

A lot of comments also missed a major platform, laptops.

I've been furiously tweaking out my Averatec to get the quickest possible bootup (and shutdown); everything from a highly customized 2.6.0 kernel, to experimenting with software suspend and custom startup scripts. Right now I have my system booting the bare bones necessary services to get me in to X so I can turn the laptop on and fire up OpenOffice in class. The rest of the service launching is done with a shell script that I call after booting if I want to do more, like get on the net, use Samba or print.

Re: "you only need to boot it up once"

[vlad_petric]

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

Re:Hmm

[Obasan]

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.

PowerPC Linux users had compiled boot 'scripts'

[Sleepy]

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.

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.. .no "glory". Fixing this would be like someone fixing fdisk... no one wants to touch the damn stuff...

Re:PowerPC Linux users had compiled boot 'scripts'

[Master Bait]

That's a pretty good idea.
I use a bunch of homemade Xterminals made out of Nforce boards and we have replaced /sbin/init itself with an executable shell script (and use ash for the shell instead of bash). The entire contents of init is this:

#!/bin/sh
/bin/cat /dev/null > /var/run/utmp
/sbin/insmod /modules/nvnet.o
/sbin/ifconfig lo 127.0.0.1
/sbin/mount -o remount,rw /
/sbin/mount -t proc /proc /proc
/sbin/insmod /modules/nvidia.o
/usr/X11R6/bin/X -broadcast
/bin/sh

No shutdown script is necessary because Xterminal users simply logout and turn them off.

I think one of the biggest slowdowns on PCs is the lame PCBIOS which takes a very long time to run through all the hardware. I remember following LinuxBIOS development. It is so fast, that it was finished checking the computer's hardware before the disk drives finished spinning up.

Parallel startup implemented in Mac OS X

[MotownAvi]

Bah. Mac OS X's done this since Jaguar.

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_papers /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).

netbsd rc.d

[Fritz_the_Cat]

I'm surprised someone hasn't pointed this out already. NetBSD's rc.d.has had support for dependencies for sometime.
http://www.netbsd.org/guide/en/chap-rc. html

Additionally, there's an article here. http://www.daemonnews.org/200108/rcdsystem.html

Apple did this in Jaguar

[tim1724]

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:

• The System Initialization section of the Mac OS X System Overview document
• The Creating SytemStarter Startup Item Bundles HOWTO
• SystemStarter(8) man page

Re:Just use Jiffies

[CausticWindow]

Remember to turn back the uptime when you sell your computer.

That's exactly what I wrote minit for

[Fefe]

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).

I've been doing it since 1999.

[pr0ntab]

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.

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, :-P)

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.

My own rc/init scripts

[Skapare]

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:

• 000.12345.net_lo
• 020.--345.video_120x58
• 040.--345.keymap
• 060.-2345.mouse
• 100.-2345.net_eth0
• 101.-2345.net_eth1
• 190.-2345.gw
• 200.--345.random
• 220.-2345.syslog
• 240.--345.at
• 260.--345.cron
• 300.-2345.dns
• 320.-2345.nsd
• 400.-2345.ssh_main
• 410.-2345.ssh_alt
• 520.--345.inet
• 540.-2345.ntp
• 600.--345.mail
• 620.--345.http
• 640.--345.rsync
• 660.-----.pop3
• 700.----5.xfs
• 780.--345.ftp
• 800.--345.cache
• 950.----5.xdm

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.