LPC: Booting Linux in five seconds

Well, if it's a sport - I agree, there should be the same rules for everyone :-)

However, otherwise I simply want to start working as soon as possible after I've logged in (as probably most people here, I seldomly boot). Obviously showing a screenshot of the desktop is just plain silly, but why should I have to wait for some network share to be mounted unless I really need it?

Applications will start slower, sure, but if the system is unusable because of I/O caused by daemons starting in the background I'd consider that a plain bug which should be fixed.

// Simon

What question are we discussing here? Are we discussing what some useful rules for an artificial game are, or what should normal system startup behaviour be?

Let's address the second of those first.

Note that what's been demonstrated isn't in fact "done" by 5 seconds: networking isn't up, bluetooth isn't up, various other services aren't up. Some users do want these services to be started at around boot time (e.g. maybe they can't get any work done until the network is up, or have only a bluetooth keyboard), but may nevertheless want to be able to start work before waiting for the some services to have started. In other words, they do want the system to be "putting up a desktop while still starting services behind the scenes" (or at least put up a desktop before all services have started, i.e. further delaying some services to reduce resource contention while the user starts some applications). Certainly many users would want to be able to enter their username & password while other things are still starting, as an instance of parallelization.

That still leaves various issues like avoiding bad behaviour when applications (including the one handling the login) don't have services they need, but we can at least say that in principle users would like to have a usable desktop as soon as possible even if some services that they want to be started around boot time haven't yet started.

On to the question of good rules for a game.

The idea of having such a game is for it to result in improvements to the systems that people actually run, where "improvements" is defined by what people actually care about.

If the game rules result in a system too distant from what will run on real systems, then it's harder to translate the game-produced system across to real systems, which may result in this transferral not happening. This suggests that the game rules should be such that the resulting system does start networking, avahi etc. (That's not to say that the goodness metric should be simply the time taken for all services to have started.)

Having game players spend time "do[ing] a lot of damage to X" or changes that break hardware that distributors want to support regardless of boot time, such work isn't useful unless someone does the remaining work of re-adding any of the lost functionality that the distributor considers more valuable than the corresponding reduction in boot time. If there's doubt as to whether anyone would do that work, then maybe the rules shouldn't reward optimizations that do more damage than most distributors would accept; whereas in cases where it is likely that someone else would do the work, then perhaps it's better to reward work on such damaging optimizations than not to have those optimizations.

Different users need different things started up before they can be productive with their machine. The goodness metric for the game can either go for simplicity (choose a common case and optimize that while ignoring all others' needs), or we can try to weight different cases according to their importance to most distributors (which is somewhat arbitrary in choice of weighting, but should result in improvements for more users). We don't have to choose the weights in advance, it's enough for game players to understand that it will be judged by a weighting of the value of the system for different types of users, and that the weighting and judgement of "system value" is intended to reflect real-world values. (Of course there's value in game players being informed about the relative importance of different use cases or how people value boot time compared to lost functionality, but we don't need to specify it all in great detail before a game can begin.)

On the question of delaying login to avoid applications misbehaving when services they need aren't started yet: Note that even the program handling the login might need the network up (for network filesystems or other remote databases) or need setroubleshootd running to debug a problem in that login handler. Maybe some upstart (etc.) ideas can be applied to user applications rather than just init scripts. (Some init replacements work statically, doing a topological sort to determine startup order, whereas other init replacements, possibly including upstart, allow for processes to be started but block on some service coming up.)

I really don't understand this argument. So the machine has not really booted, since network (for example) is not up yet? Well, why should it be? Because you want to use the network right after you get to the desktop? Well, think about it: You get to the desktop, but the network is not yet running. You then decide to launch Firefox. It takes you maybe 2-4 seconds to click the Firefox-icon, it takes anout 2-4 seconds for Firefox to launch, and then it takes you another 2-4 seconds to type in an URL in Firefox. That means that the system has 6-12 additional seconds to bring the network up before you actually NEED to have the network up&running. Network might not be running right after you get to the desktop, but it does not need to be, since it would take you several seconds to actually DO something with the network in any case! Do you need to have networking up if you are not actually using the network for anything?

People who complain about services that are not running right after boot, fail to understand the fact that it takes several seconds for the user to actually DO anything with the system in any case. And that means that the system has quite a bit of time to bring any missing service up before the user actually needs it. Whenever I log in to a machine, I do not launch apps in a split-second or start frantically working right away. No, it takes me quite a few seconds to get up to speed. And the system can use those seconds to load any needed services that are not yet up.

Of course there are wrong ways to do this, like what MS does with XP, where the system is actually un-usable for longish time after you get to the desktop.

The log-in screen should be shown as early as possible (before even X) and should not block the boot process. Thus the computer would be usable earlier, because the boot process would continue while the user is typing her password. This is especially important for users who are slow to authenticate -- some users take about 4 seconds. With a normal boot, they would wait n seconds to see the log-in screen, spend m extra seconds logging in, then wait d seconds till they can use the desktop. If they can authenticate after x second while the computer is booting, they only wait max(n - x, m) + d seconds to use the computer.

With a long boot, this also allows users to authenticate themselves whenever is convenient for them, rather than waiting to do it at the right time for the machine.

And, knowing which user is logging in will allow further parallelization of loading the user's desktop components and services. That will reduce the time "d" required to start up the desktop.

Any serious effort to bring down boot times will inevitably scrutinise each and every daemon and service started and likely do away with a few less essential ones. As a side-effect, that may very well make a system use less resources and be more stable and secure once the system has been brought up.

I also believe that faster boots give us happier and more productive kernel hackers, because they reboot more often than anyone else. That alone makes it worth the trouble.

Probably not, as it stands.

I suppose a complex application that takes a long time to start in its own right (OpenOffice, I'm looking at you) might take some hints from the methodology and try to parallelize and optimize its startup tasks. I'm not sure how far you get with a userspace app like that though.

I suppose if you have an embedded device that actually gets powered off and on semi-regularly (media player, cell phone), this work directly impacts the user experience. Those devices could actually boot from scratch rather than dumping state to flash for suspend when they power off. That extends flash lifetime, and it makes startup and shutdown quicker.

My current cellphone takes a good 15 seconds to boot. Booting in 5 would be a noticeable improvement. Granted, I only shut it off when I'm flying somewhere or when the battery gets obnoxiously low, but still, it could make you a favorite with the jet setters. Seeing as there's already interesting Linux distributions running on OpenMoko, I'm sure there's plenty of opportunity for cross-pollination. (Check out this one: http://mobile.slashdot.org/article.pl?sid=08/09/21/1730256 )

Are you talking about suspend or hibernate? Resuming from suspsend takes about 9 seconds on my Thinkpad T42p, while resuming from hibernate takes 1.5 mins. This is unfortunate because cold boot takes less than a minute... I tend to suspend/resume a lot and never ever hibernate.

When Linux supports process suspend/resume, hopefully resuming from hibernate becomes:
- boot in 5 secs
- restore your suspended apps

I can't wait for containerization to hit.

Ubuntu seems to push kernel updates that want a reboot every few weeks. That said, I usually push it to a couple months before I do reboot.

Could you tell us why Sys V init was prefered to upstart? Shouldn't upstart replace xinetd _and_ init _and_ provide faster boot through parallelisation?

Do you think it's possible to boot in 5 seconds with upstart 0.5 or a later version? Or is upstart (partly) going the wrong way?

Please enlighten us, or point us to a blog with your problems/decisions listed :-)

That doesn't really work. CUPS without the browsing is not really useful. And for the browsing you need to run it continuously all the time. Much like Avahi.

It's nice to be able to boot in 5s, but this is far from a standard Fedora system. Be honest!

CUPS does printer autodiscovery (zeroconf style, but on other ports), so
some people want it running to find printers. :/

And it manages local queues occasionaly, which was one reason I heard to
have it run all the time. (Not sure if this applies.)

Ciao, Marcus

Although according to your boot chart, you're not starting xinetd either ;)

Starting CUPS on demand isn't quite ideal sadly, if the user is using
network printers, then CUPS needs to have already been running for about
30s before they try and print otherwise the network printer won't be shown.

Sadly we can't "start CUPS 30s before the user needs it" ;)

Though I entirely agree in principle that CUPS is not part of the critical
path of the boot sequence, if the system is idle at some point, it's worth
starting -- even if that means the disk isn't entirely inactive after boot.

The most ideal way to deal with these kinds of services is to start them
after boot, when the system is idle - with low CPU and I/O scheduler
priority so that user activity takes precedence - or activate them on
demand by xinetd or D-Bus when the user actually needs them.

That way, if the user clicks print and cups wasn't running yet, it gets
brought up -- or if the user leaves their PC alone for a bit, we start cups
for the next time they click print.

Of course, even better would be if we could do network printer discovery
via other means like Avahi -- but then Avahi falls into the exact same
"start on idle or first demand, whichever is sooner" category

No server vendor should enable Sendmail as daemon by default either. Accepting mail on port 25 is uncommon. Sending out mail isn't, but it is done on demand with Sendmail from the command line. What cannot be sent can be pushed out with a cron job that does a sendmail -q every now and then.

Because programs that crash are not necessarily in a consistent state, so
crash recovery can fail where ordinary bootups do not. (Of course, if you
can make crash recovery reliable with something like application-level
journalling, your point stands, unless like databases the post-crash
bootup is really expensive. But that's probably a rare case.)

Uh... so if I hit "save" while using my app, that app should always fsync before returning? That sounds awful. (I guess the alternative is that we just throw away the files that users thought they had saved, but that seems suboptimal.)

IIRC emacs (used to?) do this by default, and until I disabled that it was unusable on a laptop, because hitting C-x C-s blocked everything for a few seconds waiting for the drive to spin up. ELISP SMASH

> I assume he meant wake up from suspend-to-ram...
He did.

YAY! Another ugly crock bites the dust...

(of course we still need /lib/cpp for the occasional non-X program that
uses imake. Can't live without xpilot, now, can we. ;) )

A better way to do that is:

apt-get install debian-goodies ; checkrestart -v

That gives you package names and init scripts to run.

And given that you don't really hear a chorus of start-up chimes from business travelers' laptops once the electronics gag has been lifted, that's obviously what they've been doing all along: suspending.

Nobody fully turns off their PDAs too, as far as I can tell. Though you hope they do remember to put them to in-flight mode...