[分享]ubuntu有望赶上xp启动速度了。改进init是办法

系统安装、升级讨论
版面规则
我们都知道新人的确很菜,也喜欢抱怨,并且带有浓厚的Windows习惯,但既然在这里询问,我们就应该有责任帮助他们解决问题,而不是直接泼冷水、简单的否定或发表对解决问题没有任何帮助的帖子。乐于分享,以人为本,这正是Ubuntu的精神所在。
回复
gydoesit
帖子: 153
注册时间: 2006-10-10 11:01

[分享]ubuntu有望赶上xp启动速度了。改进init是办法

#1

帖子 gydoesit » 2006-10-20 14:21

前些天发了一帖:

viewtopic.php?t=26904

什么时候ubuntu或其他linux的桌面版才能启动速度比得上xp?
现在的主流配置上,xp启动只要10多秒,可不管是fedora 还是 ubuntu,启动都要40多秒以上吧。反正我是50秒以上。用自动登录对比,免得登录时间不同。
即使换成轻量的桌面,快是快了些,但还是无法与xp比。至于网上说的什么优化,比如关不必要服务,启用read ahead服务等,都解决不了问题。


发帖后,大家反映不一,其实我的意思是希望大家能找出改变启动速度的方法,而不是纯比较哪个更快更实用。在我记忆中,看到有人把linux的init由串行变并行,并且当时这牛人给出了一些代码。不过文章找不到了。

今天看到了ubuntu官方开发upstart的消息,果然爽。E文不好,不过粗看了一下,是说原来的init为什么启动慢,是因为要先把驱动器扫描完才mount,把网卡找完才初始化网络。而现在,usb和网卡都可以即插即用,磁盘也可以放在NFS上。所以upstart采用事件驱动。显然,这完全改变原来那种串行的过程化的方式。

下面是转过来的文章:

Ubuntu正在开发Init系统的替代者

日期:2006-08-28 作者:netsplit 来自:osnews


--------------------------------------------------------------------------------

Ubuntu目前正在开发名为Uptsrt的系统,用来替代现有的init守护进程系统,该系统进程复杂内核进程的生成、挂起、停止等等。在该篇文章中,作者还比较了Solaris系统中的SMF、Apple公司的launchd和initng。

Upstart in Universe
upstart is a replacement for the init daemon, the process spawned by the kernel that is responsible for starting, supervising and stopping all other processes on the system.

The existing daemon is based on the one found in UNIX System V, and is thus known as sysvinit. It separates jobs into different “run levels” and can either run a job when particular run levels are entered (e.g. /etc/init.d/rc 2) or continually during a particular run level (e.g. /sbin/getty).

The /etc/init.d/rc script is also based on the System V one (and is in the sysv-rc package), it simply executes the stop then start scripts found in /etc/rcN.d (where N is the run level) in numerical order.

Why change it?
Running a fixed set of scripts, one after the other, in a particular order has served us reasonably well until now. However as Linux has got better and better at dealing with modern computing (arguably Linux’s removable device support is better than Windows’ now) this approach has begun to have problems.

The old approach works as long as you can guarantee when in the boot sequence things are available, so you can place your init script after that point and know that it will work. Typical ordering requirements are:

Hard drive devices must have been discovered, initialised and partitions detected before we try and mount from /etc/fstab.
Network devices must have been discovered and initialised before we try and start networking.
This worked ten years ago, why doesn’t it work now? The simple answer is that our computer has become far more flexible:

Drives can be plugged in and removed at any point, e.g. USB drives.
Storage buses allow more than a fixed number of drives, so they must be scanned for; this operation frequently does not block.
To reduce power consumption, the drive may not actually be spun up until the bus scan so will not appear for an even longer time.
Network devices can be plugged in and removed at any point.
Firmware may need to be loaded after the device has been detected, but before it is usable by the system.
Mounting a partition in /etc/fstab may require tools in /usr which is a network filesystem that cannot be mounted until after networking has been brought up.
We’ve been able to hack the existing system to make much of this possible, however the result is chock-full of race conditions and bugs. It was time to design a new system that can cope with all of these things without any problems.

What we needed was an init system that could dynamically order the start up sequence based on the configuration and hardware found as it went along.

Design of upstart
upstart is an event-based init daemon; events generated by the system cause jobs to be started and running jobs to be stopped. Events can include things such as:

the system has started,
the root filesystem is now writable,
a block device has been added to the system,
a filesystem has been mounted,
at a certain time or repeated time period,
another job has begun running or has finished,
a file on the disk has been modified,
there are files in a queue directory,
a network device has been detected,
the default route has been added or removed.
In fact, any process on the system may send events to the init daemon over its control socket (subject to security restrictions, of course) so there is no limit.

Each job has a life-cycle which is shown in the graph below:



The two states shown in red (“waiting” and “running”) are rest states, normally we expect the job to remain in these states until an event comes in, at which point we need to take actual to get the job into the next state.

The other states are temporary states; these allow a job to run shell script to prepare for the job itself to be run (“starting”) and clean up afterwards (“stopping”). For services that should be respawned if they terminate before an event that stops them is received, they may run shell script before the process is started again (“respawning”).

Jobs leave a state because the process associated with them terminates (or gets killed) and move to the next appropriate state, following the green arrow if the job is to be started or the red arrow if it is to be stopped. When a script returns a non-zero exit status, or is killed, the job will always be stoped. When the main process terminates and the job should not be respawned, the job will also always be stopped.

As already covered, events generated by the init daemon or received from other processes cause jobs to be started or stopped; also manual requests to start or stop a job may be received.

The communication between the init daemon and other processes is bi-directional, so the status of jobs may be queries and even changes of state to all jobs be received.

How does it differ from launchd?
launchd is the replacement init system used in MacOS X developed as an “Open Source” project by Apple. For much of its life so far, the licence has actually been entirely non-free and thus it has only become recently interesting with the licence change.

Much of the goal of both systems appears initially to be the same; they both start jobs based on system events, however the launchd system severly limits the events to only the following:

system startup,
file modified or placed in queue directory,
particular time (cron replacement),
connection on a particular port (inetd replacement).
Therefore it does not actually allow us to directly solve the problems we currently have; we couldn’t mount filesystems once the “filesystem checked” event has been recived, we couldn’t check filesystems when the block device is added and we certainly couldn’t start daemons once the complete filesystem (as described by /etc/fstab) is available and writable.

The launchd model expects the job to “sit and wait” if it is unable to start, rather than provide a mechanism for the job to only be started when it doesn’t need to wait. Jobs that need /usr to be mounted would need to spin in a loop waiting for /usr to be available before continuing (or use a file in a tmpfs to indicate it’s available, and use that modification as the event).

This is not especially surprising given that Apple have a high degree of control over both their hardware and the actual underlying operating system; they don’t need to deal with the wide array of different configurations that we have in the Linux world.

Had the licence been sufficiently free at the point we began development of our own system, we would probably have extended launchd rather than implement our own. At the point Apple changed the licence, our own system was already more suitable for our purposes.

How does it differ from initng?
Initng by Jimmy Wennlund is another replacement init daemon intended to replace the sysvinit system used by Linux. It is a dependency-based system, where upstart is an event-based system.

The notion of a dependency-based system is interesting to talk about at this point. Jobs declare dependencies on other jobs that need to happen before the job itself can be started. Starting the job causes its dependencies to be started first, and their dependencies, and so on. When jobs are stopped, if running jobs have no dependencies, they themselves can be stopped.

It’s a neat solution to the problem of ordering a fixed boot sequence and the problem of keeping the number of running processes to a minimum needed.

However this means that you need to have goals in mind when you boot the system, you need to have decided that you want gdm to be started in order for it, and its dependencies, to be started. Initng uses run levels to ensure this happens, where a run level is a list of goal jobs that should be running in that run level.

It’s also not clear how the dependencies interact with the different types of job, a dependency on Apache would need the daemon to be running where a dependency on “checkroot” would need the script to have finished running. Upstart handles this by using different events (“apache running” vs. “checkroot stopping”).

Again while interesting, Initng does not solve the problems that we wanted to solve. It can reorder a fixed set of jobs, but cannot dynamically determine the set of jobs needed for that particular boot.

A typical example would be that if the only dependency on the job that configures networking is the mount network filesystems job, then should that job fail or notbe a goal (e.g. because there are no network filesystems to be mounted) the result is that network devices themselves will not be configured. You could make everything a goal, and just use the dependencies to determine the order, however this is less efficient than just ordering the existing sysv-rc scripts (which
can be done at install time).

Another example is that often you simply don’t know whether something is a dependency or not without reading other configuration, for example the mount network filesystems may be a dependency of everything under /usr or may just be a dependency of anything allowing the user to login if it just mounts /home.

The difference in model can be summed up as “initng starts with a list of goals and works out how to get there, upstart starts with nothing and finds out where it gets to.”

How does it differ from Solaris SMF?
SMF is another approach to replacing init developed by Sun for the Solaris operating system. Like initng it’s a dependency-based system, so see above for the differences between those systems and upstart.

SMF’s main focus is serive management; making sure that once services are running, they stay running, and allowing the system administrator to query and modify the states of jobs on the system.

Upstart provides the same set of functionality in this regard, services are respawned when they fail and system administrators can at any time query the state of running services and adjust the state to their liking.

Will it replace cron, inetd, etc?
The goal of upstart is to replace those daemons, so that there is only one place (/etc/event.d) where system administrators need to configure when and how jobs should be run.

In fact, the goal is that upstart should also replace the “run event scripts” functionality of any daemon on the system. Daemons such as acpid, apmd and Network Manager would send events to init instead of running scripts themselves with their own perculiar configuration and semantics.

A system administrator who only wanted a particular daemon to be run while the computer was on AC power would simply need to edit /etc/event.d/daemon and change “on startup” to “on ac power”.

What about compatibility?
There’s a lot of systems administrators out there who have learned how Linux works already and will not want to learn again immediately, there’s also a large number of books that cover the existing software and won’t cover upstart for at least a couple of years.

For this reason, compatibility is very important. upstart will continue to run the existing scripts for the forseeable future so that packages will not need to be updated until the author wants.

Compatibility command-line tools that behave like their existing equivalents will also be implemented, a system administrator would never need to know that crontab -e is actually changing upstart jobs.

Does it use D-BUS?
“To D-BUS people, every problem seems like a D-BUS problem.”
—Erik Troan

The UNIX philosophy is that something should do just one job, and do it very well. upstart’s one job is starting, supervising and stopping other jobs; D-BUS’s one job is passing messages between other jobs.

D-BUS does provide a mechanism for services to be activated when the first message is sent to them, thereby starting other jobs. Some people have taken this idea and extended it to suggest that all a replacement init system need do is register jobs with D-BUS and turn booting into a simple matter of message parsing.

This seems wrong to me, D-BUS would need to be extended to supervise these services, provide means for them to be restarted and stopped; as well as deal with being process #1 which means cleaning up after children whose parent’s have died, etc. It seems far simpler to arrange for D-BUS to send an event to init when it needs a service to be started, and focus on being a very good message passing system.

The IPC mechanism used by upstart is not currently D-BUS because of various problems, however it’s always been expected that even if init itself doesn’t communicate with D-BUS directly, there would be a D-BUS proxy that would ensure messages about all init jobs and events would be given to D-BUS and D-BUS clients could send messages to init to query and change the state of jobs.

What is the implementation plan?
Because this is process #1 we are changing, we want to make sure that we get it right. Therefore instead of releasing a fully-featured daemon and configuration to the world, we’re developing it in the following stages:

Principal development; at the end of this stage the daemon has been implemented and can manage jobs as described.
Replacement of /sbin/init while running the existing sysv-rc scripts. This is the shake-down test of the daemon, can it perform the same job as the existing sysvinit daemon without any regressions?
/etc/rcS.d scripts replaced by upstart jobs. These consitute the majority of tasks for booting the system into at least single-user mode, and contain many of the current ordering problems and race conditions. If the daemon solves the problems here, it will be a success.
Other daemon’s scripts replaced by upstart jobs on a package-by-package basis; this will be an ongoing effort during which upstart will continue running the existing sysv-rc scripts as well as its own jobs. During this time the event system may be tweaked to ensure it truly solves the problems we need.
Replcement of cron, atd, anacron and inetd. This will happen alongside the above and result in a single place to configure system jobs.
Modification of other daemons and processes to send events to init instead of trying to run things themselves.
The current plan is that we will be at least part of the way into stage #3 by the time edgy is released, with that release shipping with upstart as the init daemon and the most critical rcS scripts being run by it to correct the major problems

For edgy+1 we hope to have completed stage #5 and be at least part of the way into the implementation of stage #6. From the start of development of edgy+2, no new packages will be accepted unless they provide upstart jobs instead of init scripts and init scripts will be considered deprecated.

What state is it in now?
The init daemon has been written and is able to manage jobs as described above, receiving events on the control socket to start and stop them. This has now been uploaded to the Ubuntu universe component in the upstart package for testing before it becomes the init daemon.

We welcome any experienced users who want to help test this; install the package and follow the instructions in /usr/share/doc/upstart/README.Debian to add a boot option that will use upstart instead of init. If your system boots and shut downs normally (other than a slightly more verbose boot without usplash running) then it is working correctly.

Other types of events will be added as required during development and testing. Currently only a basic client tool (initctl) has been written, compatibility tools such as shutdown will be written over the next week or two before it replaces our sysvinit package.

原文:
http://www.netsplit.com/blog/articles/2 ... n-universe
头像
zhuqin_83
帖子: 10606
注册时间: 2006-05-13 4:02
联系:

#2

帖子 zhuqin_83 » 2006-10-20 14:27

就是6.10edgy,都跟你说过了。
HP Pavilion DV6-2064CA: AMD Turion II Ultra Dual-Core Mobile M640, HD4650, 2GBx2 DDR2-800, Seagate 500GB 7200RPM SATA, BD-ROM
DELL UltraSharp 2209WA
Arch64, Testing repo
gydoesit
帖子: 153
注册时间: 2006-10-10 11:01

#3

帖子 gydoesit » 2006-10-20 14:33

嗯,同意楼上,我准备下一个来玩玩。哎,就是没有腾讯QQ,其他的QQ用起来不爽,所以暂时还不能换到linux。我在网上主要就是用QQ,很多功能在luma中没有。

在网上找到的资料中看,的确启动速度加快:

Ubuntu 6.10 的第三个 Alpha 版——Edgy Eft Knot 3 现已发布。与以往一样,本次发布引入了大量新增特性,其主要亮点如下:

使用 Upstart 替换了原来默认的 init 系统。Upstart 具有设计清爽及使引导过程更加快速的明显优势。



edgy 使用 upstart 代替了 init 。 实际测试大约启动提高了1/4,关机提高了2/3。
dbzhang800
帖子: 3182
注册时间: 2006-03-10 15:10
来自: xi'an China
联系:

#4

帖子 dbzhang800 » 2006-10-20 14:46

啊,难怪我的/sbin 目录下没有 init
jimmin
帖子: 2138
注册时间: 2006-09-24 4:37

#5

帖子 jimmin » 2006-10-30 0:24

我不觉得Ubuntu比XP启动慢,那些滚动条只走两次的改版XP不算,不过最好不要用那些改版XP,不稳定。
hghw1776
帖子: 41
注册时间: 2006-04-03 16:51
来自: 湖南长沙
联系:

#6

帖子 hghw1776 » 2006-10-30 0:47

jimmin 写了:我不觉得Ubuntu比XP启动慢,那些滚动条只走两次的改版XP不算,不过最好不要用那些改版XP,不稳定。
那不适改版,另外也没有不稳定之说
jimmin
帖子: 2138
注册时间: 2006-09-24 4:37

#7

帖子 jimmin » 2006-10-30 1:05

hghw1776 写了:
jimmin 写了:我不觉得Ubuntu比XP启动慢,那些滚动条只走两次的改版XP不算,不过最好不要用那些改版XP,不稳定。
那不适改版,另外也没有不稳定之说
的确是不稳定,而且越用越慢,还有些驱动和软件装不上,比如我的摄像头即使装了驱动也就不能在某些改版用,但在原版XP里就行,反正有一大堆不确定因素,刚装上时看着没什么区别,用长了就容易出问题。
hghw1776
帖子: 41
注册时间: 2006-04-03 16:51
来自: 湖南长沙
联系:

#8

帖子 hghw1776 » 2006-10-31 0:21

jimmin 写了:
hghw1776 写了:
jimmin 写了:我不觉得Ubuntu比XP启动慢,那些滚动条只走两次的改版XP不算,不过最好不要用那些改版XP,不稳定。
那不适改版,另外也没有不稳定之说
的确是不稳定,而且越用越慢,还有些驱动和软件装不上,比如我的摄像头即使装了驱动也就不能在某些改版用,但在原版XP里就行,反正有一大堆不确定因素,刚装上时看着没什么区别,用长了就容易出问题。
减少滚动条的走动次数只是修改了注册表里的一个数值而已,我的xp装好就修改了它,现在一圈半就进系统,但是没有发现驱动和软件装不上的情况

而那个参数你也可以上网查查到底起什么作用,根本和系统没什么关系的
zhangchi100
帖子: 212
注册时间: 2006-11-17 9:53

#9

帖子 zhangchi100 » 2006-11-20 13:18

楼上的你改滚动条只是表面上看过去快了,但是滚动条过后会有比较长的一段黑屏时间,难道你用xp没发现么?而且打开一些软件也会变慢的,这也就是微软不推荐取消预读取功能的原因
回复