Avaya Logo

Previous Topic

Next Topic

Book Contents

Book Index

iCk activities

$timingMsg {process} {runlevels} {checkPeriod/Time}

This activity causes a timing message to be sent to a specified process at regular intervals whenever the system is at one of a specified run levels. Currently, the TSM and the VROP processes expect to receive timing messages once every two seconds.

$hungProcess {process} {runlevels} {checkdPeriod/Time} {timeout{fill|report|exec cmd}}

This activity causes a specific process, whose name appears in the Bulletin Board, to be evaluated to see if it is properly reading its messages. Processing takes place only when the system is at one of the specified run levels. {timeout} is the length of time the process can stay in the working state before being declared hung. Once a process is determined to be hung, one of three responses is possible, as described in the following table:

Response

Description

Comments

kill

The process is killed by sending it a SIGUSR1 signal, followed by a SIGKILL signal if it does not voluntarily exit

�

report

A message saying that the process is hung is logged

No other action is taken

exec

The specified command is executed

The %p meta-word has the value of the PID of the process associated with the rule

$autoReboot {off/on} {u-reboots} {ubPeriod} {runlevels} {setPeriod}

This activity controls the feature that automatically sets the UNIX kernel auto-reboot flag. If the entry is marked off, the auto-reboot flag is not automatically turned on. It can still be manually set with an iCk command. If the entry is marked on, the automatic setting is enabled. The remaining parameters control when the flag is set. The algorithm that controls the setting of the flag is as follows. In this discussion, the term boot event refers to an instance when the system boots itself.

The number of unanticipated kernel boot events is determined by examining the /etc/wtmp file (the history file of init actions) for change of run level entries and boot time entries. Any entry falling within the {ubPeriod} of time prior to the most recent system boot time are considered. If a boot time entry is preceded by a change of run level to levels 0, 5, or 6, the boot event is considered anticipated, since someone deliberately entered the command to boot the system. If a boot time entry is NOT preceded by such a change of run level entry, the boot event is considered unanticipated. This includes power failures, reset button pushes, and panics of the UNIX kernel.

If the number of unanticipated boot events is less than {u-reboots}, the auto-reboot flag is set {setPeriod} amount of time after the system comes up to one of the run levels specified by {runlevels} .

If the number of unanticipated boot events is greater than or equal to {u-reboots}, setting of the auto-reboot flag is inhibited and is not set until the system has been up at one of the run levels specified by {runlevels} for a {ubPeriod} of time.

For example: typing $autoReboot on 5 60m 4 5m, which is the standard default setting, specifies that if less than 5 unanticipated boot events have occurred in the past 60 minutes, the auto-reboot flag is set in the UNIX kernel 5 minutes after reaching run level 4. If 5 or more unanticipated boot events have occurred in the past 60 minutes, the auto-reboot flag is not set until 60 minutes after reaching run level 4.

$fileMax {file} {maxSize} {checkPeriod/Time} reduce {minSize}
$fileMax {file} {maxSize} {checkPeriod/Time} remove
$fileMax {file} {maxSize} {checkPeriod/Time} exec {cmd}

This activity checks one or more files to insure that they have not grown too large. {file} is the name of a file or a pattern specifying a set of files. {maxSize} is the maximum size in bytes that a file can grow to before it triggers a response from iCk. A check on the size of the file or files is made as specified by {checkPeriod/Time}. One of three responses to a file becoming too large can occur, a described in the following table:

Response

Description

Comments

reduce

The offending file is reduced in size by saving the last {minSize} bytes of the file and discarding the rest

�

remove

The offending file is removed entirely

�

exec

The command specified is executed

The meta-words %f , %d , and %b are defined as the various parts of the file name and can be used in the command

$fileCheck {file} {runlevels} {checkPeriod/Time} {type} {owner} {groups {modemask} {modes} [ cmd ]

This activity can be used to insure that a specific file or files exist and have the proper ownership and modes. {file} specifies the file or a pattern that selects a set of patterns. {runlevels} specify at which run levels the checks are made. {checkPeriod/Time} specifies the frequency of checks. {type} specifies the type of file, and can take one of seven values, as described in the following table:

Value

Description

- (hyphen)

The type does not matter

f

The file is a regular file

d

The file is a directory

p

The file is a named pipe

c

The file is a character special device

b

The file is a block special device

I

On SVR5.4 systems, the file is a symbolic link

The {owner} variable specifies who owns the file. If this value is a hyphen (-) the owner of the files is not of interest. {group} specifies which group owns the file. If this value is a hyphen (-), which group owns the files is not of interest. {modeMask} specifies which bits of the mode are of interest while {modes} is the desired state of the bits. For example, if both {modeMask} and {modes} are 0444, the check is to insure that the file is readable by anyone, but whether it was writable or executable is not of interest. If on the other hand {modeMask} is 0777, while {modes} is 0444, the check is to insure that the file was only readable and must not be writable or executable by anyone. If a file fails to pass a $fileCheck test, the failure is always reported. If the optional [cmd] is specified, this command is executed. The meta-words %f, %d, and %b are set to the various parts of the file name for use in the command.

$EOF

This mark indicates the end of the rules. Anything beyond this mark in the rules file is ignored.

� 2002 Avaya Inc. All Rights Reserved.