Home | Hardware | Internet News |Web Hosting |IT Management |Network Storage
LinuxPlanet
Search 
  Power Search | Tips 

 Front Door
 Discussion
 LinuxEngine
 Opinions
 Reports
 Reviews
 Tutorials
 News
 Technology Jobs

 Browse by subject.
Free Newsletter

Java/Open Source Daily
Linux Today
More Free Newsletters

Be a Commerce Partner


















internet.com
IT
Developer
Internet News
Small Business
Personal Technology

Search internet.com
Advertise
Corporate Info
Newsletters
Tech Jobs
E-mail Offers

Print this article
Email this article

   LinuxPlanet / Tutorials







Controlling Ubuntu's and Fedora's Upstart (the init replacement)
Controlling Startup Events

Juliet Kemp
Wednesday, May 13, 2009 02:00:48 PM

In the previous article in this series I looked at how init (the system we've all been using for years to start up our services) works, and how upstart, the new replacement for init, works instead. This article looks at upstart and its scripts in more detail.

Moving over

The first piece of very good news is that it's possible to move from init to upstart without having to shift all of your services at once. There's a default set of example scripts available from the upstart website which includes a job which runs the init scripts. For example, here's the rc3 job:

start on runlevel 3

stop on runlevel

console output
script
        set $(runlevel --set 3 || true)
        if [ "$1" != "unknown" ]; then
            PREVLEVEL=$1
            RUNLEVEL=$2
            export PREVLEVEL RUNLEVEL
        fi

        exec /etc/init.d/rc 3
end script
The first two lines define what events this job should react to, and how it should react. So on the occurrence of a 'runlevel 3' event (probably triggered by the telinit compatability wrapper), the job starts. On the occurrence of any runlevel event, it stops (so in fact a runlevel 3 event will stop it, then start it again – this matches how init works). The script section does the actual work of running the job.

Writing an upstart job

But what about setting up a particular job for yourself? You keep your job definitions in /etc/init/jobs.d, and they should be plain text files, and not executable. Your job needs to have either an exec line:

exec /bin/echo "ping"
giving a path to a binary, and the arguments to pass to it; or a script section, as in the runlevel 3 job description above, which has a shell script to be run with /bin/sh. These define what will be run when the job is triggered. Jobs can be set to respawn with the line:
respawn
There's an automatic limit set to this: if a process is respawned more than 10 times within 5 seconds, it will be stopped and not restarted. You can alter this default with:
respawn limit 20 5
(this would set the limit at 20 times in 5 seconds).

So, we could have a very basic job that looked like this:

start on startup
exec /bin/echo "ping"
which would run that echo line on startup. There's no point in putting a stopping stanza here, as it's not a daemon to start/stop, and similarly no need for respawning.

Next: Scripts Can Run Before or After a Job »

Skip Ahead

1 Controlling Startup Events
2 Scripts Can Run Before or After a Job





Linux is a trademark of Linus Torvalds.


internet.com home | search | help! | about us

Jupiter Online Media

internet.comearthweb.comDevx.commediabistro.comGraphics.com

Search:

Jupitermedia Corporation has two divisions: Jupiterimages and JupiterOnlineMedia

Jupitermedia Corporate Info


Legal Notices, Licensing, Reprints, & Permissions, Privacy Policy.

Web Hosting | Newsletters | Tech Jobs | Shopping | E-mail Offers