Discovery: getDeviceInfo fails with "Connection Timed Out" when using ksh (^C in the session log) or zsh

Version 4
    Share This:

    This document contains official content from the BMC Software Knowledge Base. It is automatically updated when the knowledge article is modified.


    BMC Discovery


    BMC Discovery 11.3


    BMC Discovery



    A Discovery scan starts, and the ssh connection is established. The shell reported by the session log is ksh (or zsh ):

     $ echo START $SHELL END
     START /bin/ksh END

    and the discovery log says:

    DEBUG: ssh: checkSessionReady: Session ready. Shell is /bin/ksh

    The commands start being executed and in the middle of the platform script, for no obvious reason, the prompt does not come back, and getDeviceInfo fails with Connection Timed out.

    The session log shows that all the getDeviceInfo commands completed, but then it appears that the discovery ran out of time (there are three ^C entries at the end):

    os: Red Hat Enterprise Linux Server release 6.1 (Santiago)
    os_arch: x86_64

    The discovery log shows normal progress until these messages:

     discovery.session.ssh: DEBUG: expectAndWait: expecting ['([#>%\\$])(\\s*\x1b\\[(\\d+;)*\\d+m)?', <class 'pexpect.EOF'>, <class 'pexpect.TIMEOUT'>]
     common.delayedPerform: DEBUG: 36901:Calling (<bound method Scavenger.scavenge of <common.scavenger.Scavenger object at 0x10102a50>>, (), {})
     common.delayedPerform: DEBUG: 36901:unregister non existent uid
     common.delayedPerform: DEBUG: 36902: register delay 10.000000, (<bound method Scavenger.scavenge of <common.scavenger.Scavenger object at 0x10102a50>>, (), {})
     common.scavenger: DEBUG: Scavenger considered 1 objects in 0.7288 ms and destroyed 0.
     common.delayedPerform: DEBUG: waiting for 9.995506
     common.delayedPerform: DEBUG: 36902:Calling (<bound method Scavenger.scavenge of <common.scavenger.Scavenger object at 0x10102a50>>, (), {})
     common.FSM: DEBUG: calling doEvent(...)
     common.FSM: DEBUG: event = <class 'pexpect.TIMEOUT'>

    Here is another example:

    api.audit: DEBUG: queryDeviceInfo(): Trying command 'device_info'
    discovery.session: DEBUG: ssh: executeCommand: Sending cmd
    discovery.session: DEBUG: ssh: sendCommandList: BLOCK style: sending block
    common.delayedPerform: DEBUG: waiting for 9.976304
    discovery.session: DEBUG: ssh: expectAndWait: expecting ['(?i)\\bp?assword( for [^:]+)?\\s*:', '__TIDEWAY_CMD_END__', <class 'discovery.session_statetable.EOF'>, <class 'discovery.session_statetable.Timeout'>]
    common.FSM: DEBUG: calling doEvent(...)
    common.FSM: DEBUG: event = __TIDEWAY_CMD_END__
    common.FSM: DEBUG: calling setState((<common.FSM.FSM object at 0x2aaab57edb90>, 'WAIT_FOR_PROMPT'), {})
    discovery.session: DEBUG: ssh: expectAndWait: expecting ['[#>%\\$]', <class 'discovery.session_statetable.EOF'>, <class 'discovery.session_statetable.Timeout'>]

    and then it times out 3 minutes later (or whatever value the session timeout is set to):

    discovery.session: DEBUG: ssh: executeCommand: Connection timed out
    discovery.session: DEBUG: ssh: killChild: Killing child with PID 26920
    discovery.session: DEBUG: ssh: killChild: Sending '\x03' 3 times
    discovery.session: DEBUG: ssh: expectAndWait: expecting ['[#>%\\$]']

    In one case where the login user was using zsh, the session log is filled with weird control characters and other signs of problems such as:
    zsh: command not found:
    zsh: bad option: -a

    and at the end just drops:
    Connection to closed.




    Legacy ID:KA358097


    This information may indicate that Discovery waited for a prompt and it was not there (see KA 000020159), or some other problem with script processing.

    The root cause is the shell. The   doc at says:

    Shell support
    BMC Discovery is tested to work with Bourne and Bourne-compatible shells. Support for other shells such as the Korn shell is best effort only. The product has been sporadically tested and might work but with known issues, and BMC might not fix bugs that affect these shells.

    Note that other unusual behaviors might result from using ksh or zsh.

    The recommendation is to try the "force subshell" option in the credential (see the same doc mentioned above). Another option is to
    change the user account profile to use sh. 


    Article Number:


    Article Type:

    Solutions to a Product Problem

      Looking for additional information?    Search BMC Support  or  Browse Knowledge Articles