Refreshing a Script from the Master Source

To refresh a local commit script with a copy from the location specified in the source statement, include the refresh statement at the [edit system scripts commit file filename.xsl] hierarchy level:

[edit system scripts commit file filename.xsl]

refresh;

When you commit the configuration and the refresh operation is performed, the copy of the XSLT file located in the /var/db/scripts/commit directory is overwritten by the copy of the file located at the URL you configure in the source statement at the same hierarchy level. If the script is enabled as described in Enabling a Commit Script and Making the Script Optional, the refreshed copy of the commit script runs immediately during the current commit operation.

To refresh all scripts from their sources, include the refresh statement at the [edit system scripts commit] hierarchy level:

[edit system scripts commit]

refresh;

If a platform has dual Routing Engines and you want the script to be refreshed on both Routing Engines, you must include the refresh statement in the configuration of both Routing Engines. The commit synchronize command does not cause the refresh statement to take effect on scripts in both Routing Engine directories.

The refresh operation happens as soon as you include the refresh statement in the configuration and issue the commit command. The refresh statement is not permanently recorded in the configuration file. In this way, it behaves like an operational mode command.

CAUTION: We recommend that you do not automate the refresh function by including the refresh statement as a commit script change element. Doing this might be tempting because it seems like a way to ensure that the most current commit script is always used. We recommend against automating the refresh function for the following reasons: Automated refresh means that the network must be in operation in order to successfully commit a configuration. If the network goes down after you make a configuration error, you are not able to recover quickly. If the software must refresh multiple commit scripts for each commit operation, the network response time might be slowed. If you automate the refresh operation, the script refresh is the last action in the current commit operation. Consequently, the updated commit script takes effect only for the subsequent commit operation. This is so because commit scripts are applied to the candidate configuration before the software copies any persistent changes generated by the scripts to the candidate configuration. For more information, see How the JUNOS Software Commit Model Works with Commit Scripts. In contrast, if you perform a refresh operation manually, the updated commit script takes effect as expected, that is, immediately after your commit the refresh statement in the configuration. If you automate the refresh operation, the refresh-from statement has no effect, because the refresh-from URL conflicts with and is overridden by the source statement URL. For information about the refresh-from statement, see Refreshing a Script from a Different Location.