ONTAP Discussions
ONTAP Discussions
Hi,
I am unable to ssh to a filer after accidentally leaving the systemshell logged in.
Ontap version is 8.1.4P6
Unlocked diaguser:
priv set advanced
useradmin diaguser unlock
useradmin diaguser password
******
systemshell
diag
******
and then hit ctrl-D rather than typing 'exit' first.
I am unable to access the filer via SSH or telnet since.
I was hoping that the session would time out but I've left it overnight and no joy 😞
P.S Yes I know I should'nt be playing with the system shell 😛
Any ideas without reboot/takeover?
Danny -
Some lessons we have to learn the hard way - don't do that !
: )
Use the console connection ... ?
Or the SP ?
I hope this response has been helpful to you.
At your service,
Eugene E. Kashpureff, Sr.
Independent NetApp Consultant http://www.linkedin.com/in/eugenekashpureff
Senior NetApp Instructor, IT Learning Solutions http://sg.itls.asia/netapp
(P.S. I appreciate 'kudos' on any helpful posts.)
Managed to get in, phew.
Had to get access to the systemshell prompt non-interactively:
ssh user@filer "priv set advanced; systemshell"
Log in using user "diag"
then ps -ef to identify the hung session
kill -9 to terminate it
🙂
I had this issue and was just successful in releasing the systemshell session.
I logged into the system via the sp and then did a "system console" to get access to the system. Unlocking and setting the password to diag user via the advanced privileged commands were done so that I could access the systemshell.
Here is a copy of my log, I will explain what I did under the output:
fas01*> systemshell
Data ONTAP/amd64 (fas01) (pts/1)
login: diag
Password:
Last login: Wed Jul 19 16:01:25 from localhost
WARNING: The system shell provides access to low-level
diagnostic tools that can cause irreparable damage to
the system if not used properly. Use this environment
only when directed to do so by support personnel.
fas01% ps -ef
PID TT STAT TIME COMMAND
83586 1 S 0:00.01 USER=diag LOGNAME=diag HOME=/var/home/diag SHELL=/bin
83591 1 R+ 0:00.00 USER=diag LOGNAME=diag HOME=/var/home/diag SHELL=/bin
fas01% sudo ps -ef
PID TT STAT TIME COMMAND
3474 rlm Is+ 0:00.00 TERM=vt100 login /dev/console (ontaplogin)
3472 con Is+ 0:00.01 TERM=vt100 login /dev/cuacons.auth (ontaplogin)
3473 sp. Ss+ 0:20.00 TERM=vt100 login /dev/cuasp.auth (ontaplogin)
82943 0 Is+ 0:00.01 TERM=xterm login
83585 1 Ss 0:00.01 TERM=xterm login [pam] (login)
83592 1 R+ 0:00.00 HOME=/var/home/diag MAIL=/var/mail/diag PATH=/sbin:/b
fas01% sudo ps -ef
PID TT STAT TIME COMMAND
3474 rlm Is+ 0:00.00 TERM=vt100 login /dev/console (ontaplogin)
3472 con Is+ 0:00.01 TERM=vt100 login /dev/cuacons.auth (ontaplogin)
3473 sp. Ss+ 0:20.09 TERM=vt100 login /dev/cuasp.auth (ontaplogin)
82943 0 Is+ 0:00.01 TERM=xterm login
83585 1 Is 0:00.01 TERM=xterm login [pam] (login)
83593 1 R+ 0:00.00 HOME=/var/home/diag MAIL=/var/mail/diag PATH=/sbin:/b
fas01% exit
logout
fas01*> systemshell
Data ONTAP/amd64 (fas01) (pts/1)
login: diag
Password:
Last login: Wed Jul 19 17:04:03 from localhost
WARNING: The system shell provides access to low-level
diagnostic tools that can cause irreparable damage to
the system if not used properly. Use this environment
only when directed to do so by support personnel.
fas01% sudo ps -ef
PID TT STAT TIME COMMAND
3474 rlm Is+ 0:00.00 TERM=vt100 login /dev/console (ontaplogin)
3472 con Is+ 0:00.01 TERM=vt100 login /dev/cuacons.auth (ontaplogin)
3473 sp. Ss+ 0:20.33 TERM=vt100 login /dev/cuasp.auth (ontaplogin)
82943 0 Is+ 0:00.01 TERM=xterm login
83602 1 Ss 0:00.01 TERM=xterm login [pam] (login)
83608 1 R+ 0:00.00 HOME=/var/home/diag MAIL=/var/mail/diag PATH=/sbin:/b
fas01% sudo kill -9 82943
fas01%
I logged into the system shell and ran a "ps -ef" and was only able to see current session.
Next I ran a "sudo ps -ef" to see all processes running.
I ran the "sudo ps -ef" a couple times to see if any changes presented itself and what stayed.
The TT column showed "rlm", "con", and "sp." I felt that it would not be any of these sessions. So I ignored them.
I was interested in PID 82943 and 83585. At this point I logged out of the systemshell and logged back in.
Again seeing that PID 82943 was still there, I attempted to kill the process.
Killing the process was unsuccessful as myself (obviously), so I performed the "sudo kill -9 82943".
I then attempted to log in via SSH to the system and was successful for the first time in hours.
I hope this helps someone else.