We’re giving away 1,500 more DJI Tello drones. Enter to win ›
by David Tansley | Published July 29, 2013
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.
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:
To shut down a service automatically when a system is shut down, AIX offers:
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
Each entry field is separated by a colon “:”.
When you add entries into inittab, you need to make sure that:
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.
Need to know?
How long your machine has been up:
Your current runl evel:
Alternatively one can also use:
$ who ‑r
run‑level 2 May 24 16:29 2 0 S
When was my AIX box last rebooted:
Run level changes on your AIX box:
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.
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:
For completeness, here is the script in question:
/usr/sbin/sendmail ‑t <<mayday
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:
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:
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:
It will now be restarted.
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.
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:
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.
Tailoring your inittab and shutdown files allow you to control the services or applications that you want to get started or stopped in a clean manner. The rc.local file is handy for one-off commands that need to be run at startup.
March 14, 2019
This article provides a way to implement a kernel module on Linux, compile it, and explore ways in which a…
May 8, 2019
Artificial intelligenceData science+
Back to top