Helix Core is now P4. Product user interfaces will be updated soon. Learn more >>

P4 Server Administration Documentation | 2025.2

# Triggering on failed-back

This can be fired only during p4 failback when the newly restored target server The immediately upstream server for replica servers, edge servers, standby servers, proxies and brokers. See also 'upstream server' and 'central server'. first starts up during a successful `p4 failback` command. This trigger could be used to perform a DNS change, or any other activities needed to support replication after failback.

The special variables:

- `%%standbyserverid%%` and `%%standbyserverport%%` expand to the `serverID` and `serverport` of the standby before it became the new target server The immediately upstream server for replica servers, edge servers, standby servers, proxies and brokers. See also 'upstream server' and 'central server'..

- `%%serverid%%` and `%%serverport%%` refer to the current `serverid` and `serverport` of the new target server.

The equivalent for P4 Server Extensions are listed with the same names under Server extension session variables.

To define a failed-back trigger, use the p4 triggers command to configure the triggers form with this syntax:

triggerName failed-back failed-back command

Note that most of the usual trigger variables are not available for this trigger because this fires at server startup before any client connection.

Also note that multiple failed-back triggers run in the background asynchronously, and that a failed failed-back trigger does not prevent any other failed-back triggers from running.

- most of the usual trigger variables are not available for this trigger because this fires at server startup before any client connection

- multiple failed-back triggers can run in the background asynchronously

- a failed failed-back trigger does not prevent any other failed-back triggers from running

- See also Triggering on failed-over and Triggering on heartbeat (server responsiveness).

The following table describes the fields for a trigger definition:

Field | Meaning
--- | ---
name | The name of the trigger, such as testFailedBack2
`type` | Must be failed-back
`path` | Must be failed-back
`command` | The trigger for P4 Server to run when the target server The immediately upstream server for replica servers, edge servers, standby servers, proxies and brokers. See also 'upstream server' and 'central server'. restarts after a successful failback. Specify the command in a way that allows P4 Server to locate and run the command. The command is typically a call to a script. The command must be quoted. The command can take any arguments that your trigger can parse, including P4 Server trigger variables.

See also Triggering on heartbeat (server responsiveness).

## Example

In the Triggers: field, your form might have something similar to this:

    testFailedBack failed-back failed-back "perl '%serverroot%'/test.pl '%serverport%' '%serverid%' '%standbyserverid%' '%standbyserverport%'"
    testFailedBack2 failed-back failed-back "perl '%serverroot%'/test.pl '%serverport%' '%serverid%' '%standbyserverid%' '%standbyserverport%'"
    testFailedBack3 failed-back failed-back "perl '%serverroot%'/test.pl '%serverport%' '%serverid%' '%standbyserverid%' '%standbyserverport%'"

Your search for returned results