Using the sysctl() Extension Function on Junos Devices
Junos OS and Junos OS Evolved run on *nix-like operating systems, which enable you to
retrieve various kernel state and process information.
You can invoke the sysctl() extension function in your automation scripts to
retrieve this same kernel state information, similar to how you would use the
sysctl command in the shell to retrieve these values. The
sysctl() function takes the same variable names that you would provide for
the sysctl command in the shell. The variable name is a MIB-style name, which
uses a dotted set of components. Because Junos OS is based on FreeBSD and Junos OS Evolved
runs natively on Linux, the sysctl variables and variable names are different for each OS.
You can execute the sysctl -a command in the shell to see the entire list
of available states and the corresponding names that you can provide as arguments to the
sysctl() function. However, the output can be extensive.
For example, on Junos OS, the following sample SLAX op script retrieves and prints the values
for the sysctl states kern.hostname and
hw.product.model:
version 1.1;
ns junos = "http://xml.juniper.net/junos/*/junos";
ns xnm = "http://xml.juniper.net/xnm/1.1/xnm";
ns jcs = "http://xml.juniper.net/junos/commit-scripts/1.0";
import "../import/junos.xsl";
match / {
<op-script-results> {
var $host = jcs:sysctl("kern.hostname");
expr jcs:output($host);
var $model = jcs:sysctl("hw.product.model");
expr jcs:output($model);
}
}user@router1> op sysctl-junos router1 mx960
Similarly, on Junos OS Evolved, the following sample SLAX op script retrieves and prints the
values for the sysctl states kernel.hostname and
kernel.osrelease:
version 1.1;
ns junos = "http://xml.juniper.net/junos/*/junos";
ns xnm = "http://xml.juniper.net/xnm/1.1/xnm";
ns jcs = "http://xml.juniper.net/junos/commit-scripts/1.0";
import "../import/junos.xsl";
match / {
<op-script-results> {
var $host = jcs:sysctl("kernel.hostname");
expr jcs:output($host);
var $osrelease = jcs:sysctl("kernel.osrelease");
expr jcs:output($osrelease);
}
}
user@router2-re0> op sysctl-evo router2-re0 5.2.60-yocto-standard-g9a086a2b7
For Junos OS Evolved, the return type is always a string ("s"). If you omit the type argument, the default is "s".
Junos OS and Junos OS Evolved have different sysctl state names because the
underlying operating systems are different. For example, in Junos OS, you can retrieve the
kernel state for hw.product.model, but Junos OS Evolved does not have a
similar sysctl variable name. In those cases, you can use RPCs or other means
to retrieve the same information.
For example, the following SLAX op script executes the
get-software-information RPC to retrieve the model name on Junos OS
Evolved, which is equivalent to returning the sysctl
hw.product.model value on Junos OS.
version 1.1;
ns junos = "http://xml.juniper.net/junos/*/junos";
ns xnm = "http://xml.juniper.net/xnm/1.1/xnm";
ns jcs = "http://xml.juniper.net/junos/commit-scripts/1.0";
import "../import/junos.xsl";
match / {
<op-script-results> {
var $local = jcs:open();
var $rpc = "get-software-information";
var $result = jcs:execute($local, $rpc);
expr jcs:output($result/product-model);
}
}
user@router2-re0> op sysctl-evo-model ptx10008
If you invoke the sysctl() function in a script and specify a nonexistent
sysctl variable name, Junos OS does not generate an error, but Junos OS Evolved generates a
sysctl error: No such file or directory error.
For example, suppose the sysctl() function requests the value for
hw.product.model, which is a valid sysctl variable name on Junos OS but is
not a valid sysctl variable name on Junos OS Evolved. If you execute the script on a device
running Junos OS Evolved, the script emits the following output:
user@router2-re0> op sysctl-evo-invalid error: sysctl error: No such file or directory error: xmlXPathCompiledEval: No result on the stack. error: runtime error: file /var/db/scripts/op/sysctl-evo-invalid.slax line 10 element variable error: Failed to evaluate the expression of variable 'model'.