This kind of problem may be related to two possible reasons:
1. The problem is caused by CLI connections.
The number of CLI connections reached the maximum number. Our maximum CLI connections is 32 and now we have 32 connections. This issue is causing the controller A’s unavailability. So, please check the CLI connections number. If there are 32 connections on controller A, please try to close some of them and then, try to log in to the controller A again.
2. Second reason is related to the CLI exit not properly.
If you accessed the controller without exit normally, we have to check this and then kill some threads. Before to perform the operation below, you must know that there should be only one connection to the controller A because the other connections will be killed.
Please run the steps below:
Step1: Enter to minisystem, then run ps –elf command. Then find “/bin/bash /OSM/script/os_debug_mode_process.sh”
Step2: There is a ppid (for picture below, it is 19035). Find the thread number which equal to this ppid(19035). Keep this thread.
Step3: Kill other thread “/ISM/cli/ismcli” which without ppid equal to the one “/bin/bash /OSM/script/os_debug_mode_process.sh”.
Command “kill -9 pid0 pid1 … pidx”
Step4: Check if other threads have already killed by command “ps –elf”
Step5: Use command “exit” to quit minisystem.
To enter into minisystem mode, please follow the steps:
3. Log in to a storage system as the super administrator and run change user_mode current_mode user_mode=developer.
admin:/>change user_mode current_mode user_mode=developer
Password:************* \\ Enter the login password. (The default password is debug@storage.)
developer:/> \\ Login succeeds.
4. Manually entering the minisystem mode: Log in to the CLI by using the IP address of a controller management network port, and run minisystem in the developer view.
Storage: minisystem> \\ Login succeeds.