19.5 Trigger Variables
Trigger variables can add greater flexibility and power to a site administrator who wants to automate certain tasks and system behaviors. Variables allow triggers to launch based on another trigger's behavior, state, and/or output.
AType=exec,Action="/tmp/trigger1.sh",EType=start,Sets=Var1.Var2 \ AType=exec,Action="/tmp/trigger2.sh $Var1 $Var2",EType=start,Requires=Var1.Var2
In this example, the first trigger sets two variables (separated by a '.'), which are received in the second (separated by a ':'). As previously mentioned, those arguments could be accessed in the second trigger through the variables $1 and $2.
It is also possible to have a trigger set a variable when it fails using the '!' symbol:
AType=exec,Action="/tmp/trigger1.sh",EType=start,Sets=!Var1.Var2 \ AType=exec,Action="/tmp/trigger2.sh",EType=start,Requires=Var1 \ AType=exec,Action="/tmp/trigger3.sh",EType=start,Requires=Var2
In this example, the first trigger will set Var1 if it fails and Var2 if it succeeds. The second trigger will launch if Var1 has been set (the first trigger failed). The third trigger will launch if Var2 is set (the first trigger succeeded).
Variable requirements can be further refined to allow for the evaluation and comparison of the variable's value. That is, triggers can have a dependency on a variable having (or not having) a certain value. The format for this is as follows:
The optional * specifies that the dependencies are satisified by an external source that must be previously registered. A number of valid comparison types exist:
Following is an example of how these comparitive dependencies can be expressed when creating a trigger.
AType=exec,Action="/tmp/trigger2.sh",EType=start,Requires=Var1:eq:45 \ AType=exec,Action="/tmp/trigger3.sh",EType=start,Requires=Var2:ne:failure1
In this example, the first trigger will fire if Var1 exists and has a value of 45. The second trigger will only fire if Var2 is not the string failure1.
Several internal variables are available for use in trigger scripts. These can be accessed using $<VARNAME>:
Other unique variables are available to triggers attached to specific objects:
AType=exec,Action="/tmp/trigger3.sh $OID $HOSTLIST",EType=start
In this example, the object ID ($OID) and hostlist ($HOSTLIST) will be passed to /tmp/trigger3.sh as command line arguments when the trigger executes the script. The script can then process this information as needed.
For triggers that are attached to job objects, another method for supplying variables exists. The trigger is able to see the variables in the job object to which it is attached. Updating the job object's variables effectively updates the variable for the trigger. This can be accomplished through the use of mjobctl using the -m flag.
> mjobctl -m var=Flag1=TRUE 1664
This sets the variable Flag1 to the value TRUE, creating Flag1, if necessary. This will be seen by any trigger attached to job 1664.
Variables used and created by triggers are stored in the namespace of the object to which the trigger is attached. Sometimes it is desirable to make certain variables more accessible to triggers on other objects. When using the Sets trigger attribute, you can specify that a variable, created either by a success or failure, should be exported to the name space of the parent object when the current object is destroyed through a completion event. This is done by placing the caret (^) symbol in front of the variable name when specifying it.
AType=exec,Action="/tmp/trigger1.sh",EType=start,Sets=^Var1.!^Var2 \ AType=exec,Action="/tmp/trigger2.sh",EType=start,Requires=Var1 \ AType=exec,Action="/tmp/trigger3.sh",EType=start,Requires=Var2
In this example, both Var1 and Var2 will be exported to the parent object when the trigger has completed. They can also be used by triggers at their own level, just as in previous examples.
By default, triggers will only look for variables to fulfill dependencies in the object to which they are directly attached. In addition, if they are attached to a job object, they will also look in the job group, if defined. However, it is not uncommon for objects to have multiple generations of parent objects. If the desired behavior is to search through all generations of parent objects, the caret (^) symbol must be specified, as in the following example:
Searches Moab documentation only
|© 2001-2010 Adaptive Computing Enterprises, Inc.|