...
Code Block | ||
---|---|---|
| ||
# for all commands in a set, define this in the command set - note the S in run_commandS_...! 'scheduling_info' => { 'run_commands_on_separate_connection' => 'true' }, # for just a specific command, set this for the command in question - no S in run_command_...! commands => [ { 'command' => 'show version', 'run_command_on_separate_connection' => 'true', }] |
Recovering from Timeouts
opConfig doesn't block indefinitely if a command on a device doesn't return a response; instead the session times out after a configurable period (see config item opconfig_command_timeout
, default 20 seconds) and the command is marked as failed.
From version 3.0.7 onwards, opConfig handles timeouts in long-lived sessions robustly; earlier versions could, under certain circumstances, get confused into associating the wrong outputs with commands if a timeout had occurred earlier during that session.
Version 3.0.7 lets you decide how to react to a command timing out:
- If your command set activates the
attempt_timeout_recovery
option, then opConfig will attempt to re-synchronise the session state for a little while longer.
It does so by looking for your device's prompt for a little while. If none is forthcoming (ie. the problematic command is still blocking progress), then opConfig will send a newline to "wake" the device.
This is repeated a few times, unless a prompt is find. - If that option is off or the resynchronisation is unsuccessful, then opConfig will close the session (and open a new one, if further commands are to be run for this node).
The value of the attempt_timeout_recovery
option must be a nonnegative integer; it defines how many wait-and-wake-up cycles opConfig should perform. Each such cycle takes up to opconfig_command_timeout
seconds.
You may set the attempt_timeout_recovery
for a all commands belonging to a set or for individual commands. Individual commands' setting override the ones for the set. The default if neither are given is zero, i.e. no extra recovery grace period.
Here is an example config set snippet, whose commands all get one extra timeout cycle for recovery, except some_brittle_command
gets up to five extra timeout periods.
Code Block |
---|
%hash = (
'my_first_config_set' => {
'os_info' => {
# ...node conditions
},
# add one extra timeout period for all commands
'scheduling_info' => {
'attempt_timeout_recovery' => 1,
},
'commands' => [
{ 'command' => "uptime" },
# any number of commands, treated equal wrt. timeouts
# but the following command is more prone to timing out, so we give it up to 5 x timeout
{ 'command' => 'some_brittle_command',
'attempt_timeout_recovery' => 5,
}, |
Privileged Mode
Many types of devices distinguish between a normal and a privileged/superuser/elevated mode, and allow certain commands only in privileged mode. opConfig needs to know whether that applies to your device and which commands are affected.
...