Y'herd thisun? 

“Seen the funny and GREAT movie "the Big Dish?" Heading to Cali for a vaca? You have to visit the Goldstone array complex. Check this to see why”

from Visit to Goldstone by Smith

MONO/Ubuntu part 18 - Ubuntu Services and Service Managers


By this point in our tutorial your fingers are probably pretty quick at controlling a a service during a session via the /etc/init.d/[program] stop|start|etc. or the more readable service [program] stop|start|etc., but what about forcing a service to load or not at bootup? For example, you know that you can stop Apache at any time with "sudo /etc/init.d/apache2 stop" but when you restart the machine Apache is going to load again. For most services there is no init.d option for making a service stay dead.

To just get it done without caring the why, do this:

1) Determine what run level your machine is running in with either who -r or runlevel. 999 times out of a thousand an Ubuntu box will be in run level 2 but it's best to check.

2) Install sysv-rc-conf, if you haven't already.

3) Call up "sudo sysv-rc-conf" and use your arrow keys to scroll to the service you want to change. In this example, we're showing Oracle Express.

CAREFUL, this applet can use your mouse and it's very easy to click the wrong places, it is recommended to not touch your mouse and just use your arrow keys.

4) Use your arrow keys to scroll horizontally over to the column matching the run level value from step 1 and tap your space bar to toggle the checked box off.

Press the "q" key to exit the app.

FYI: The instructions at the top of the screen about stopping a service with the minus key or stopping one with the plus key are only about an immediate stop/start, not about altering the bootup. If you use those options don't be surprised if it takes several seconds for a confirmation prompt to appear. There is NO confirmation prompt for changes you make to the bootup "check boxes", your settings are just applied when you exit the app.

5) sudo reboot your machine and verify that the service wasn't started using sudo /etc/init.d/[service name] status.

To set the service to start on boot, repeat the process but check the little box instead.

To understand what the heck you just did... read on.

Linux Services for Windows Professionals

You're no one at the watercooler these days if you haven't got a story about using the Windows Powershell commands for XPSP2/WS2003SP1 and higher :-). Out of the box though, Windows gives you three long-trusted and powerFULL ways to manage services and driver loading: the Net command (net start|stop [service name]), the "Service Controller" command (sc start|stop|query|config|etc. [options]) and the graphical MMC Services snapin.

For all the good fun of the commandline options, the snapin's probably still the most used by developers. Just start it with the terminal call service.msc (or clicking your way through the Control Panel), scroll through the list, right click on the service you want to control, click on Properties and the keys to the kingdom are laid out before you. A button press turns a service on or off for the current session and a choice from the "Startup type" dropdown sets any service to run or not when the machine starts up.

Services on textmode Linux Ubuntu server aren't so user-simple out of the box.

There are some optional tools to get the job done on Linux, some "ui" and some command line. Unfortunately not all of them work on Ubuntu and, as you saw in the "just do this" beginning of this page, to make sure you're doing what you want even the easy ones require having a bit of knowlege of 'nix at a lower level. The system isn't that bad once you "get it", but it is hard to find good writeups that explain it in a manner that a Windows pro can take to town. So let's see if our attempt here will fill that gap.

Linux Run Levels

Googling for information on Linux services brings up a whole mass of pages that tell you about the eight to twelve 'nix "Run Levels". You'll read that run level "S" is for core OS Services, that run level 0 is "Halt", that 1 is single user mode, 2 is multiuser mode and may or may not be the default mode, that 3 and 4 may or may not be the same as 2, that 5 may or may not be graphical UI mode, that 6 is "Reboot to normal" and that some flavors may also have even more numbers that may or may not be useable. Ooooo-kay.

If your experience is like ours, you get a face full of advice that will surely help once you understand about Run Levels, but no flat-out explanation of what the heck a run level IS.

Here's the deal in Windows parlance: You know what Safe Mode is right? Well, that's a "run level". As a matter of fact, safe mode is optionally several different run levels. When you hose a low level driver install or manually restart an XP/Vista/2000 Winbox while holding down the F8 key Windows offers you a handful of modes that you can use to get into your machine with limited drivers/services loaded up. The optional "sub modes" are: basic graphical safe mode with a standard low-resolution VGA driver and no networking, low res graphical with networking, low res mode where you have to approve the loading of each driver and service as they come up in the boot order or even a text mode boot and last known good full configuration.

There it is, the key to unlock the run level concept for Windows people. Each of those safemode options, and the option of just starting your machine normally with all drivers and automatic services loaded, are essentially "run levels".

In Windows dealing with run levels isn't a routine requirement, we only need to do it when we accidentally goof on the choice of some driver download (usually a video card driver). In Linux, getting the gist of run levels is essential if you need or want to correctly change service startups.

In a highlevel nutshell, how Linux starts

When most 'nix machines start they call the "init" program that you see in your top and htop lists to start all of the absolutely required core services, then the currently specified run level is determined and that value is used to start just the services that that specific level needs.

Those "optional" services are started using sequence-named symbolic links to script files saved to subfolders of /etc/ that are named in relation to the run level. Ahem. It's easier if you see it, so here's a sample list of all of the run level script folders and the script files they contain:

As you see, the /etc/ folder has folders named rc0.d through rc6.d (the number being the run level) plus a special rcS for the core OS services. Inside each folder are a set of script files starting with either a "K" or an "S" followed by a two digit number and the friendly name of the specific service.

Note for purists: The "files" are not really "files", they're symbolic links to real files, sort of like Windows shortcuts. Generally you can treat them like files so we'll call them files for simplicity.

The "K" files are services to be Killed/stopped in that run level and the "S" files are services to be Started in that run level. The two digit numbers are the relative sequence ids for the starting or killing of the service... the boot order, if you will. So as an example we see in the folder for run level 2 (/etc/rc2.d/) that the apache2 service will be started at sequence number 91, so it will start after all S files of lower value (dbus message service at 12, ssh at 16, etc.) and before rc.local which is at sequence number 99.

fyi: 99 is a good number to keep rc.local set to. rc.local is sort of like the Windows Startup folder, a shortcut to making programs automatically run without having to actually create a real service script. Just like using the Windows Startup folder you have to be careful because while the programs/commands will run their processes might not gracefully exit when you reboot your box.


Starting to make sense? Are you thinking that setting a service to start or not at bootup or rearrange the boot order of a service is as simple as changing the file name in the correct run level folder? Good, because, technically, you're right.

In each of the folders there is a README text file, it's a short message about the correct way to rename a service file and its main point is that just changing the starting letter isn't enough. You have to also change the two digit number in the file name to be 100 minus the current value, so the S91apache2 file is supposed to be renamed K09apache2. Make sense by the logic that the digits are processing sequence ids, and if a service is supposed to start only after things it depends on are already started then the sequence for killing it should be reversed so that it can end gracefullly with the help of any services that it uses (rather than killing those dependency services first and having the main app crash when it tries to call on them in its shutdown).

Obligatory Linux caveatus:

Yep, it makes sense but it's not a hard and fast rule. When you use a good ui tool to change the apache2 service startup it will switch between 09 and 91 but Oracle Express and some others from big and small developers won't; using a tool to shut off the oracle-xe service will change the file name from S20oracle-xe to K20oracle-xe. Which brings up another matter... the sequence digits don't appear to have to be unique because you see that there's both the S20oracle-xe and the S20rsync (the remote IO service, similar to using scp). Oracle's a pretty major player so you'd think their install would do something about the conflict if it was a big deal AND that their system would correctly rename the digits from 20 to 80 and back but it doesn't happen.

Why? Because Debian (the parent of Ubuntu) has a bug in its service-creator command update-rc.d that's been around so long that fixing it now would "confuse some users".

The fact that it confuses ALL New users who read the README file and are trying to do Linux correctly is apparently not important.

Obligatory Linux caveatus Ubuntu caveatum:

It's interesting that the July 2003 bug response from has the line "it would be a lot of trouble for only aesthetic benefit. The ugliness will go away if and when the sysv boot system is replaced by something better."

That was written six years ago. Since then Ubuntu HAS moved away from System-V to the event-based Upstart System. And the same bug remains.

Bug becomes bad habit, bad habit becomes dogma, just like case-sensitivity. Next time a granola head puts down Windows for bloating arcana, ask them about update-rc.d ;-).






Which run level to change?

Looking up at that list of run level folders you see that levels 2 through 5 (rc2.d - rc5.d) are exactly the same. So if you want to change a service boot setting do you have to alter all of them? It depends.

The concept of run levels as separate profiles (groupings of services) that can be called up without having to make individual changes and reboot is a nice one, it can save time for developers while they're working on service level code or geeks on desktop distros who'd rather go full screen text instead of opening up a terminal window. But for most users, even advanced admins, it's not a daily helper and all of those folders and symbolic links are overkill. So Ubuntu, being the distro targetted at the real-world masses doesn't default to supporting run levels like other Linux products.

In Ubuntu, there is no rule that run level 2 is textmode only and that 5 is only for a GUI (GNOME or KDE) interface or that 3 and 4 are only for custom profiles. In Ubuntu, level 2 is the default for all. In fact, the startup scripts in Ubuntu are written to look for files that it knows aren't typically even on the machine and then just force the run level to 2.

Wanna see proof? Use the "sudo telinit 3" to force your current session to use run level 3. Test that it worked with the "who -r" command. Now reboot and ask again. On some other Linux variants you'd see that you started in the newly specified run level but on most all Ubuntu machines you'll start right back on level 2 (for the caveat, see the next section).

So why still even have the other folders? It seems to be Debian tradition and interoperability (update-rc.d, called by many 3rd party installers is built to install service links in all of the folders so they have to be there). Bottom line is that for most installations you can ignore all but rc2.d

What if you do want to change run level?

We just mentioned the "sudo telinit [level number]" command and the fact that using it to change run levels doesn't stick. That is perfectly fine for the vast majority of machines and users.

If for some reason changing the service startup link in rc2.d isn't good enough and you really do want to make some other run level sticky in Ubuntu there are a few different ways, the easiest is to add a text file named "inittab" to the /etc/ folder.

Older system-V based distros run the "init" function when the machine starts and "init" calls on settings in the file "/etc/inittab" file. The accepted thinking is that System-V has not kept up with hardware evolutions and has issues with hotswaps, plug&plays, flash drives and other "new" stuff so some distros have been trying alternative systems; Apple uses "launchd", Solaris uses SMF, there're others such as sysvinit and initng ... and Canonical decided to make a newer event-based startup system called Upstart. Upstart doesn't technically use the "inittab" file and instead uses the /etc/event.d/rc-default" file. However, when Ubuntu starts it is coded to still look for the System-V "/etc/inittab" file and it will use it if it finds it, so all you have to do is use nano to create that text file and inside it add this line:


Don't forget the trailing colon.

The number, in this case "4", is the run level to start up in. Save the file and restart your machine, then verify that you did change the default run level with a quick call to "who -r"

Honestly, I still don't get why sticking with run level 2 is the big bad thing that some geeks with blogs make it out to be. They rant and rage while real-world use points to a single primary run level being fine (so long as you have access to run level 1 to get the same abilities as Windows safemode). Whatever. If you find an important reason to use another level, you now know how to get it.

Enough with the text files and theoreticals, let's move on to getting practical work done with the tools for changing service startups in the run levels.


Ask Google about "configure linux services startup" and the top results will tell you about chkconfig.

This optional commandline tool seems to be the beloved biggie with docs and tipsites showing it listing service settings and altering them for starting or stopping at boot by run level. Problem is that only one of the options seems to work in Ubuntu, that being the namesake option of it "checking" the service configuration.

Below is a shot of the result of calling sudo chkconfig --list |less

That's very nice, you can see the startup settings for all of the run levels of the installed services so you don't have to list the contents /etc/rc*.d folders. However, calling the tool to switch off a run level boot doesn't work out so well.

So maybe it's not so great for Ubuntu after all :(.

If you want to test it out for yourself, just install it with:

sudo aptitude install chkconfig

Oh, one other thing chkconfig currently has a dependency conflict with sysvconfig.


Long as we mentioned it, might as well explain it ;-). Install this pretty gui applet with the logical:

sudo aptitude install sysvconfig

Note: If you previously installed chkconfig, you'll be alerted to the dependency conflict and prompted to have the installer remove chkconfig.

Now just type "sudo sysvconfig" and voila!


Use the highlighted hotkeys or your arrow keys (or mouse if it's enabled, but keys are safer) to pick an option off of this main screen and press Enter to go into that sub mode.

Here's the first option, a scrollable list of all the services on your machine. Hotkey or arrow to the service you want and use your spacebar to check or uncheck the startup option. CAREFUL: if you chose to use your mouse, remember that clicking on a service row will not only select that row but also toggle the startup setting, this mousey helpfulness can lead to accidents so it's recommended to use your keys instead.

When you're done toggling the startup settings you want, press enter to exit the screen. If you made any changes, the main screen will have the new option "Finished - Finish and Save files", you can chose that to lock in your alterations or use the "Quit" option and on closing the tool will prompt you to confirm that you want to save changes. Nice & safe.

That option didn't ask you anything about run levels... did it pick the right one? Yes, maybe. Do a full list of all the /etc/rc*.d folders OR open up the applet again and use the "Edit - Edit runlevels" option to view all the services and all of their run level settings.

Scroll down to the one you want to check and look at the Kill/Start values (If you have a lot of services "scrolling" can be tedious because the up/down arrow keys roll left to right then down). You'll see that using the other screen to quickly toggle a service startmode toggled the startmode in all of the multiuser levels (2 -5). This follows the Ubuntu service installation logic of 2 being the default and the rest all being disk-wasting mirrors.

So if you've got the need to jump between run levels in sessions with particular services running in each then you'll have to use this "Edit runlevels" screen and manually (and correctly) change the K/S[sequence digits] values in each run level box.

sysvconfig is probably the prettiest of all the tools. Are there uglier ones that do the job as well or even easier? Let's see.


As previously mentioned the Debian/Ubuntu update-rc.d command is used to install new services on your machines (and it has a bug that sets all new services to sequence number 20). This command was not designed to be used by humans but occasionally you'll come across tipsites that say it's the tool to use.

Whether it's right for you depends on what you mean by shutting off a service in a run level. update-rc.d WILL make a service "stop" and it does it by removing the symbolic link "files" for the service in the /etc/rc*.d/ folders. If a file doesn't exist then it won't start. That may not be what you want.

If it is, then you can get rid of a service from all run levels by using the command as in this example.

List the files in the /etc/rc*.d/ folders and you'll see that the service in question is no longer there.

To put all of the link files back the way they were when the service was installed, change the "remove" option with the word "defaults". Notice in this example that there's a warning about oracle-xe missing the "LSB header", that's a common issue with service scripts that Debian techs tell developers how to fix and tell end-users that developers not doing things right is not a big deal to worry about.

The command allows more fine grained control if you want to specify the starts and kills per run level. To use that option on a service that is already in the rc*.d folders, you first have to call the remove line to get rid of any existing link files then make the new files you want using this exact format (including the little dots)

sudo update-rc.d [service name] start [sequence id] [space separated run levels] . . stop [sequence id] [space separated run levels] .

Here's an example of the steps for changing the oracle express service to have start files in run level 3 and 4 and stop/kill files in run levels 0, 1, 6 and S:

Listing the /etc/rc*.d/ folders for the oracle service shows that Kill and Start links were installed in the specified run levels. In this example, rc2.d does not have a link because our command did not have a "2" in the start or stop lists.

update-rc.d does work but it's highly invasive and convoluted. May want to follow the recommendation of letting robot installers use it but keeping human fingers away.


This guy is noob-simple. Install it with the logical:

sudo aptitude install rcconf

And call it up with its name.

sudo rcconf

Mmmmm, easy. Why do so many people say to not use this cutie?

rcconf is just a simple Enable/Disable screen like the one in sysvconfig and logically it works the same way. You scroll to the service in question and use your spacebar to toggle the asterisk, then tab to <Ok> and press Enter. All of the standard multiuser run level files are renamed to match the new startmode (and defined sequence digits are correctly altered - if they aren't "20").

Here's a minor useage thing. After disabling a service, call up rcconf again and search for it...

Where's the oracle-xe? Keep scrolling and eventually you'll find it. Resetting a service screws up the initial alpha ordering of the list. Yep, that's all.

That little weirdness alone has made some tipsters vehemently advise you to never use rcconf. I've read them, and for a while I believed them... they and I didn't keep scrolling and instead assumed that once a service boot was turned off it was gone from the list. So now you know that that isn't the reason to be wary of this tool.

The reason to be wary is something else. Look closely at the screen after you close rcconf and you'll see it throwing some Perl errors:

Early on, I only used rcconf and never saw this issue. Then I started seeing it and it wouldn't go away. Then I started hitting it right off the bat on newly built machines. Once I even took the time to "fix" it, at least I made the error go away. No, sorry, I don't remember how and honestly I don't care any more.

rcconf is simple but weird errors on the top make me worry about stuff under the hood. Besides, once run levels are understood, using a slightly more geeky tool that doesn't throw errors makes me feel more comfortable. I know that's not scientific, just because you don't see an error doesn't mean it's not there, but I'm human. Are you the same way? Then maybe you'll like sysv-rc-conf.


And here we are back at the beginning. Now that you have the gist of 'nix Run Levels and've seen some of the major service tools you see why we started this page with the "just do it" of sysv-rc-conf.

  • It's less dangerous than update-rc.d
  • It works where chkconfig doesn't
  • It's not as pretty as sysvconfig but gives you finer control than the sysvconfig all-on/all-off screen
  • Scrolling down the list of services isn't as tedious as the sysvconfig run levels screen and you just have to check/uncheck instead of typing the K/S[digit] values.
  • rcconf is more colorful and a lot simpler but it's got some scary output. And the general consensus from smarter people than me is that it's got deeper problems.

So do yourself a favor:

sudo aptitude install sysv-rc-conf

Hope that helps.


Up next: Installing Oracle XE 10g

jump to:

  • 1: Why?
  • 2: Installation
  • 3: Update the OS with APT
  • 4: Remoting to the box with SSH
  • 5: NANO quickies for 95% of the jobs
  • 6: Firewalling Ubuntu 8.10 Server
  • 7: Installing Apache2 and MONO
  • 8: Test client host files
  • 9: Configure MONO on Apache2
  • 10: Apache default pages
  • 11: Handling Apache and Mono Errors
  • 12: Subdomains and Christian porn
  • 13: Virtual Host Tweak: unmanaged cAse sensitiviTy
  • 14: Managed cAse sensitiviTy
  • 15: Managing files and folders
  • 16: Logging Apache Accesses and Errors
  • 17: Ubuntu Task Managers
  • 18: Ubuntu Services and Service Managers
  • 19: Installing Oracle 10g XE Server
  • 20: Connecting Mono to Oracle

  • home     who is smith    contact smith     rss feed π
    Since 1997 a place for my stuff, and it if helps you too then all the better