Editing Startup Scripts on Solaris - Part 2 - The Rub

As we mentioned yesterday, it's generally best practice to edit, or update, your init scripts by editing the source file in /etc/init.d, rather than the link to it in one of the "run level" directories, like /etc/rc2.d

Given a specific example (For instance: we need to comment out 8 or 9 scripts in /etc/init.d) that we want to do fast, we've decided that just adding "#" symbols to the beginning of every line of all 9 scripts in /etc/init.d would be the fastest way.

We have a few options, like using Sed, Awk or command-line Perl, to take care of the work for us lickety-split. However these solutions, and others like them, present a general problem. There's nothing wrong with using these methods, in general, except that Solaris, right out-of-the-box, uses a lot of "hard links" in its "run level" directories to point back to the source script in /etc/init.d.

Hard links differ from the symbolic links we discussed yesterday in that they are not just "pointers" to the source file; they are actually links to the inode that the source file uses. In essence, they are another version of the exact same file, or, in different terms, another reference to the same file.

To illustrate the difference another way: If you delete a source file, the symbolic link to it will still exist, but if you try to edit that symlink, you'll be editing an empty file, since it's just a pointer to something that doesn't exist anymore. If you delete the source file and go to edit the hard link, you will still be able to edit the original file since the hard link points to the inode (not the filename) and removing the source file has just decreased the reference count of the inode.

When a hard link to a file is created, in essence, two copies of the file now exist. This presents an issue if you use Sed, Awk or command line Perl, because when you edit the source file in /etc/init.d using these methods, you're copying the changes to another file and then writing that back over the original: Changing the inode number! Now your source file and your file in the "run level" directory both point to different inodes, and updating the source file won't change the contents of the "run level" file.

There is an easy way around this. You can edit each of the 9 files using an editor like vi. But how to do it as quickly and easily as with Sed, Awk or command line Perl?

Tomorrow, we'll create a script that will do just that. It will edit your files for you, hands-off, and not change the inode number; thus ensuring that all of your changes will remain consistent in the "run level" directories, no matter what kind of links (soft or hard) they harbour.

Have a good Saturday Night :)

, Mike

linux unix internet technology

Editing Startup Scripts on Solaris - Part 1 - The Nice Part

A Good Friday to you :)

Today I thought I'd go on a little about editing startup scripts.

It's generally accepted that the correct form for creating an init (or rc) script on Solaris is to create that actionable script in /etc/init.d and then create links to it (soft or hard) in the proper "run level" directories (/etc/rc2.d for run level 2). These files are also standardly named beginning with a capital S (to instruct /sbin/rc to run the script with the "start" option) or K (to instruct /sbin/rc to run the script with the "stop" option).

A lot of times, folks will simply create scripts in the various "run level" directories (like /etc/rc3.d for run level 3), which works perfectly well, but might cause some confusion down the road. For instance; if you create /etc/rc2.d/S88sendmail and replace the linked version that pointed back to the /etc/init.d/sendmail script, any changes made to the the source version in /etc/init.d will never be reflected in your version (sitting in /etc/rc2.d) and - should you expect your changes to work - you'll find that they never seem to stick on reboot.

I suppose that the best argument for doing things the "standard" way is that it can save you a lot of time and probably more than a few headaches. Consider that, by doing things by-the-book, you need only edit one script to affect however many run levels its linked to. Also, confusion over "what is actually where" is removed.

When it comes to the back-links in the "run level" directories, I prefer to use symbolic links (created by "ln -s") rather than hard links (created using "ln" straight up). The reasons for this are threefold.

1. Symbolic links are easy to see. I don't consider myself simple or anything like that, but I do like to be able to run "ls -l" in /etc/rc3.d and see something like this (clipped output to keep the output line short enough to not word-wrap):

hostname.xyz.com[/etc/rc3.d] # ls -l
lrwxrwxrwx 1 root other S90prog -> /etc/init.d/prog

Just seeing that, I know that this script is actually in /etc/init.d and, if I want to make changes to it, that's where the source is. Which brings me to point two.

2. Symbolic links are just as easy to use as hard links. Now that I'm feeling confident that I'm editing the correct file, I don't need to edit the /etc/init.d/prog file, because the symbolic link "/etc/rc3.d/S90prog" is just a pointer to it and, by editing it, I'm actually editing the script in /etc/init.d.

3. And thirdly, I like the fact that symbolic links are merely symbolic. The difference between a hard link and a symbolic link can be gigantic depending on what kind of change you're making!

And that, we'll talk about tomorrow, because it's a topic that will eat up some real estate, I've taken up enough space for today :)


, Mike

linux unix internet technology