If you are using a Linux distribution is Ubuntu, are likely to find find / etc / inittab file on your computer, this is because Ubuntu uses the new init system what is called the upstart.
Developed Upstart reason
Around 2006 or even earlier, Ubuntu developers tried to install Linux on a laptop. During this period, there are some problems found in the art of classic sysvinit: It is not suitable for notebook environments. This prompted programmer Scott James Remnant started to develop upstart.
When the Linux kernel into the 2.6 era, the kernel function has a lot of new updates. The new features make Linux is not only a good server operating system, can also be used for desktop systems, and even embedded devices. It features a desktop or portable device is often restart, but also frequent use of hot-swappable hardware technology. In modern computer systems, hardware range, limited interfaces, people are not always all devices connected to the computer, such as U disk usually not connected to the computer, insert the USB connector when it is used. Therefore, when the system is powered on, some of the peripherals may not be connected. But time after startup when required to connect these devices. In the 2.6 kernel support, once the new peripherals connected to the system, the kernel will be able to find them automatically in real time, and initialize these devices, and then use them. This provides great flexibility for portable device users.
But these characteristics sysvinit poses some challenges. When the system is initialized, the device needs to be initialized and is not connected to the system; such as printers. In order to manage the print job, the system needs to start CUPS and other services, and the next if the printer is not connected to the system, the launch of these services is wasted. Sysvinit no way to deal with such demand, it must all at once are likely to use the service to start up, even if the printer is not connected to the system, CUPS service must also be started.
As well as network shared disk mount problems. In the / etc / fstab, you can specify the system to automatically mount a network drive, such as NFS, or iSCSI devices. It can be seen in the first part of this article sysvinit introduction, sysvinit analysis / etc / fstab to mount file systems this step is before the network starts. But if the network does not start, NFS or iSCSI are inaccessible, of course, can not mount operation. Sysvinit use netdev way to solve this problem, namely / etc / fstab found netdev attribute mount point, do not try to mount it in the network can be initialized and after, there is a special service to mount all these netfs network drive. This is a remedy of last resort, to the administrator inconvenience. Part Newbie Administrator never even heard of netdev option, so often become a trap system administration.
For these circumstances, Ubuntu developers After evaluating several alternative init system at the time, decided to re-design and development of a new init system, that UpStart. UpStart event-based mechanisms, such as U disk inserted USB interface, udev get kernel notification, we find that this is a new event. UpStart after the event to trigger the perception of waiting tasks, such as handling / etc / fstab mount points exist. With this event-driven mode, upstart perfect solution to new problems caused Plug and Play device.
In addition, the use of event-driven mechanism has also brought some other beneficial changes, such as speeding up boot time. sysvinit runtime synchronization blocked. When a script runs, the script must wait for the follow-up. This means that all the initialization steps are performed in series, and in fact many of the services are not related to each other, can start in parallel, thereby reducing the system's start-up time. In the widely used Linux server era, the system start-up time and perhaps not so important; however, for desktop systems and portable devices, the length of the start-up time of a great impact on the user experience. Besides cloud computing and other new Server-side technologies often require a single device can be started more quickly.
UpStart meet these needs, not only the current desktop Ubuntu uses UpStart, even enterprise-class server-level default RHEL also use UpStart to replace sysvinit as the init system.
UpStart sysvinit solve the shortcomings of the previously mentioned. Event-driven model, UpStart can:
Faster system start
When new hardware is found and dynamic start service
Dynamic stop service hardware is unplugged
These features make UpStart can be well used in a desktop or portable systems, these systems handle dynamic hardware swap properties.
Upstart concepts and terminology
Upstart clear basic concept and design. The main concept is UpStart job and event. Job is a unit of work to complete a job, such as starting a background service, or run a configuration commands. Each Job is waiting for one or more events, once the incident, upstart to trigger the job to complete the work.
Job is a unit of work, a task or a service. Sysvinit can be understood as a service script. There are three types of work:
task job within a certain time on behalf of completed tasks, such as deleting a file;
service job on behalf of the background processes and services, such as apache httpd. Here the process is generally not quit once you start to run it as a background daemons, by the init process management, if such a process exits, by the init process is restarted, they can only send a signal to stop by the init process. They are generally due to the stop depends stop event triggers, but upstart also provides a command line tool that allows management personnel to manually stop a service;
Abstract job used only by internal upstart, only to understand the internal mechanism upstart help. We do not care about it.
In addition to the above classification, there is another job (Job) classification. Upstart not only can be used to initialize the service of the whole system, but also for each user session (session) initialization services. System initialization tasks is called system job, such as file system mount task is a system job; initialization service user session called session job.
Upstart for each work maintains a life cycle. In general, the work began, and the end of the operation in several states. In order to describe the change finer work, Upstart also introduces a number of other states. For example, start there before the start (pre-start), is about to begin (starting) and has already begun (started) in several different states, so you can more accurately describe the current status of the job.
Working from some initial state, gradually changes, perhaps through several other different states and eventually into another state, forming a state machine. In this process, when the status of the job is about to change, init process will receive a corresponding event (event).
Job status table may 1.Upstart
State name Meaning
Waiting initial state
Starting Job is about to begin
pre-start the implementation of pre-start section, that should be completed before the task starts work
Spawned ready to execute script or exec segment
post-start the implementation of post-start operation
Running interim state set after post-start section processed denoting job is running (But it may have no associated PID!)
pre-stop implementation of pre-stop segment
Stopping interim state set after pre-stop section processed
Killed task is about to be stopped
post-stop implementation of post-stop segment
There are four state will cause init process to send the corresponding event, show a corresponding change in the job:
The other change in state does not issue an event. So we are going to take a look at it in detail the meaning of the event.
As the name suggests, Event is an event. Event notification message to the upstart in the form of concrete existence. Once an event has occurred, Upstart sends a message to the entire system. There is no other means to prevent the event message is part of the upstart known, that is, once the event occurs, the entire system all work upstart and other events will be notified.
Event can be divided into three categories: signal, methods or hooks.
Signal event is non-blocking, asynchronous. Control returns immediately after sending a signal.
Methods event is blocked, synchronized.
Hooks event is blocked, synchronized. It ranged between Signals and Methods, the calls made process Hooks event must wait for an event to complete before they can get control, but does not check whether the event was successful.
Event is a very abstract concept, I set out below some common event, I hope to help you learn more about the meaning of the event:
The system is powered on, init process will send "start" event
When the root file system can be written, the file system will send the appropriate job-ready event
A block device was found and the initialization is complete, sends the corresponding event
A file system is mounted, sends the corresponding event
Similar atd and cron, you can send the event at the time point a point in time or period
Also beginning or end of a job, it sends the corresponding event
A disk file is modified, you can issue the corresponding event
When a network device is found, it can receive a corresponding event
When the default route is added or deleted, the corresponding event can be issued
Different Linux distributions have different customized for upstart and implementation, implementation and support of events are different, you can use man 7 upstart-events to view the event list.
Interaction of Job and Event
Upstart is triggered by an event of a system job to run, run each program by its dependence event triggered.
System initialization process is working in collaboration with each other and events completed, can be broadly described as follows: When the system initialization, init process is run, init process itself emits different events, these initial events will trigger some work operation. Each work will be released during the operation of the different events that in turn trigger a new job to run. And so forth, until the entire system is up and running.
Exactly which events will trigger a run to work? This is defined by the working profile.
Any work is done by a working configuration file (Job Configuration File) definition. This file is a text file that contains one or more sections (stanza). Each section is a complete definition module defines one aspect of the work, such as the author section defines the work of the author. Working configuration files are stored in / etc / init below, as the file extension is .conf files.
Listing 1. A simple job profile
#This Is a simple demo of Job Configure file
#This Line is comment, start with #
#Stanza 1, The author
#Stanza 2, Description
description "This job only has author and description, so nouse, just a demo"
The above example will not have any effect, a real job configuration file contains many sections, the more important sections are the following:
Upstart addition to the boot process is responsible for the system, and as SysVinit, Upstart provides a range of management tools. When the system starts, the administrator may also need to perform maintenance and adjustments, such as start or stop a system service. Or switched to other working conditions, such as changing the run level. This article will detail the use Upstart subsequent management tools.
To start, stop, restart and query a system service. Upstart need to track the service corresponding to the process. For example, the process of service httpd PID 1000. When users need to query httpd service is running normally, Upstart can use ps command to query the process 1000, if it is operating normally, it indicates that service is normal. When users need to stop the httpd service, Upstart to terminate the process using the kill command. To this end, Upstart must keep track of the process number of the service process.
Some of the services in order to process into their own background daemons (daemon), will use the two-derived (fork) technology, other services do not. If a service is derived twice, UpStart must be derived from the second process ID as PID services. However, UpStart itself can not determine whether the service process will derive twice, for working in the definition of the service configuration file must specify the expect section, UpStart tell whether the process will derive twice.
Expect two, "expect fork" means that the process will fork once; "expect daemonize" means that the process will fork twice.
"Exec" Stanza and "script" Stanza
What a UpStart work must be done, you may be running a shell command, or run a script. Use the command "exec" key configuration work needs to be run; the script with "script" keyword defines the need to run.
Listing 2 shows the script and exec Usage:
Listing examples 2.script
description "Mount filesystems on boot"
start on startup
stop on starting rcS
[-f / Forcefsck] && force_fsck = "- force-fsck"
[ "$ FSCKFIX" = "yes"] && fsck_fix = "- fsck-fix"
exec mountall -daemon $ force_fsck $ fsck_fix
This is an example mountall, which work when the system up and running, is responsible for all mounted file systems. The work requires the implementation of complex scripts, defined by the "script" keyword; in the script, use the exec command to execute mountall.
"Start on" Stanza and "stop on" Stanza
"Start on" defines all event triggers work. "Start on" syntax is very simple, as follows:
start on EVENT [[KEY =] VALUE] ... [and | or ...]
EVENT indicates the name of the event, you can specify multiple events start on, it indicates the beginning of the work relies on multiple events occur. Between multiple events can be and or or in combination, "represents all must occur" or "one of them happened to" the different dependencies. In addition to events outside of work can also start it relies on specific conditions, after the start on the EVENT, KEY = VALUE can be used to indicate the additional conditions, the general is an environment variable (KEY) and a specific value (VALUE) Compare. If the order is only one variable or variables are known, the KEY can be omitted.
"Stop on" and "start on" is very similar, but the work is to define under what circumstances need to stop.
Listing 3 is a "start on" an example and "stop on" the.
Listing 3. start on / stop on the example
description "D-Bus system message bus"
start on local-filesystems
stop on deconfiguring-networking
D-Bus is a message service system, the above profile indicates that the starting D-Bus when the system is local-filesystems events emitted; when the system sends deconfiguring-networking event, stop D-Bus service.
UpStart also be used to initialize manage user sessions. As I write this article today, most Linux distributions have not used UpStart management sessions. Only in Ubuntu Raring version, use the initialization process UpStart manage user sessions.
First, let us look at the concept of Session. Session is a user session, the user login to the system from a remote or local start working until the user exits. This whole process would constitute a session.
Each user's habits and methods of use are not the same, so users often need for their own sessions to make a customized, such as adding a specific command aliases, start a particular application or service, and so on. These efforts are part of the initialization operation for a particular session, it can be called Session Init.
Linux can use two modes: character mode and graphical interfaces. In character mode, session initiation relatively simple. Shell can only start after a user logs on, by using the system command shell. Various shell programs support a startup scripts run automatically, such as ~ / .bashrc. User added custom commands that need to run these scripts. Character session demand simple, so that existing mechanisms work well.
In a graphical interface, things get complicated. After the user logs on to see is not a shell prompt, but a desktop. A complete desktop environment made up of many components.
A desktop environment including window manager, panel and some other definitions in / usr / share / gnome-session / sessions / following basic components; There are also some secondary applications together to help form a complete and convenient desktop, such as system monitors, panel applets, NetworkManager, Bluetooth, printers and so on. When the user logs on, these components need to be initialized, this process could be much more complex character interface. Currently initiate various graphical components and applications done by gnome-session. As follows:
In Ubuntu, for example, when a user logs on Ubuntu graphical interface, display manager (Display Manager) lightDM start Xsession. Xsession then start the gnome-session, gnome-session responsible for other initialization, and then began a desktop session.
Traditional desktop session startup process
- Lightdm --- session-child
- Gnome-session --session = ubuntu
- Dbus-daemon --session
This process has some drawbacks (and sysVInit similar). Some applications and components is not required in the session initialization process starts, the better option is to start when it needs them. For example, update-notifier service that constantly monitor several file system path, once discovered can update packages on these paths, to remind the user. The file system path includes the newly inserted DVD disc and the like. Update-notifier started by gnome-session and has been running, in most cases, the user will not insert a new DVD, this time update-notifier service has been running and consuming system resources in the background. Better mode when the user inserts the DVD when you run update-notifier. This can speed up the startup time and reduce the cost of the system is running in memory and other system resources. For mobile, embedded and other equipment, etc. It also means power. In addition to the Update-notifier service, there are other similar services. For example, Network Manager, users rarely a day switching network equipment, so most of the time Network Manager service is just a waste of system resources; another example, backup manager, and other memory-resident, non-stop operation background is rarely actually used services .
With the event-based pattern of demand started UpStart can solve these problems, such as the user plugs in the network cable when it starts Network Manager, as users plug the network cable indicates the need to use the network, which can be called demand-start.
Upstart uses the Desktop session init process
- Lightdm --- session-child
- Session-init # < - upstart running as normal user
- Dbus-daemon --session
- Gnome-session --session = ubuntu
There are two people need to understand the use of Upstart. The first is the system developers, such as MySQL developers. They need to know how to write a job profile to be used UpStart management services. Such as start and stop MySQL service.
Another case is the system administrator, they need to know Upstart administrative commands to configure and manage the system initialization, system management services.
System developers need to understand the knowledge of UpStart
System developers need to master not only the wording of job profiles, but also need to understand some of the requirements for service on the process of programming. This article lists only a small number of grammar work profile. To fully grasp the work of writing the configuration file, you need to read the manual Upstart. Here, let us analyze how to achieve the traditional Upstart run level, and then learn how to use flexible work profile.
Upstart system run level
Upstart operation is entirely based on work and events. Status of the job changes and running will cause event, which triggers work and other events.
The traditional Linux system initialization is based on the operating level, namely SysVInit. For historical reasons, most of the software on Linux or using the traditional SysVInit script startup mode, and not the development of new startup script UpStart, so even on Debian and Ubuntu systems, or must simulate the old SysVInit run level model, in order to and is compatible with most existing software.
While Upstart itself does not run the conceptual level, but it can be simulated with UpStart work. Let's look at a complete system startup UpStart mechanism.
The system startup process
GRUB loaded into the kernel running on the system after power. Kernel performs hardware initialization and kernel initialize itself. In the last kernel initialization, the kernel starts the init process pid 1, that UpStart process.
Upstart process after execution of some of its initialization, immediately issued a "startup" event. The figure above plus red arrow red box represents an event, you can see the "startup" event at the top left.
All depends on the "startup" event is triggered work, the most important thing is mountall. After mountall mandate to mount the system file systems need to use to complete the corresponding work, mountall task will issue the following event: local-filesystem, virtual-filesystem, all-swaps,
Wherein the virtual-filesystem udev event-triggered task to work. Task udev trigger upstart-udev-bridge work. Upstart-udev-bridge will issue a net-device-up IFACE = lo event, it represents the local loopback IP network is ready. Meanwhile, Task mountall to continue, and eventually get a filesystem events.
In this case, the task rc-sysinit will be triggered, since rc-sysinit the start on the following conditions:
start on filesystem and net-device-up IFACE = lo
Task rc-sysinit calling telinit. Telinit task will be issued runlevel events trigger the execution /etc/init/rc.conf.
rc.conf execute all scripts /etc/rc$.d/ directory, and SysVInit very similar, the reader can refer to the description of the first part of this article.
Matters program development Note
As a developer, when in the preparation of system services, you need to understand some of the special requirements of UpStart. Only software that meets these requirements can be UpStart management.
Rule number one, the derived number of times it should be declared.
Many Linux background services are derived by the two techniques will become daemons themselves. If you write a service also used this technique, it is necessary to explicitly allow the document or by some other way UpStart maintenance personnel know this, which will affect expect stanza UpStart, we have been described in detail in front of this stanza meaning.
Rule number two, after the derived available.
Daemon in the completion of the second derivative of the time, we must ensure that the service is already available. Because UpStart derived by counting to determine whether the service is in the ready state.
Rule number three, to comply with the requirements of SIGHUP.
UpStart daemons will send SIGHUP signal, at this time, UpStart want the wizard to do the following in response to the work process:
• Complete all necessary re-initialization, such as re-read the configuration file. This is because UpStart command "initctl reload" is designed to allow the service to update the configuration without rebooting.
• daemons must continue to use the existing PID, it can not be called when the fork that is received SIGHUP. If the service must call fork here, it is the equivalent derived twice, referring to a process of the above rules. This rule ensures that UpStart can continue to use PID management of the service.
Rule IV received SIGTEM namely shutdown.
• Upon receipt of the signal SIGTERM, UpStart hope daemons processes now exit cleanly, release all resources. If a process does not quit after receiving SIGTERM signal, Upstart signal it sends SIGKILL.
System administrators need to know Upstart command
As a system administrator, an important duty is to manage system services. For example, monitoring systems and services, start, stop, and configure. UpStart provides a series of commands to accomplish these tasks. The core is initctl, this command is a tape style command-line tool.
For example, you can use initctl list to view all the work before:
$ Initctl list
alsa-mixer-save stop / waiting
avahi-daemon start / running, process 690
mountall-net stop / waiting
rc stop / waiting
rsyslog start / running, process 482
screen-cleanup stop / waiting
tty4 start / running, process 859
udev start / running, process 334
upstart-udev-bridge start / running, process 304
ureadahead-other stop / waiting
This is output on Ubuntu10.10 system, the output of other Linux distributions on different. The first column is the name of the work, such as rsyslog. The second column is the objective of the work; the third column is the status of the job.
In addition you can also stop by initctl stop a running job; start a job with initctl start; initctl status can also be used to check the status of a job; initctl restart to restart a job; initctl reload allows a service running reloading profile. These commands and command is very similar to the traditional service.
Table 2.service command and the command table initctl
Service command UpStart initctl command
service start initctl start
service stop initctl stop
service restart initctl restart
service reload initctl reload
In many cases administrators do not like subcommand style, because too many characters need to be manually typed. UpStart also provides shortcut commands to simplify initctl, in fact these commands only internally calls the appropriate initctl command. For example, reload, restart, start, stop, and so on. Start a service can simply call
start < job>
This execution initctl start < job> is the same effect.
Some commands are for compatibility with other systems (mainly sysvinit), such as display runlevel using / sbin / runlevel command:
This output shows that the current system run level 2. And the system does not run level before, that is on the system is powered on after entering a predetermined level no longer run the modified run level.
So how to modify the default operating system power level after it?
In Upstart system, you need to modify the DEFAULT_RUNLEVEL /etc/init/rc-sysinti.conf this parameter to modify the default startup run level. This and sysvinit habits are different, we need extra attention.
There are some gadgets with UpStart released to help developers UpStart or diagnostic UpStart problems. For example, init-checkconf and upstart-monitor
You can also use the initctl emit command sends an event from the command line.
#initctl emit < event>
This is typically used for debugging UpStart itself.
You can see, UpStart design is more advanced than SysVInit. On most Linux distributions no longer used SysVInit, part of the distribution used UpStart, such as Ubuntu; while others, such as Fedora, using what is called systemd init system is. Systemd appears UpStart than later but the rapid development, although UpStart is also still actively developing and more and more applications, but systemd seems to develop faster, I will be the next article will introduce systemd.