Triggering on journal rotation

To configure Helix Core Server to run trigger scripts when journals are rotated, use the journal-rotate and journal-rotate-lock type triggers. Journal-rotate triggers are executed after the journal is rotated on a running server, but only if journals are rotated with the p4 admin journal or p4 admin checkpoint commands. Journal rotate triggers will not execute when journals are rotated with the p4d -jc or p4d -jj commands.

Journal-rotate triggers allow you to run maintenance routines on servers after the journal has been rotated, either while the database tables are still locked or after the locks have been released. These triggers are intended to be used on replicas or Edge Servers where journal rotation is triggered by journal records. The server must be running for these triggers to be invoked.

The following table describes the fields of a journal-rotate trigger:

Field Meaning

name

The name of the trigger.

type

  • journal-rotate: Execute the trigger after the journal is rotated and database file locks are released. See Example of journal-rotate trigger.
  • journal-rotate-lock: Execute the trigger after the journal is rotated but while the database files are still locked. While the database tables are locked, no P4 commands can be run against this Helix Core Server. See Example of journal-rotate-lock trigger.
Warning

While a journal-rotate-lock trigger is running, the Helix Core Server will not respond to Helix client commands.

path

The server(s) on which the triggers should be run. One of the following:

any all servers
serverid the specified server

command

The trigger for Helix Core Server to run when the server matching path is found for the trigger type. Specify the command in a way that allows Helix Core Server account to locate and run the command. The command (typically a call to a script) must be quoted, and can take as arguments anything that your command is capable of parsing, including any applicable Helix Core Server trigger variables.

Journal-rotate triggers can process two variables: %journal% and %checkpoint%. These specify the names of the rotated journal and the new checkpoint if a checkpoint was taken. If no checkpoint was taken, %checkpoint% is an empty string.

When your trigger script is stored in the depot, its path must be specified in depot syntax, delimited by percent characters. For example, if your script is stored in the depot as //depot/scripts/myScript.pl, the corresponding value for the command field might be "/usr/bin/perl %//depot/scripts/myScript.pl%". See Storing triggers in the depot.

Example of journal-rotate trigger

This journal-rotate trigger sends an email to the Perforce administrator on journal rotation.

#!/bin/sh
# journal-rotate.sh - email Perforce administrator about journal rotation
journal="$1"
serverid="$2"
serveraddress="$3"
p4 -p $serveraddress journals -m1 | mail -s "$serveraddress - Journal Rotation to journal:$journal on server:$serverid" perforce-admin@localhost
exit 0

To use the trigger, add to your triggers table:

jnlrotate journal-rotate any "/path/to/journal-rotate.sh %journal% %serverid% %serverport%"

Example of journal-rotate-lock trigger

A journal-rotate-lock trigger that runs commands that are not Helix Core Server commands while the Helix Core Server database and journal are locked.

#!/bin/sh
#journal-rotate-lock.sh - Trigger script to run actions while the database and journal are locked.
#Perforce commands cannot be run against the Helix Server because the database is locked.
#Add external actions and commands for this trigger as required.
echo "External actions while database and journal are locked" | mail -s "Actions took place while the journal and database were locked !" perforce-admin@localhost
exit 0

To use the trigger, add to your triggers table:

jnllock journal-rotate-lock any "/path/to/journal-rotate-lock.sh"