# # Unix and Linux startup scripts, Part 3
APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

Unix and Linux startup scripts, Part 3

I've removed advertising from most of this site and will eventually clean up the few pages where it remains.

While not terribly expensive to maintain, this does cost me something. If I don't get enough donations to cover that expense, I will be shutting the site down in early 2020.

If you found something useful today, please consider a small donation.



Some material is very old and may be incorrect today

© December 2009 Anthony Lawrence

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:


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


Unix and Linux startup scripts, Part 4 introduces Systemd.


If you found something useful today, please consider a small donation.



Got something to add? Send me email.





(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

->
-> Unix and Linux startup scripts, Part 3


Inexpensive and informative Apple related e-books:

El Capitan: A Take Control Crash Course

Take Control of Preview

Take Control of OS X Server

iOS 8: A Take Control Crash Course

Take Control of Apple Mail, Third Edition





More Articles by © Anthony Lawrence





Printer Friendly Version

Have you tried Searching this site?

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us


Printer Friendly Version





There's no obfuscated Perl contest because it's pointless. (Jeff Polk )




Linux posts

Troubleshooting posts


This post tagged:

BSD

Basics

Linux

Popular

SCO_OSR5



Unix/Linux Consultants

Skills Tests

Unix/Linux Book Reviews

My Unix/Linux Troubleshooting Book

This site runs on Linode