You are here: Administration > Man Pages > LCDI-flag(1M)

LCDI-flag(1M)

NAME

LCDI-flag(1M) — LifeKeeper flags

SYNOPSIS

LKROOT/bin/flg_create [-d dest] -f flag

LKROOT/bin/flg_remove [-d dest] -f flag

LKROOT/bin/flg_list [-d dest]

DESCRIPTION

LifeKeeper provides a facility to dynamically set flags to do various things. At the end of its listing, the lcdstatus command prints out a complete list of the flags that are currently defined. The following special purpose flags can exist:

 

shutdown_switchover

The presence of this flag indicates that the shutdown strategy for the local system has been set to "switchover", indicating that switchovers will occur when the server is shutdown. The absence of the flag indicates that the shutdown strategy is set to"do_not_switchover".

!nofailover!uname

If this flag exists, failover is inhibited for resources on the system with Unix uname, that have defined the system with the flag on it as their backup system. Note that this is a temporary flag that will be removed automatically when LifeKeeper communication with the system is restored.

!action!procid!timestamp!uname:identifier

This is an example of an "admin lock flag" [see getlocks(1M)]. These flags are used on actions that require that no other action be performed at the same time on any of the systems in a LifeKeeper configuration. For example, one may not create a hierarchy on one system while creating a hierarchy on another. The "admin lock flags" areused to ensure that one of these "global" operations is not performed until the one currently running completes.

The identifier field of the "admin lock flag" identifies the kind of action being performed. The system that requested the "admin lockflag" is specified by uname. The flag was created at timestamp number of seconds after Jan 1, 1970, by a process with a Unix process ID of procid that called getlocks [see getlocks(1M)]. All of the processes waiting for the "admin lock flag" are shown with their own "admin lockflag" in the listing produced by the lcdstatus command. The only one allowed to run is the first process that has their lock flag show up from the left side of the listing when reading the listing from left-to-right.

An example of such a flag is as follows:

!action!01525!701120147!cindy:filesys

This flag indicates that the action filesys is in progress, indicating a"file system hierarchy" is being created. The process with Unixprocess ID 1525 requested the "admin lock flag," at the time 701120147 on system cindy.

!object.table_stale

The object table is stale and needs to be regenerated. No user action is required here; this is a transitory condition that LifeKeeper will automatically fix when the postrestore scripts [see LCD(1M)] are run.

!restore

This flag is set by LifeKeeper when the prerestore scripts [see LCD(1M)] are run. It indicates that the postrestore scripts should be run. Normally, this is a transitory condition that LifeKeeper will automatically fix when the postrestore scripts [see LCD(1M)] are run at a later time. The only exception to this is if the postrestore scripts are being explicitly run by using the following command:

$LKROOT/bin/lcdrecover -G restore

!restore!uname

When this flag is set it indicates that the postrestore scripts [see LCD(1M)] should be run remotely on system uname. When the postrestore scripts are run on this system, a remote request will be sent to system uname to run its postrestore scripts. Normally, this is a transitory condition that LifeKeeper will automatically fix. The only exception to this is if the postrestore scripts are being explicitly run by using the $LKROOT/bin/lcdrecover -G restore command.

!remove

This flag is set by LifeKeeper when the preremove scripts [see LCD(1M)] are run. It indicates that the postremove scripts should be run at a later time. Normally, this is a transitory condition that LifeKeeper will automatically fix when the postremove scripts [see LCD(1M)] are run at a later time. The only exception to this is if the postremove scripts are being explicitly run by using the following command:

 $LKROOT/bin/lcdrecover -G remove

!remove!uname

When this flag is set it indicates that the postremove scripts [see LCD(1M)] should be run remotely on system uname. When the postremove scripts are run on this system, a remote request will be sent to system uname to run its postremove scripts. Normally, this is a transitory condition that LifeKeeper will automatically fix. The only exception to this is if the postremove scripts are being explicitly run by using the following  command:

$LKROOT/bin/lcdrecover -G remove

!delete

This flag is set by LifeKeeper when the predelete scripts [see LCD(1M)] are run. It indicates that the postdelete scripts should be run at a later time. Normally, this is a transitory condition that LifeKeeper will automatically fix when the postdelete scripts [see LCD(1M)] are run at a later time. The only exception to this is if the postdelete scripts are being explicitly run by using the following command:

$LKROOT/bin/lcdrecover -G delete

!delete!uname

When this flag is set it indicates that the postdelete scripts [see LCD(1M)] should be run remotely on system uname. When the postdelete scripts are run on this system, a remote request will be sent to system uname to run its postdelete scripts. Normally, this is a transitory condition that LifeKeeper will automatically fix. The only exception to this is if the postdelete scripts are being explicitly run by using the following command:

$LKROOT/bin/lcdrecover -G delete

serial_recover

The user may set this flag to enable serial recovery of resources in the event of server failure. The default failover mechanism in this event is parallel recovery, which may be restored by removing this flag. This option is provided in the event that unexpected behavior occurs during parallel recovery. A user may also choose to use serial recovery to obtain a sequential event log, or to measure the performance of individual recovery kits.

A specific example of a situation in which it might be useful to set this flag is the case of multiple LifeKeeper protected file systems residing on the same physical SCSI disk or disks. Because performing fsck's of the file systems in parallel during a server failover could result in excessive disk head movement which could slow down the recovery, setting the serial_recover flag in this case might actually result in faster failovertimes.

confirmso!uname

When set on a given LifeKeeper system, this flag indicates that any failovers from the system indicated by uname to the local system require manual confirmation. Confirmation is provided using the lk_confirmso command.

SYNTAX

The syntax of the commands is as follows:

flg_create [- dest] -f flag

The flag is created on system dest. The flag name must be enclosed insingle quotes if it contains '!' characters to avoid improper interpretation by the shell, e.g. flg_create -f '!nofailover!systemA'. Note that this only modifies the "shared memory" segment of the LifeKeeper configuration database. The LifeKeeper lcdsync command should be run after this command to ensure that the shared memory changes are reflected into the permanent storage onto a disk file. If dest is not specified, the current system is assumed.

flg_remove [-d dest] -f flag

The flag is removed on system dest. The flag name must be enclosed insingle quotes if it contains '!' characters to avoid improper interpretation by the shell, e.g. flg_create -f '!nofailover!systemA'. Note that this only modifies the shared memory segment of the LifeKeeper configuration database. The LifeKeeper lcdsync command should be run after this command to ensure that the shared memory changes are reflected into the permanent storage onto a disk file. If dest is not specified, the current system is assumed.

flg_list [-d dest]

A short listing, one flag per line, of all of the flags currently defined on this system is printed to UNIX stdout. The list is ordered by time of creation, where the last flag in the  list is the newest one. If dest is not specified, the current system is assumed.

EXIT CODES

The following exit codes could be returned by these commands:

0

The operation has succeeded.

1

A Unix system call or library call has internally returned failure.

2

A user-specified syntax error occurred.

3

LifeKeeper internal error.

4

A request to perform an operation on an object that already exists.

5

An argument specified is illegal.

6

Index out-of-range.

7

A request has been made on an object that does not exist.

8

A request was made to delete a resource instance on which anothernon-deleted resource instance depends.

9

An attempt to communicate with another system failed.

NOTES

The location of this utility, LKROOT, is defined in the default file /etc/default/LifeKeeper.

FILES

/etc/default/LifeKeeper

© 2012 SIOS Technology Corp., the industry's leading provider of business continuity solutions, data replication for continuous data protection.