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.
- 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.
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.
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.
You may need to know?
How long your machine has been up:
#uptime01:25PMup236days,3:54,
Your current runl evel:
#cat/etc/.init.state2
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-bsystembootFeb1719:13
Run level changes on your AIX box:
#/usr/lib/acct/fwtmp</var/adm/wtmp|greprun-levelTueMay2112: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 identifier2 : 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.
!/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.
# 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.
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>&1When 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 CoordinatorNext, get init to re-read the inittab file:
telinit qNow, 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 qIt 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>&1In 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/etc/rc.shutdownI then know all the applications get shutdown correctly, before issuing the actual
0 blogger-disqus:
Post a Comment