Script | Description |
---|---|
LaunchScript | Used to launch a service. The most widely used mechanism for starting all the services is: sms-start The default script to start a single service is sms‑start‑service. Its syntax is: sms-start-service [host] [service] [process] [options] • host: Name of the machine on which to run the service • service: Name of the service • process: Name of the executable that launches the service • options: Command line options that are passed to the process at initialization For example, to start DBService, type: sms-start-service train1 DBService DBService -nodaemon Define the launch script in system.dat as follows: LaunchScript [script name] If no script is specified, then sms-start-service is assumed. |
Notify Script | Announces an event. This script eliminates the need for an isis tool as an announcer. It can be used to generate e-mails and logs, or to interface to paging systems. When developing this script, keep in mind that it does not connect to isis. The syntax is: [script name] [time] [host] [process] [event type] [system state] [old system state] [message] • time: Date/time stamp. • host: Name of the machine on which the processes are running. • process: Name of the process. • event type: The process state. Valid values are: • STARTING: The process has started. • INITIALIZING: The process has registered and is initializing. • RUNNING: The process reports as initialized. • FAILED: The process has failed. • FAILED_INTERFACE: The process reports a failed interface. • STOPPED: The process intentionally stops. • INFO: The process generates a progress report. • system state: State of the system. Valid values are: INITIALIZING: SMService is launching processes from system.dat. NORMAL: All processes are running or are intentionally stopped. WARNING: A non-critical process has failed. This state also refers to failed critical processes that have another instance running. CRITICAL: A critical process has failed and there are no other instances running. • old system state: State of the system before the event generating the announcement occurred. • message: Message supplied by SMService or the process that caused the event. Define the notify script in system.dat as follows: NotifyScript [script name] There is no default value, so if a script is not defined here, then only isis announcements are generated. |
CoreScript | SMService looks to this script for instructions when a core file is detected. This script determines what should be done with the file, such as announce the existence of the file, delete it, archive it, or e-mail the administrator. It does not connect to isis. Its syntax is: [script name] [process] [corefile] process: Name of the process that has produced the core file corefile: Path to the core file Define the core script in system.dat as follows: CoreScript [script name] If a script is not defined, the core file remains and will be detected by SMService during the next cycle. |
Name | Description |
---|---|
sms‑notify | This is a NotifyScript and can be configured as the notify script in system.dat (this example is very simple), it merely calls the notify by email script. |
sms‑notify‑by‑email | This is a somewhat more advanced script for sending notifications of selected events to a group of administrators by email. The script uses the information supplied by SMService on the command line to determine if this event is putting the system into a critical state - or is clearing a previously existing critical state. If either of these two events are detected an email is constructed and sent to the appropriate people. The script is quite configurable and can be easily modified to change the names of the recipients, the mailer program used to generate the email, etc. This script can be configured directly as the NotifyScript in system.dat, or it can be invoked by an intermediate script such as sms‑notify . |
sms‑core‑save | This is an example of a CoreScript. It simply moves the core file to an archive directory and renames it based on machine name, process name and timestamp. It then generates an email to the administrators to inform them that a core file was found. |
sms-start | This script is the way you start the NMS services. SMService is launched and then smsReport is run in one-shot mode. This means that the script will run until SMService starts reporting a system state as something other than initialized sms-start uses the Action command to determine if SMService is already running on this machine. If it is, it simply sends it a restart message. |
# NAME | REQUIRED | START | DELAY | RESTARTS | RESET | MODE |
service SMService | Y | 60 | 0 | 10 | 86400 | |
service DBService | Y | 90 | 0 | 10 | 86400 | |
service ODService | Y | 180 | 0 | 10 | 86400 | |
service DDService | Y | 180 | 0 | 10 | 86400 | |
service MTService | Y | 180 | 0 | 10 | 86400 | |
service MBService | Y | 180 | 0 | 10 | 86400 | |
service JMService | Y | 280 | 0 | 10 | 86400 | |
service SwService | Y | 280 | 0 | 10 | 86400 | |
service PFService | Y | 4000 | 0 | 10 | 86400 | |
service FLMService | Y | 4000 | 0 | 10 | 86400 | |
service FLTService | Y | 4000 | 0 | 10 | 86400 | |
service VVOService | Y | 4000 | 0 | 10 | 86400 | |
service corbagateway | Y | 120 | 0 | 10 | 86400 | |
service service_alert | Y | 120 | 0 | 10 | 86400 |
Field | Description |
---|---|
NAME | The name of the executable for the particular service. |
REQUIRED | Indicates whether the instance of the service is required for the system to be functional. Valid values are ‘Y’, ‘Yes’, ‘N’, or ‘No’. If there are no instances of a required service, the system locks until an instance is started. |
START | The time taken for a service to start. If the service is not running after this many seconds, it is considered failed. If services are started in parallel (if parallelStart is set to 1 in system.dat or sms‑start -p is used). This value must take into account the start time of each of the services this service depends on. |
DELAY | Sets the number of seconds to wait before restarting a failed service. It only applies to processes that failed after they were running. Processes that fail before initialization are restarted based on the period parameter. A negative number indicates that the process is not restarted. |
RESTARTS | The number of times to attempt restarting a process. A process is no longer automatically restarted after this value is exhausted until the process is reset (see below). |
RESET | The timeout period that controls the rate at which processes are reset. When a process is reset, the restart counters re-initialize. A negative value deactivates this feature. |
MODE | An optional argument that specifies the high availability mode of the service. If a mode is specified, the service starts with -[mode] and -number [n], where [n] is the id defined for the node in the server line. Valid modes are exclusive, redundant, parallel or not specified. Exclusive runs with only one server. Redundant specifies running two servers, each with a database that mirrors the other. Parallel involves using Oracle Parallel Server to run two servers with a shared database. |
# NAME | EXE | ARGS |
---|---|---|
program DBService | DBService | -nodaemon |
program ODService | ODService | -nodaemon -aggregates |
program DDService | DDService | -nodaemon -zones -subscribezone -allowReset -alarms ALL |
program MTService | MTService | -nodaemon |
program MBService | MBService | -nodaemon |
program JMService | JMService | -nodaemon -dbs |
program SwService | SwService | -nodaemon |
program PFService | PFService | -nodaemon |
program FLMService | FLMService | -nodaemon |
program FLTService | FLTService | -nodaemon |
program VVOService | VVOService | -nodaemon |
program corbagateway | Corbagateway | -nodaemon -ORBInitRef NameService=iioploc://[hostname]:1750/NameService -ORBLogFile /users/[username]/dialog_log/orb.log -ORBDebugLevel 3 -implname InterSys_[hostname]_[username] -iorfile /users/[username]/etc/[username]_vns.ior -publisher -xmldir /users/[username]/dist/wwwroot/xml |
program service_alert | Mycentricity | -nodaemon -xmldir /users/[username]/dist/wwwroot/xml |
Field | Description |
NAME | Specifies the name of the service that the executable belongs to. Valid services for this value are defined in the service section. |
EXE | Specifies the name of the executable that runs the service. |
ARGS | Defines the command line options that are used in all instances of the service. |
# | NODE | SERVICE | DATABASE/ARGS |
---|---|---|---|
instance | [local] | SMService | |
instance | [local] | DBService | |
instance | [local] | ODService | |
instance | [local] | DDService | |
instance | [local] | MTService | |
instance | [local] | JMService | |
instance | [local] | SwService | |
instance | [local] | corbagateway | |
instance | [local] | service_alert |
Field | Description |
NODE | Defines the node. Valid nodes for this value are defined in the server section. The value for NODE can be specified literally as [local]. If this is the case, then SMService will automatically substitute the name of the current node as the instance for which the service is to be started. By using [local] in place of a specific machine name, you can simplify your effort when replicating a system; you will not need to make changes to the system.dat at all. |
SERVICE | The service being defined. |
DATABASE/ARGS | Command line arguments that are applied when the service starts at this node. If the program section specifies command line options for a particular service, it applies to all nodes, so the arguments do not need specification here. |