Adding System Services with Upstart

We took a look at upstart more than half a year ago, and at that point it was only beginning to emerge. In Ubuntu 7.10 and beyond, we are beginning to see the result of what eventually will be a complete replacement for System V. Since we'll be seeing more of upstart in future Ubuntu versions, in Fedora 9, and other distributions, let's take a look at how to make and manage Upstart jobs.

Note: Assume commands are prefixed with sudo if you are not root.

Before jumping into upstart, let's take a quick look at a common configuration of a SysV-style system. Most boot scripts are stored in /etc/init.d. There you will find many scripts for getting your system running. But, they don't actually do anything just sitting in there. You have to activate them into runlevels.

A runlevel is a state of the boot process that tells your system which programs to start, and which to stop. Usually when your computer boots, it will enter a runlevel anywhere between 2 to 5. (If you're anxious to know, run the command runlevel in a terminal.) While you are using your computer, it will usually stay at this level. However, once you reboot, runlevel 6 is entered, which tells most processes to prepare for shutdown and reboot the system. Runlevel 0 is similar, except the system is turned off instead of restarted. The only other notable level is 1, which in most cases is recovery, or single-user, mode.

rcd-context.png

Back to System V: The init.d scripts from above are linked to directories named /etc/rc#.d, where # is the runlevel being entered. These directories are usually full of different scripts, but they all link back to /etc/init.d. The style of them is beyond the scope of this tutorial, but know that upstart is still backwards-compatible with these should you have to use them.

Let's move on. cd to /etc/event.d and have a look at the files in there. You will most likely see a bunch of files that look similar to the rc# directories; these exist for backwards compatibility. You will also see some files like tty0 and tty1, which is what we will be working on.

upstart-eventd.png

If you have an Ubuntu server, most likely you will only have a tty0 file. In many situations, this is not a problem. Tty0 is the main console front-end used only for accessing your server or computer from a physical location. (On a desktop, tty7 is the X display, and all of the others are accessed with Ctrl+Alt+F#. Also note SSH connections are not affected by the amount of tty's available.) However, some web hosts have the option of a recovery console which might run on another terminal interface.

To enable another virtual terminal, such as tty1, in the SysV system, you would probably add a /etc/init.d script to start tty1. Sure, you can still do that, but why would you when you have upstart?

Let's make a new file called /etc/event.d/tty1. Don't make it executable, just write a plain text file. Now, throw this into it:

start on runlevel 2
start on runlevel 3
start on runlevel 4
start on runlevel 5
stop on shutdown
respawn
exec /sbin/getty 38400 tty1

Wait - that's it?

Yes, yes it is. If you read my introduction on runlevels above, this isn't hard to understand at all. We want tty1 to start on runlevels 2 through 5, and stop when the system is turned off. Respawn simply tells upstart to restart the service if it exits, and the exec line tells it what service to start.

Managing a service is even easier. In many systems, services were started by running something like /etc/init.d/service start. What do we do with upstart?

start tty1
status tty1
stop tty1

You probably don't want to run all of these commands in succession; they are just three separate commands to manage jobs. Start and stop do just that, and status tells you if a job is running.

There you have it - and really, this isn't as long as I made it. It really just involves the two black boxes above: upstart job files, and running the jobs. You don't have to run the jobs by yourself either on startup; upstart does this for you. Obviously there is more to just this if you want more complex options, but if you just want to be able to make and manage jobs, that's it. Enjoy.

Avatar for jacob Jacob Peddicord - http://jacob.peddicord.net/

Jacob is a web developer, student, and programmer from Ohio. He is a staff member at the Ubuntu Forums and is most likely a fanboy of the distribution. He loves to write in code and words, play video games, and rant about topics most would have abandoned long ago. Jacob uses GNOME and is never seen running stable software, much to the demise of his laptop.

Home » Articles »

Discussion: Adding System Services with Upstart

  1. Diego (guest)

    # Posted on 22 February 2008 at 02:32 PM

    What benefits has upstart upon sysv or other inits? I have ubuntu, but it doesn't start too much quick to say that an unstandard process is a good thing.



  2. # Posted on 23 February 2008 at 08:47 AM

    <strong>Story added...</strong>

    This story has been submitted to fsdaily.com! If you think this story should be read by the free software community, come vote it up and discuss it here:

    http://www.fsdaily.com/HighEnd/Adding_System_Services_with_Upstart...



  3. OrcRys (guest)

    # Posted on 23 February 2008 at 10:46 AM

    To Diego:

    Upstart isn't only about rapidity, though it is one of the goals. It is supposed to add a tremendous event-based flexibility to Linux.

    For exemple, on ubuntu, there is an upstart job that interprets a ctrl-alt-del keypress as a shutdown -r now command.

    Upstart is still in development. The transition from sysV has to be smooth.



  4. Diego (guest)

    # Posted on 24 February 2008 at 03:01 AM

    Yep, i see how an event based system can improve flexibility. By i dont trust on ubuntu any more. I have been on ubuntu almost 2 month and it really always have something which requires a lot of unix knowledge becouse of all of its problems and the really really out of date repositories.

    I am seeing with good eyes to Pardus Linux they seem to want to implement what has to be done from the start. A part of Pardus is Murdur, which is mostly like upstart is for ubuntu. But it focuses on threading the start process and it really makes it faster. It is already working and it has by now much more usefullness than upstart. The bad point of Pardus is that it is too much new for now, the repositories are even smaller than ubuntu, but are up to date. And is kde based. I dont know if murdur will try to implement something like an event based job system, but they have taken into account upstart features.



  5. # Posted on 03 March 2008 at 06:37 PM

    [...] An intro to&nbsp;SystemRescue Filed under: Linux, Security &#8212; 0ddn1x @ 2008-03-03 18:37:17 +0000 http://fosswire.com/2008/02/28/systemrescuecd/ [...]



Home » Articles » Adding System Services with Upstart