User guide
DataDirect Networks SFA™ OS 1.5.3.0 Release Notes Revision B | 11
• If stack commands (CLI commands starting with 'app') are issued shortly after
rebooting a controller, you may encounter communication errors displayed in the
CLI, and failure of the attempted commands. Errors may include:
o Long delays followed by:
Communication connection failed for this command
o Or this message:
ASM initialization in progress
Suggested Work Around
o After the failed controller comes back up, do not immediately issue any
CLI commands besides "show controller".
o Connect to the remaining controller and issue this command:
$ show controller
o When "show controller" shows the remote controller in the output,
focus on the ULA field in the output. The remote controller won't show
up until it is fully booted.
o If the ULA field has the value "0000000000000000", continue to wait
and not issue any CLI commands besides "show controller".
Here is example full output of the condition where you want to wait:
$ show controller
*************************
* Controller(s) *
*************************
| Up Time | |Encl| |
…
Idx|Name |Mastership|Locality| D: H: M: S|RP| ID |Idx | ULA |
…
-----------------------------------------------------------------------------------------------
…
0 A PRIMARY LOCAL 0000:20:24:34 1 0001ff0900180000 0 00000001ff0800ac
…
1 B SECONDARY REMOTE 0000:00:00:05 1 0001ff09002d0000 0 0000000000000000
…
Total Controllers: 2
o When the ULA number has something other than all zeros for the remote
controller, it is now safe to issue CLI commands and avoid the
communication problems.
• If a stack/VM is already running, and you issue a "app start stack" command
for that stack/VM, in some cases the stack/VM will be reset instead of giving an
error message that the stack is already running. [DE4510]
Suggested Work Around
If you are using scripts with the CLI command to work with stacks, it is best to
check if the stack is running or not before issuing "app start stack". That will
effectively work around this problem.