IBM Tivoli Monitoring > Version 6.3 Fix Pack 2 > Installation Guides > Installation Guide > Prepare for installation > Linux or UNIX installation considerations
IBM Tivoli Monitoring, Version 6.3 Fix Pack 2
Autostart scripts
Overview
The autostart script, generated by an installation, upgrade, or configuration, named ITMAgentsN or rc.itmN, depending on the UNIX platform, contains an entry for each Tivoli Monitoring application. The entries look similar to...
su - USER -c "ITM_Install_Home/bin/itmcmd agent start product_code"
...and...
su - USER -c "ITM_Install_Home/bin/itmcmd agent –o Instance start product_code"
...where...
USER ID the application will be started as. By default, USER is the owner of the bin directory for the application. For UNIX Log Alert agent, USER is owner of... ITM_Install_Home/PLAT/ul/bin
N Integer specific to each installation on a system. ITM_Install_Home Full path to the IBM Tivoli Monitoring version 6.x installation directory. product_code Two-character code for this application. instance Instance name required to start this application. PLAT Platform directory where the application is installed.
Components are started in the order listed in the autostart script. This order is based on the dependencies between components, rather than any logical sequence.
The kcirunas.cfg file allows overrides to the default processing. The kcirunas.cfg file is delivered in the root directory of the installation media, in the same location as install.sh. During installation, this file is copied to the directory...
ITM_Install_Home/config
...but is not overwritten if this file already exists. kcirunas.cfg is provided as a sample file with each section commented out. You do not have to modify this file if you want the autostart script to be generated with the default processing.
For local installation usage, you may modify the kcirunas.cfg file in the root directory of the media if you want to use the same set of values for multiple installations on similar systems from this image. You may also modify the kcirunas.cfg file in the ITM_Install_Home/config directory if you want to use a specific set of values for each individual installation from this image.
For remote deployment usage, you can modify the kcirunas.cfg file in the root directory of the media. You can also modify the kcirunas.cfg file in the Tivoli Enterprise Monitoring Server depot after populating the depot from this image. If you have set the DEPOTHOME variable in the file...
tables/TEMS_NAME/KBBENV
...use that value as the base when searching for the depot location.
To determine if you have set DEPOTHOME
cd ITM_Install_Home
DEPOTHOME=`find tables -name KBBENV -exec grep DEPOTHOME {} \; 2> /dev/null | cut -d= -f2`
echo $DEPOTHOME
If DEPOTHOME is not empty, locate kcirunas.cfg in the monitoring server depot:
cd ITM_Install_Home
DEPOTHOME=`find tables -name KBBENV -exec grep DEPOTHOME {} \; 2> /dev/null | cut -d= -f2`
find $DEPOTHOME -name kcirunas.cfg -print
If DEPOTHOME is empty, runs instead:
cd ITM_Install_Home
find tables -name kcirunas.cfg -print
The file kcirunas.cfg contains a superset of the XML syntax and structure in the file...
ITM_Install_Home/config/HOST_kdyrunas.cfg
(where HOST is the short hostname for this system) produced by remote configurations, such as remote deployment or Tivoli Enterprise Portal-based agent configuration.
The entries in kcirunas.cfg do not affect the actions performed for remote deployment, remote configuration, remote starting or stopping, or any Tivoli Enterprise Portal-initiated agent action. The entries in HOST_kdyrunas.cfg affect the generation of the reboot script. The entries in kcirunas.cfg also affect the generation of the reboot script, and they override any entries for the same component in HOST_kdyrunas.cfg.
The following is the default kcirunas.cfg file with all <productCode> entries commented:
<agent> <!productCode>ux</productCode> <instance> <user>itmuser</user> </instance> <!productCode>ul</productCode> <instance> <user>root</user> </instance> <!productCode>lz</productCode> <instance> <user>itmuser</user> </instance> <!productCode>ud</productCode> <instance> <name>db2inst1</name> <user>db2inst1</user> </instance> <instance> <name>db2inst2</name> <user>root</user> </instance> <!productCode>ms</productCode> <instance> <name>HUB17</name> <user>itmuser</user> </instance> <!productCode>cq</productCode> <instance> <user>itmuser</user> </instance> <!productCode>cj</productCode> <instance> <user>itmuser</user> </instance> </agent>
By default, each <productCode> section in the kcirunas.cfg file is disabled by making the product code a comment, such as <!productCode>.
To activate a section...
- Remove the comment indicator (the exclamation point, !) so that the item...
<!productCode>
...looks like...
<productCode>
- Copy a <productCode> section.
- Rather than creating new sections from scratch, customize each <productCode> section, and activate it.
Commented, or deactivated, sections are ignored. Uncommented, or activated, sections for applications that are not installed are ignored. For agents that do not require an instance value, specify only:
<productCode>product_code</productCode> <instance> <user>USER</user> </instance>
For agents that do require an instance value, like the DB2 monitoring agent (product code ud), specify the product_code, instance, user, and name:
<productCode>ud</productCode> <instance> <name>db2inst1</name> <user>db2inst1</user> </instance> <instance> <name>db2inst2</name> <user>root</user> </instance>
Two items that are supported in the kcirunas.cfg file that are not supported in the HOST_kdyrunas.cfg file are the <default> section and the <autoStart> flag. The <autoStart> flag can be used in the <default> section and in the <instance> section. The <default> section is specified as follows:
<productCode>product_code</productCode> <default> <user>db2inst1</user> </default> <productCode>product_code</productCode> <default> <autoStart>no</autoStart> </default> <productCode>product_code</productCode> <default> <user>db2inst1</user> <autoStart>no</autoStart> </default>The <autoStart> flag is specified as follows:
<productCode>product_code</productCode> <default> <autoStart>no</autoStart> </default> <productCode>product_code</productCode> <instance> <autoStart>no</autoStart> </instance>A section similar to the following can be used to not automatically start the default MQ Monitoring instance and to automatically start all other instances as the mqm user:
<productCode>mq</productCode> <default> <user>mqm</user> </default> <instance> <name>None</name> <autoStart>no</autoStart> </instance>A set of sections similar to the following can be used to avoid automatically starting the set of installed agents and servers. You need one section for each agent or server component installed:
<productCode>product_code</productCode> <default> <autoStart>no</autoStart> </default>
- Any changes made directly to the autostart script (ITMAgentsN or rc.itmN, depending on the platform) will not be preserved and will be overwritten the next time you install, configure, or upgrade an application.
- Any changes made to the AutoRun.sh script will not be preserved and will be overwritten the next time you apply higher maintenance.
Autostart scripts
The behavior of the autostart scripts generated during installation and configuration on UNIX platforms has evolved.
- In V6.1 FP 3, the installation process produced an autostart script with only one entry using a generic CandleAgent start all command. Users modified this file as needed.
- In V6.1 FP 4, the installation process generated individual entries for each application in a particular installation, but the values captured in the file could not be overridden.
- In V6.1 FP 5, the multiple entries remain, and an override capability has been added.
- In V6.2.2 fix pack 2 and later, the multiple entries remain, and the override capability has been significantly enhanced.
Parent topic:
Linux or UNIX installation considerations