If you use a SSH client such as Putty connecting to the EMS Appliance with tibadm user, the connection is accepted but very soon the Putty session will get closed, with some error stack trace printed before that. ( It will be hard to capture the exception since the Putty window get closed very rapidly )
  
 If you are on Mac or Linux, using the command line based ssh client, you will be able to see the error, similar to the following:
 
 _____ INSTANCE 0 , ROLE = PRIMARY _____
Traceback (most recent call last):
  File "/opt/tibco/ems/currentversion/bin/emsa_cli.py", line 731, in emsa_cli_main
    ret=emsa_cli_work(argv)
  File "/opt/tibco/ems/currentversion/bin/emsa_cli.py", line 696, in emsa_cli_work
    EmsaCommand().cmdloop()
  File "/usr/lib/python2.7/cmd.py", line 109, in cmdloop
    self.preloop()
  File "/opt/tibco/ems/currentversion/bin/emsa_cli.py", line 346, in preloop
    g.hc.hc_show_report()
  File "/opt/tibco/ems/3.0.2/bin/emsa_health_check.py", line 830, in hc_show_report
    self.report_inst("0 -short")
  File "/opt/tibco/ems/3.0.2/bin/emsa_health_check.py", line 633, in report_inst
    state_num, state_txt, pid, readystate = ama.ems_getstate(int(ins), incl_ready=True)
  File "/opt/tibco/ems/3.0.2/bin/agent_util.py", line 921, in ems_getstate
    g.log.info("Unable to get EMSd pid.%s" % (str(text)))
  File "/opt/tibco/ems/3.0.2/bin/util.py", line 682, in info
    self._rpt(self.INFO,*args,**kw)
  File "/opt/tibco/ems/3.0.2/bin/util.py", line 798, in _rpt
    syslog.syslog(self._map_lvl(_level,self._map_syslog),text)
TypeError: [priority,] message string
ERROR:
Connection to ems7 closed.


 Another symptom is one of the EMS instances is in "active-paused" state on this appliance, and is not able to service the client connections. 

SSH Login to the EMS appliance get reset

If you see those symptoms, you will unlikely be able to resolve the situation on your own, please contact TIBCO support as soon as possible. TIBCO Support will request you to login to the problematic appliance as "admin" user and then resolve the issue from the root shell. 


It has been observed that in very rare cases, when the system time on the EMS Appliance is changed and the change is large enough to cause a missing heartbeat situation between the active & standby EMS instances ( since the default ft_timeout setting is 10, it means the time change has to be more than 10 seconds ), it may lead to such unexpected situations on the EMS Appliance. The system time change is usually an outcome of malfunction of the NTP server, since the "tibadm" user does not have the ability to change the system time.