Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
IBM Software Linux

Booting Linux Faster 625

Posted by CowboyNeal
from the every-little-bit dept.
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.
This discussion has been archived. No new comments can be posted.

Booting Linux Faster

Comments Filter:
  • Predicted response (Score:5, Insightful)

    by Anonymous Coward on Thursday September 18, 2003 @05:51PM (#6998850)
    "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.

    • by Anonymous Coward
      Yup.. just keep talking about that and wonder why Linux never becomes mainstream.

      Because mainstream means rebooting every day! Twice on Sundays.
    • by ftzdomino (555670) on Thursday September 18, 2003 @07:46PM (#6999820)
      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.
    • by kelnos (564113) <<ude.llenroc> <ta> <32tjb>> on Friday September 19, 2003 @03:06AM (#7001820) Homepage
      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...
  • by Anonymous Coward
    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.
    • by pudding7 (584715) on Thursday September 18, 2003 @05:53PM (#6998870)
      Anyone ever wonder how we got ourselves into a situation where we spend so much time saving ourselves time?
    • the /etc start scripts are very unix standard, so you see them all over and cross-platform developers don't have to write special startup modules/programs/scripts/plug-ins/whatever for linux. the "nifty" colors and functions some distros use are bad enough for that, but at least you can still dump in a normal self-contained shell script.

      it really doesn't serve linux well to become totally different. before deviating from the norm, the reason has to be a lot better than "i'd like to boot my system 45 seco
    • This is a blatant troll. The current init.d scripts system IS a way to start and stop daemons with a set of standard command line options. Realistically, there isnt any noticable performance hit from using bash scripts, especially considering the scripts used to start system services are usually incredibly simple.
    • ... or simply don't run the services you don't need? Distros try to please all the people all of the time. That doesn't mean you need to run half the stuff that's provided.

      A very interesting experience for me was starting from scratch and only *including* the stuff I needed when playing around with a minimal linux distro (crux linux). You'd be amazed how much crud you don't need and how much faster the system boots ...

  • by rocjoe71 (545053) on Thursday September 18, 2003 @05:52PM (#6998858) Homepage
    Like any Linux user is gonig to reset their uptime just to see if they can boot faster!
    • What why
      ***REBOOT IN 1 MINUTES***
      not? It's worth a try rig............
    • Isn't there a way (Score:3, Interesting)

      by SHEENmaster (581283)
      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".
    • by Sleepy (4551) on Thursday September 18, 2003 @06:17PM (#6999085) Homepage
      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...

      • by Master Bait (115103) on Thursday September 18, 2003 @07:11PM (#6999506) Homepage Journal
        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 [linuxbios.org] development. It is so fast, that it was finished checking the computer's hardware before the disk drives finished spinning up.

      • Gentoo claim they go the extra mile for "performance"

        My *cheap ass* Athlon 1700 gentoo box (total system value: 300$) can *reboot* gentoo in under 30 seconds, INCLUDING X. What else do you want?

        If your linux box takes more then 30 seconds to boot up you are either A: running way too many services, B: You're running Mandrake/Redhat (in which case you're guilty of A to).

  • by Atmchicago (555403) on Thursday September 18, 2003 @05:53PM (#6998861) Homepage
    you insensitive clod!
  • Hmm (Score:2, Interesting)

    by Arker (91948)

    I guess someone has a use for this, or they wouldn't have spent the time working on it. But I don't see it.

    I never noticed Linux taking very long to load, and even if it did I doubt I would care very much, as reboots are so rare anyway.

    • Re:Hmm (Score:5, Insightful)

      by 4of12 (97621) on Thursday September 18, 2003 @05:59PM (#6998930) Homepage Journal

      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.

      • Gee. Why does my TV use power when it's turned off then?
      • Re:Hmm (Score:3, Insightful)

        by MatthewB79 (47875)
        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 [handhelds.org] with the Opie [handhelds.org] 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
    • I use Linux but have to shut down every night to maintain sanity. Computer noise (in fact even transformer buzz) keeps me awake without fail, even if the machine is in another room. Maybe I should buy earmuffs.
    • Think availability guarantees. Once you get into the rarified world of 9 9's, every minute counts.
    • Re:Hmm (Score:5, Interesting)

      by Obasan (28761) on Thursday September 18, 2003 @06:13PM (#6999055)
      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.
  • Timely (Score:2, Redundant)

    by pete-classic (75983)
    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
    • Did he return your volley by asking you if you were willing to pay the electricity bills until you moved out if you're leaving the computer on all the time?
    • Re:Timely (Score:3, Insightful)

      by Arker (91948)

      Why is it taking long to boot up? That's not my experience. Loading a lot of services?

  • This sounds like an awesome reason to have multiple cpus. Maybe I missed it in the article (I did read it rather quickly), but it didn't look like it was mentioned.

    Even on an HT-enabled P4 this would be cool. Although the I/O would be the limiting factor in the process startup speed, letting multiple proceses start up at once would allow the cpu to switch to others while I/O is being services, much like make -j(# of cpus+1).
    • Actually, IO being the limiting factor would actually benefit this method. If each task initiated its IO transaction and waited while other tasks also initiated their IO transactions, it would definitely be more efficient that one task initiating IO, waiting for a response, processing the response and so on sequentially
    • Hmm, that would n't really score in a cost to benefit analysis. An extra CPU to save you 1-2 minutes a day would be kind of silly, unless your making 100's of $//E an hour.
    • by vadim_t (324782)
      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
  • Make? (Score:5, Insightful)

    by JohnGrahamCumming (684871) * <slashdot@@@jgc...org> on Thursday September 18, 2003 @05:55PM (#6998886) Homepage Journal
    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? (Score:5, Interesting)

      by clem.dickey (102292) on Thursday September 18, 2003 @06:27PM (#6999167)
      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? (Score:3, Interesting)

      by MBCook (132727)
      I thought it was suprising at first. Yes, that is what make is designed to do, but I'd think most people (myself included) think of make as a programming tool. I don't think I would have thought about using make for that job, at least not at first.

      This isn't make's intended use (it was designed for programming), so it's a bit suprising to see it used this way at first.

      That said, it does make perfect sense.

    • Re:Make? (Score:3, Informative)

      by The Pim (140414)

      How surprising that they choose to use an open-source software application that is designed to compactly represent dependencies for representing dependencies.

      Surprising to most people, because they don't understand what make is. There's a well-known paper [tip.net.au] that tries to explain what make is and how to use it effectively. As it says, "Make is an expert system". Meaning, you give it a bunch of rules, and it tries to get you to your goal. Make would get a whole lot less flack if people understood this.

    • Re:Make? (Score:3, Funny)

      by svu (67887)
      Visio?! Easy! You take Visio 2003. Generate XMI. Then - apply some XSLT stylesheet to create build.xml for the ant tool. Then use ant instead of make as startup tool. So you got visual design for you startup sequence!
    • Re:Make? (Score:5, Interesting)

      by slamb (119285) on Thursday September 18, 2003 @06:44PM (#6999272) Homepage
      > > 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? (Score:4, Informative)

        by Webmonger (24302) on Thursday September 18, 2003 @09:41PM (#7000584) Homepage
        Actually, Makefiles don't have to be single monolithic files. GNU make supports the include command, which takes wildcards.

        So in MakefileRC5, "include /etc/makerc5.d/*" would include all the makefiles in the specified directory. Such makefiles would be lpd.mk and ntpd.mk, etc.

        I think that might actually work!
    • Re:Make? (Score:4, Insightful)

      by Jellybob (597204) on Thursday September 18, 2003 @08:49PM (#7000307) Journal
      I can understand the most blindingly obvious things being surprising.

      If you were to drop someone with no knowledge of electricity into a room with a switch, and they flicked that switch, they'd be surprised when the light comes on, despite it being "obvious".

      And that's because things are only obvious once you know them, right up until that point, they're just an unsolved problem.
      • Re:Make? (Score:4, Funny)

        by Dr. Photo (640363) on Thursday September 18, 2003 @11:46PM (#7001205) Journal
        If you were to drop someone with no knowledge of electricity into a room with a switch, and they flicked that switch, they'd be surprised when the light comes on, despite it being "obvious".

        And if the light were a nice bright halogen lamp, it might even be blindingly obvious!

        (Terribly sorry.. couldn't resist...)
    • Re:Make? (Score:5, Insightful)

      by Feztaa (633745) on Thursday September 18, 2003 @10:05PM (#7000712) Homepage
      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 :)
  • by Anonymous Crowhead (577505) on Thursday September 18, 2003 @05:55PM (#6998889)
    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.
    • by Michael Woodhams (112247) on Thursday September 18, 2003 @06:59PM (#6999377) Journal
      Something for the usability folks to think about:

      Ordinary users, and even many geeks, don't have time to figure out what every service does and whether they use it. A policy of aggresively turning off services (mostly for security, partly for boot time) carries a risk of turning of a service that is needed.

      I suggest that there should be a standard framework for dealing with "a needed service is not running" problems. On a desktop Linux, this should pop up a window explaining what service wasn't running, and giving options to do nothing, start the service on a one-time basis, or add the service to boot time start-up (and prompting for root password as required.)

      (There can be extra options - don't start the service, and never ask me again. Don't start the service, and never ask me again if this particular program complains about it.)
  • by epiphani (254981) <epiphani.dal@net> on Thursday September 18, 2003 @05:56PM (#6998894)
    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.
  • how to decrease boot times for your Linux box

    Well, I might suggest faster hard drives....... :-) Seriously though, going from ATA to Ultra 320 drives made my G4 box pretty snappy on all disk related activities, including boot times.

  • by pclminion (145572) on Thursday September 18, 2003 @06:00PM (#6998937)
    I still remember the days when I installed Slackware off floppies, and unless my memory is failing much faster than anticipated, I don't think the kernel itself takes much longer to boot than it ever did.

    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? ;-)

  • To all the people that wonder what use this is (because linux never needs rebooting I guess), consider this. I had a toshiba laptop w/ linux on it. I don't know why hibernation doesn't work (it does on my IBM thinkpad w/ no problems) but it just doesn't. Therefore, this 466 celeron has to boot up every time I use my laptop.

    This slow boot time has caused me to put WinXP back on it, because it takes a 466 FOREVER to boot vs wake up from hibernation. This is also a shameless plea for any advice on how to
    • Sometimes machines ship with a hibernation partition. Did you remove it when you installed linux? If you did, have fun. I have no idea how to get it back.

      Also, why not just suspend instead of hibernate? Suspend is typically faster anyway although I think it consumes slightly more battery power when asleep. Try 'apm -S'
  • by rowanxmas (569908) on Thursday September 18, 2003 @06:02PM (#6998952)
    Because it must be asked....

    How much time is saved when booting up a beowulf cluster?
  • i think the best idea in the article is the last bullet point under "additional considerations," specifically that you just configure the system to let you log in earlier. since this is (as the article points out) mostly useful for desktops (or, more likely, laptops), a user doesn't need to wait for sshd or a web server to start before (s)he logs in.

    i'm too used to the serial boot to use parallel booting. even on a desktop, i like to see the boot messages scroll by just in case.

  • Serel (Score:5, Informative)

    by ensignyu (417022) on Thursday September 18, 2003 @06:04PM (#6998979)
    Serel [fastboot.org] 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.
  • Contrary to most comments here about how this isn't needed because of uber uptimes of linux l33t users, some people would benefit from this. Any gamers who have to dual boot to windows to play some games will want this (you think HL2 will play on Wine when it comes out?). There was a time when I would reboot almost everyday (before BF1942 was playable on Wine). Sure, saving a 30 seconds or so per day isn't a big deal, but it's nice to be on par with WinXP's boot time.

  • FastBoot.org? (Score:2, Informative)

    by nickread (217474)
    Isn't this basically the same thing (different implementation though).

    http://www.fastboot.org/
  • by augustz (18082) on Thursday September 18, 2003 @06:11PM (#6999037) Homepage
    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.
    • by John Hurliman (152784) on Thursday September 18, 2003 @06:30PM (#6999184) Homepage
      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.
    • Ok, I agree that boot time is important in many specific cases. However, you say

      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
  • by vlad_petric (94134) on Thursday September 18, 2003 @06:13PM (#6999047) Homepage
    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
  • by TornSheetMetal (411584) on Thursday September 18, 2003 @06:16PM (#6999075)
    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.
  • by MotownAvi (204916) <avi.drissman@com> on Thursday September 18, 2003 @06:24PM (#6999145) Homepage
    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).
    • You beat me to it. OS X also implements dynamic disk mounts even for root. Disks are mounted and assigned to a device on a first-come first-served basis.
    • 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.
  • netbsd rc.d (Score:5, Informative)

    by Fritz_the_Cat (100676) on Thursday September 18, 2003 @06:25PM (#6999151)
    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
  • by tim1724 (28482) * on Thursday September 18, 2003 @06:36PM (#6999219) Homepage Journal

    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:

    • Linux DID adopt it. (Score:3, Informative)

      by Balinares (316703)
      > 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.
    • Oooh I know I'm going to get flamed for this.

      On a Windows box:

      net start w3svc

      That will start IISAdmin automagically too. :)

      Gentoo's init scripts have dependency checking too. Now, if they started in parallel.. Wheee! That would certainly rock for bootup time on my laptop.
  • by CausticWindow (632215) on Thursday September 18, 2003 @06:52PM (#6999329)

    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.

  • Nostalgy (Score:4, Informative)

    by Peaker (72084) <gnupeakerNO@SPAMyahoo.com> on Thursday September 18, 2003 @06:54PM (#6999341) Homepage
    I have started a discussion [debian.org] 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 :)
  • by Fefe (6964) on Thursday September 18, 2003 @07:05PM (#6999450) Homepage
    See www.fefe.de/minit/ [www.fefe.de] 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).
  • by AxelTorvalds (544851) on Thursday September 18, 2003 @07:26PM (#6999646)
    It was a Pentium 300 Mhz class machine in an embedded device. I had the kernel in flash and used my own variation of the linuxbios project.

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

  • by ldamerow (708805) on Thursday September 18, 2003 @07:43PM (#6999802)
    Richard Gooch published an interesting implementation of parallel init scripts almost a year ago: http://www.atnf.csiro.au/people/rgooch/linux/boot- scripts [csiro.au]
  • New boot system (Score:3, Interesting)

    by Hard_Code (49548) on Thursday September 18, 2003 @08:04PM (#6999951)
    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 [www.fefe.de], 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.
  • by drinkypoo (153816) <martin.espinoza@gmail.com> on Thursday September 18, 2003 @08:23PM (#7000092) Homepage Journal

    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.

  • by Skapare (16644) on Thursday September 18, 2003 @10:47PM (#7000975) Homepage

    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.

"No job too big; no fee too big!" -- Dr. Peter Venkman, "Ghost-busters"

Working...