Am 07.07.2010 01:03, schrieb Ken Moffat: > > Well, if you have a watch with a second hand or a seconds display, you > can try building two systems (for *your* definition of how much or how > little is contained within a system, in particular what services are started). > Then, try booting each of them several times and take an average. Yes, > I know that only resolves to about 1 second, and a stop-watch would be > better, but I think it will give enough information for an early stage review. I think that I'm going to test things like that next time. > You also get to find out if there are oddities about how the new > dependencies are built (e.g. do they have to pull in a shed load of other > packages that we don't build). http://linuxfromscratch.org/pipermail/lfs-dev/2010-July/064012.html > You are the person suggesting a change. I'm trying to persuade you > to do the leg work and produce figures to explain why it is beneficial. > Generally, saying "almost everyone else does it now" is not an adequate > reason to persuade LFS to change. Ok, I'll try to explain the most important things about Upstart ...
1. Every task is a job (one separate file per job): An example job (jobname is sethostname; jobname is set by the filename): start on startup exec hostname -b -F /etc/hostname 2. The jobs will be executed when an event occurs. In my example it is the event "startup" (which is always the first event; produced by Upstart itself). The next job that depends on my job can use "start on stopped hostname" in the first line. 3. Jobs that doesn't depend on each other can be executed simultaneous (and this will save boot time). 4. Jobs will only be executed if they are really needed: If there's no network connection, NTP will never be started (for example). 5. What if, when starting a daemon or executing a program fails? This can be checked with something like "stopped hostname ok" or "stopped hostname failed". See http://upstart.ubuntu.com/wiki/JobFailedEvent for more information. > You talk about replacing the current bootscripts with "event based > jobs". I have no idea what this means. At the moment, if I add in a > new package to my own builds which needs something started in > certain runlevels, I take the template and edit it. If we were using > these "event based jobs", what would I have to know when starting > a new service ? This may all be as clear as day to you, but to some > of us here you might as well be speaking in gibberish because we > don't understand the practical changes. You'll have to create a new job (if it is not already included in the package itself). An example: start on network_up /usr/local/apache/bin/httpd -f /usr/local/apache/conf/httpd.conf And this is much shorter than the init script of apache. > Maintenance of the main part of the LFS bootscripts doesn't seem > to be required very often, in fact looking at the current and previous > releases (ignoring contrib/) it's only udev that needed changes. But, > since I've no idea how these event based jobs would look, it's hard > for me to say that you are either right or wrong. > > Further - at the moment I can, if I wish, start in a particular run level, > but you say that run levels will disappear. There is only one "dyed in > the wool" run level that particularly matters (I assume you can still > reboot and shut down in the normal ways) - run level 1 or single user > mode. Do your alternative method(s) continue to support that ? That depends on the job definitions. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
