commit

Execute the commit command without any options to commit the configuration changes to the configuration database.

Complete commit in two steps of preparing the configuration for commit and later activating the configuration. This enables you configure a number of devices and simultaneously activate the configurations on multiple devices.

Commit the configuration and, if the configuration contains no errors and the commit succeeds, exit from configuration mode.

(Optional) Save software configuration changes and activate the configuration at a future time, or upon reboot. The variable string is reboot or the future time to activate the configuration changes. Enclose the string value (including reboot) in quotation marks (“ ”). You can specify time in two formats:

• A time value in the form hh:mm[:ss] (hours, minutes, and optionally seconds)— Commit the configuration at the specified time, which must be in the future by at least one minute but before 11:59:59 PM on the day the commit at configuration command is issued. Use 24-hour time for the hh value; for example, 04:30:00 is 4:30:00 AM, and 20:00 is 8:00 PM. The time is interpreted with respect to the clock and time zone settings on the device.

• A date and time value in the form yyyy-mm-dd hh:mm[:ss] (year, month, date, hours, minutes, and, optionally, seconds)—Commit the configuration at the specified day and time, which must be after the commit at command is issued. Use 24-hour time for the hh value. For example, 2003-08-21 12:30:00 is 12:30 PM on August 21, 2003. The time is interpreted with respect to the clock and time zone settings on the router.

  For example, commit at "18:00:00". For date and time, include both values in the same set of quotation marks. For example, commit at "2018-03-10 14:00:00".

• A commit check is performed when you issue the commit at configuration mode command. If the result of the check is successful, then the current user is logged out of configuration mode, and the configuration data is left in a read-only state. No other commit can be performed until the scheduled commit is completed.

  Note:

  If Junos OS fails before the configuration changes become active, all configuration changes are lost.

  You cannot enter the commit at configuration mode command when there is a pending reboot.

  You cannot enter the request system reboot command once you schedule a commit operation for a specific time in the future.

  You cannot commit a configuration when a scheduled commit is pending. For information about how to use the clear system commit command to cancel a scheduled commit configuration, see clear system commit.

(Optional) Verify the syntax of the configuration, but do not activate it.

(Optional) Add a comment that describes the committed configuration. The comment can be as long as 512 bytes and must be typed on a single line. You cannot include a comment with the commit check command. Enclose comment-string in quotation marks (" "). For example, commit comment "Includes changes recommended by user".

(Optional) Require that the commit be confirmed within the specified amount of time.

• To confirm a commit, enter either a commit or commit check command.

• If the commit is not confirmed within the time limit, the configuration rolls back automatically to the precommit configuration and a broadcast message is sent to all logged-in users. To show when a rollback is scheduled, enter the show system commit command. The allowed range is 1 through 65,535 minutes, and the default is 10 minutes.

• The timeout for the commit confirmed command is calculated based on the system time, when the commit confirmed command is issued. In case the system time is modified while a commit confirmed is pending, the remaining time until commit execution might get shortened (in case the old system time is behind) or prolonged (in case the old system time is ahead) from the intended interval.

• In Junos OS Release 11.4 and later, you can also use the commit confirmed command in the [edit private] configuration mode.

(Optional) Configure the commit command to run without synchronization. This can be useful in situations, for example, where a Routine Engine configuration is corrupted such that a commit synchronization is not possible or will block the commit.

• This option allows you to commit only on the current Routing Engine even if set system commit synchronize is configured.

• This option overrides the commit peer-synchronize configuration as well. If you have configured the commit synchronize using set system commit synchronize and then use the command commit no-synchronize, the commit will happen only on the device issuing the command.

• When using commit synchronize, the commit is first done in the other Routing Engine and then in the current one. If the other Routine Engine is corrupted, the commit will fail. In such cases, you can use commit no-synchronize. This command cannot be configured using set. It can only be run.

(Optional) Configure the commit command to automatically perform a peers-synchronize action between peers. The local peer (or requesting peer) on which you enable the peers-synchronize statement copies and loads its configuration to the remote (or responding) peer. Each peer then performs a syntax check on the configuration file being committed. If no errors are found, the configuration is activated and becomes the current operational configuration on both peers.

(Optional) If your router has two Routing Engines, you can manually direct one Routing Engine to synchronize its configuration with the other by issuing the commit synchronize command. The Routing Engine on which you execute this command (the request Routing Engine) copies and loads its candidate configuration to the other Routing Engine (the responding Routing Engine). Both Routing Engines then perform a syntax check on the candidate configuration file being committed. If no errors are found, the configuration is activated and becomes the current operational configuration on both Routing Engines.

The synchronize option has the following two additional options:

• force—(Optional) Enforce commit synchronization on the Routing Engines by using the force option.

  The commit synchronize command does not work if the responding Routing Engine has uncommitted configuration changes. You can enforce commit synchronization on the Routing Engines by using the force option. When you issue the commit synchronize command with the force option from one Routing Engine, the configuration sessions on the other Routing Engine are terminated and the configuration is synchronized with that on the Routing Engine from which you issued the command.

• scripts—(Optional) Synchronize all commit, event, lib, op, and SNMP scripts from the requesting Routing Engine to the responding Routing Engine and commit and synchronize the configuration.

  If the commit check operation fails for the requesting Routing Engine, the process stops, and the scripts are not copied to the responding Routing Engine. If the commit check or commit operation fails for the responding Routing Engine, the scripts are still synchronized, since the synchronization occurs prior to the commit check operation on the responding Routing Engine.

• If the load-scripts-from-flash statement is configured at the [edit system scripts] hierarchy level for the requesting Routing Engine, the device synchronizes the scripts from flash memory on the requesting Routing Engine to flash memory on the responding Routing Engine. Otherwise, the device synchronizes the scripts from the hard disk on the requesting Routing Engine to the hard disk on the responding Routing Engine. The device synchronizes all scripts regardless of whether they are enabled in the configuration or have been updated since the last synchronization.

(Optional) Prepare the configuration to activate at a later stage. During the preparation stage, all the required files and databases are generated and the configuration is validated. A file is created that indicates if the commit is pending for activation. In the event of failure during the preparation stage, the log message commit preparation failed is generated.

(Optional) Commit newly enabled scripts during the commit operation and push scripts to the other Routing Engine.

(Optional) Use the | (pipe)) options to filter the output of the commit command.