Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?


Avoiding Potential Conflicts When Using Multiple Commit Scripts

When you use multiple commit scripts, each script evaluates the original candidate configuration file. Changes made by one script are not evaluated by the other scripts. This means that conflicts between scripts might not be resolved when the scripts are first applied to the configuration. The commit scripts are executed in the order they are listed at the [edit system scripts commit] hierarchy level, as illustrated in Figure 1.

Figure 1: Configuration Evaluation by Multiple Commit ScriptsConfiguration Evaluation by Multiple Commit Scripts

As an example of a conflict between commit scripts, suppose that commit script A.xsl is created to ensure that the device uses the domain name server with IP address Later, the DNS server’s address is changed to and a second script, B.xsl, is added to check that the device uses the DNS server with that address. However, script A.xsl is not removed or disabled.

Because each commit script evaluates the original candidate configuration, the final result of executing both scripts A.xsl and B.xsl depends on which DNS server address is configured in the original candidate configuration. If the now outdated address of is configured, script B.xsl changes it to However, if the correct address of is configured, script A.xsl changes it to the incorrect value

As another example of a potential conflict between commit scripts, suppose that a commit script protects a hierarchy using the protect attribute. If a second commit script attempts to modify or delete the hierarchy or the statements within the hierarchy, Junos OS issues a warning during the commit process and prevents the configuration change.

Exercise care to ensure that you do not introduce conflicts between scripts like those described in the examples. As a method of checking for conflicts with persistent changes, you can issue two separate commit commands.