Thursday 8 August 2013

IBM AIX autostartup and shutdown scripts

IBM AIX auto-startup and shutdown scripts

Summary:

Automatically starting up the required services when a system restarts can save you the task of logging in to the system to manually start those services. When shutting a system down, you can have scripts in place to shut down those services in a controlled manner. This article covers the different methods employed to start or stop your applications when a system is restarted or shut down.

When a system is restarted, which can be during the day or may be during the night that may be due to power loss at a site, it can be advantageous to have the services (applications) that were running on the system to be started up automatically. Sometimes that is! Having a service started up can save you the extra task of logging in and starting them yourself, which is good. However, there are some occasions when one would not want the services started up. Here, I am thinking of a cluster service environment, where there might be different services spread across a few IBM® AIX® hosts and those services need to be started up in a correct sequence for them to function and integrate correctly. Here, you might need to start them up manually in order.

Startup and shutdown methods:

To have services started up automatically, AIX offers (similar to other UNIX/Linux operating systems) the inittab file to achieve this. From /etc/inittab you can either:

  • Start the services directly from within inittab by issuing a command (script) to be run.
  • Use a common script, generally referenced as rc.local, that is called from inittab, that contains one or more commands (or calling scripts) to be run.
  • Use the rc.run level directories called from inittab.
To shut down a service automatically when a system is shut down, AIX offers:

  • The /etc/rc.shutdownscript. This file is the opposite of rc.local. Here, commands are placed that are to be run when the system is issued with a shutdown operation.
In this article, I will not cover the rc.runlevel directories configuration, but rather the other processes mentioned earlier.

To put an entry into inittab, you need to use the following format:
identifier : runlevel: action: command
Where:
  • identifier is a unique name for the entry. Try to keep it between 1 to 7 characters. It keeps entries readable.
  • runlevel is the actual runlevel number which upon reaching that runlevel, the said command contained in this inittab entry will be run.
  • action is how the command should be treated when it is at the required runlevel you can find more information on this later in this article.
  • command is the actual command that will be run.
Each entry field is separated by a colon ":".

When you add entries into inittab, you need to make sure that:

  • There are no typos in inittab, it is not unknown for AIX to go into a process loop if there are typos in inittab. The init command then cannot read the file correctly.
  • The identifier is definitely unique, as otherwise, the second occurrence of the duplicated identifier may not run as you might expect.
If your scripts or commands that are called from /etc/rc.shutdown have typos, be it 'syntax or command not found' issues, note that the shutdown operation will be aborted if called using the shutdown command. So, make sure that your scripts work correctly before being called from rc.shutdown.

You may need to know?

How long your machine has been up:

#uptime
01:25PMup236days,3:54,

Your current runl evel:

#cat/etc/.init.state
2
Alternatively one can also use:
$ who -r
run-level 2 May 24 16:29       2    0    S

When was my AIX box last rebooted:

#who-b
systembootFeb1719:13

Run level changes on your AIX box:

#/usr/lib/acct/fwtmp</var/adm/wtmp|greprun-level
TueMay2112:24:43BST2013
run-levelh10015000621369135516
TueMay2112:25:16BST2013
run-level210006201231369135516
TueMay2112:25:16BST2013

That's a comment

When adding entries into inittab, be sure to remember that a colon ':' , at the beginning of the line is a comment, and thus the rest of the line will be ignored by init when reading inittab. Do not use a '#' (hash) symbol to add comments. However, you can use the hash symbol at the end of the line, for a comment.

inittab entries

Let's look at a entry for inittab that runs a script. Suppose, we want to run a script that sends an email to system administrators stating that the box is available when the system come up.
The entry for inittab is shown below:
mailout:2:once:/usr/local/bin/mailout > / dev/null 2>&1 #mail users
The above entry can be summarized as follows:
  • mailout: The unique identifier
  • 2: Run this when the system reaches runlevel two (the default)
  • once: Run the script and do not wait for its termination; init will carry on processing inittab. Iif the process fails, init will not attempt to rerun it.
  • /usr/local/bin/mailout: The full path and script name of the command to run; notice that the output is thrown away to /dev/dull. We end with a '#' comment on what the script does.
For completeness, here is the script in question:
!/bin/sh
# mailout
/usr/sbin/sendmail -t <<mayday
From: `hostname`
To: rs6admins
Subject: `hostname` P-Series is up
The AIX `hostname` is now up, please check services.
In the above example, the action part attribute once is run only once, but there are other actions that can be used as well. Two other common ones are: respawn and wait. For respawn, the command will be run, but init will not wait until it finishes. If the command stops, inittab restarts it, and this process continues. So, you should look for a command that is respawned, practically running all the time.

 The STIME field of a ps -ef command output shows the last time it was respawned. Typical processes that are respawned are tty, cron, and database monitor applications and Network File System (NFS) based utilities. The other common action is wait. Init runs the command and waits until it is finished before reading the inittab file. Typical processes that use the wait action are network authentication applications and printing, backup services, and so on.

If you need to start a process that is not to be owned by root, then you can simply provide the su command as part of the command entry in inittab. The following example runs /home/ampter/start.sh, but first, the su command is invoked so that the process is started by user ampter. Note the use of quotes surrounding part of the command:

amps:2:once:su - ampter "-c /home/ampter/start.sh" > /dev/console 2>&1
When editing the inittab file, be sure to check your entries after saving the file. Then, review your changes again. Nobody wants a messed up inittab believe me. If one does not feel confident in manually editing the file, then all is not lost. AIX offers the following utilities:
chitab: to alter an exiting inittab entry 
lsitab: to list inittab entries 
mkitab: to add an inittab entry 
rmitab: to remove an inittab entry 

Stopping a respawned process

If you require to stop a process from respawning (in other words stop it perhaps to do some maintenance work), first, edit the inittab file and enter a comment at the beginning of the entry, so that it will not be read by init. The following example shows an entry that is ignored by inittab by placing a colon at the beginning of the entry.
:fmc:2:respawn:/opt/db2_09_05/bin/db2fmcd #DB2 Fault Monitor Coordinator
Next, get init to re-read the inittab file:
telinit q
Now, stop the application. Do whatever maintenance is required. To restart the process from inittab, simply remove the colon from the beginning of the entry. Then, at the command prompt, run the following command to get init to re-read the inittab file:
telinit q
It will now be restarted.

rc.local bound

Another common approach to start applications or run commands upon startup is to use the /etc/rc.local file. Here the file, which is an executable script, is called from inittab. The rc.local file can contain one or many of your bespoke commands that you need to run upon startup. In my view, this file should only be used for one-off or temporary command executions, rather then service startup scripts.
A typical entry to allow rc.local to be called from inittab is:
rcloc:2:wait:/etc/rc.local > /dev/console 2>&1
In the above example, the action part is wait. That is, init is to wait until all commands have been run, before continuing to read the inittab file. I use the rc.local file for temporary or bespoke commands, such as disabling a paging space or bringing down a network interface and thus not full startup scripts for services. Those commands would be in my inittab file.

Shutting down services

When you issue a shutdown command, the /etc/rc.shutdown file is called, which is an executable script. In this file, you put commands or calling scripts that will shut down your bespoke services. I find it as a good practice when I have to shut down an AIX system to first call the /etc/rc.shutdown file by itself:
/etc/rc.shutdown
I then know all the applications get shutdown correctly, before issuing the actual shutdown command, which of course will re-run the rc.shutdown file. But, I do not mind that.

0 blogger-disqus:

Post a Comment