It turns out that SysV has not been really taken away, since while there are tasks based on SysV, both systems will have to live together. Indeed, there is a job defined by Upstart and named rc-sysinit.conf, which controls the execution of the existing traditional SysV scripts. An Upstart system runs by default in runlevel 2.
root@ubuntu-server:~# runlevel
N 2
What is the main advantage of Upstart against SysV under my personal opinion? In contradistinction to SysV, Upstart allows to launch the services or tasks (here named jobs) in parallel, that is to say, they have just to wait for certain events happen. For example, when the Upstart init daemon has finished its initialization (upstart), when the filesystem is mounted (filesystem), MySQL daemon is started (started mysqld), and so on.
Let's see how Upstart works. All Upstart jobs are files made up of a well known structure and stored into the /etc/init directory. For example, we are going to develop an easy job to write the date within a tmp file. Its name will be job1.
root@ubuntu-server:~# cat /etc/init/job1.conf
script
date > /tmp/job1.tmp ; sleep 10
end script
One of the ways to start this job is manually.
root@ubuntu-server:~# start job1
job1 start/running, process 1705
If we take a look at its state before 10 sg, we will see which is start/running. Afterwards, it will be stop/waiting, since in this case, it is not a daemon such as httpd, but a process which finishes when completes theirs defined tasks.
root@ubuntu-server:~# status job1
job1 start/running, process 1710
root@ubuntu-server:~# status job1
job1 stop/waiting
Upstart allows to define a job or by a script section (as the previous example - remember that the scripting code will be launch under "sh -e") either using the exec directive.
root@ubuntu-server:~# cat /etc/init/job1.conf
script
exec date > /tmp/job1.tmp
end script
This sort of stanza can be used for instance to run a script or start a daemon like mysqld (zero or more arguments can be passed to it). Other manner to start a job is through an event. For example, we can run our job when job2 or job3 are started.
root@ubuntu-server:~# cat /etc/init/job1.conf
start on started job2 or started job3
...
By default, a job is a service that during its life cycle will be able to pass for different stages: starting, started, stopping and stopped, and in addition, will be able to be respawned if it exits with a zero status.
If we want to specify that the job is a task (it is considered to have finished when it has been run and stopped again - it will terminate with zero status but it will not be able to be respawned), we will have to add the task parameter into the configuration file. Otherwise, Upstart will treat the job as a service.
No comments:
Post a Comment