Unix and Linux startup scripts, Part 3

This is a continuation of Unix and Linux startup scripts, Part 2

So, after being rudely interrupted by a server crash and a few days of website migration, we're ready to continue exploring Unix and Linux startup scripts. We looked at both System V and BSD methods; until fairly recently that would have been the end of the discussion: if you were running Unix/Linux, your system used one or the other of these. Not everyone was satisfied, though

You can see the hints of unhappiness in the script directives that crept in to BSD startup scripts. More fine grained control was needed and neither System V inittab nor the BSD rc scripts provided enough.

Why replace init?

One reason is boot speed. Even when scripts can be run in parallel as in SCO's prc_sync "P" scripts , running mostly serial shell scripts takes time; you and I and everyone else want our systems up NOW. But it's not just that.

if you step back and look at init objectively, it is just a program starter. That was certainly true with the original BSD /etc/rc and inittab only added a bit more complexity. Init is a "starter", but so are inetd /xinetd, at and cron. Why shouldn't init be able to take on some of that work?

There are "event driven" tasks. Today, there are many kinds of hardware we expect to be able to just plug into a running system and be recognized. Usually some program needs to be started up when that happens. Sometimes you want something special to happen when a new file appears in a certain directory, or when some other task finishes or fails - life can be complicated and init, (x)inetd and cron/at don't always match our needs.

Think of some of the things you might want to control for any given script or process:

• Persistency - should this process be restarted when it ends? Does it matter whether it ends normally or abnormally?
  
  
• Runlevel - should this run in single user mode? In the default runlevel?
  
  
• Privilege - what id should this run in?
  
  
• Dependencies - what other tasks must be running or not running?
  
  
• Security - should this be run in a chroot jail? Should it be sandboxed in other ways (no network access, for example)? Should only certain users, remote or local, be allowed to use this service? Start it? Stop it?
  
  
• Resource limits - how many concurrent instances of this process should run? How many times can it fork? How many clients can it have? How much disk space, ram, and so on?
  
  
• Timing - should this be running after working hours?
  
  
• Logging - did the task run and if not, why not?
  
  
• Grouping - there may be several tasks to which we would like to apply identical constraints or privileges
  
  

It's not that you can't have all of that; it's that some of it can be done by inittab, some by (x)inetd, some by cron/at, some by device drivers and some you have to do inside your script or program. It's a hodgepodge of stuff, and that's why there are attempts to replace it all with something more powerful and complete. The the man pages for inittab, cron, at, xinetd, udev and maybe a few others and glom them all together: THAT'S the ideal.

Implementing all that is something else entirely.

Aside from very real dependencies from programs that expect certain directories, certain processes and certain system calls, you also have inertia, developer resistance to seeing their projects replaced, user/administrator/programmer resistance to learning anything new and of course inevitable arguments about how, how much, when - given all that it's surprising that much progress has been made at all. But it has. Fedora and Ubuntu now use Upstart. Mac OS X has Launchd. The path to get there hasn't always been smooth - launchd was implemented in stages, first replacing cron, then xinetd and the rc scripts have only disappeared in Snow Leopard. Ubuntu 9.10 has replaced init with upstart but rc scripts still exist. xinetd is replaced, but not cron.

Be aware of this when reading Internet articles. For example, Mac OS X posts on launchd may not have been updated to reflect its current state on Snow Leopard or beyond. Even the Ubuntu Upstart FAQ has a section stating that Upstart probably won't replace xinetd - but it did.

You also need to be careful about the things you think you know. You might add something to /etc/rc.common on Snow Leopard, but it won't be run. On Ubuntu 9.10, scripts are still in /etc/init.d, but they get run by Upstart (see /etc/init for the scripts that start them). Fedora still has /etc/inittab, but it is only used to set the default run level - anything else added there will be ignored. There is plenty enough confusion to be had, especially for those of us who work on different systems and release levels.

References and further reading

• Getting Started with launchd
  
  
• Ubuntu Upstart FAQ
  
  
• How to (and why) supervise forking processes
  
  
• Replacing init with Upstart
  
  
• runit - a UNIX init scheme with service supervision
  
  
• ReplacementInit
  
  
• initng- another init replacement designed to speed up boot by starting processes asynchronously.
  
  
• Service Management Utility- an init augmenter from Solaris 10
  
  

Comments?

More Articles by Anthony Lawrence - Find me on Google+

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.