jumpserver/jumpserver · warning · GMDeviceError

close session failed

Error message

close session failed

What it means

SDF_CloseSession returned non-zero while closing the session, so the device refused or failed the session teardown. Resources on the device may or may not have been released; the error usually indicates a stale/invalid session handle.

Source

Thrown at apps/common/sdk/gm/base/session.py:74

        signature = ECCSignature((c_ubyte * len(r))(*r), (c_ubyte * len(s))(*s))

        plain_text = (c_ubyte * len(raw_data))(*raw_data)
        ret = self._driver.SDF_ExternalVerify_ECC(
            self._session,
            c_int(alg_id),
            pointer(pk),
            plain_text,
            c_int(len(plain_text)),
            pointer(signature),
        )
        if ret != 0:
            raise GMDeviceError("verify_sign", ret)
        return True

    def close(self):
        ret = self._driver.SDF_CloseSession(self._session)
        if ret != 0:
            raise GMDeviceError("close session failed", ret)

View on GitHub (pinned to 6ec464fabd)

Solutions

1. Make close() idempotent in your wrapper (track a closed flag) and only close once
2. If the device was reset, treat close failure as benign after logging the ret code
3. Wrap cleanup in try/except so a failed close doesn't mask the original error
4. Re-open device/session on next use rather than reusing a stale handle

Example fix

# before
session.close()  # in finally, may raise close session failed on second call

# after
class SafeSession:
    def __init__(self, s): self._s = s; self._closed = False
    def close(self):
        if self._closed: return
        self._closed = True
        try:
            self._s.close()
        except Exception as e:
            logging.warning("session close failed: %s", e)

try:
    session.close()
except GMDeviceError as e:
    logging.warning("close session failed code=%s (likely already closed)", e.args[1])

When it happens

Trigger: Calling session.close() twice, or after the device was reset/disconnected, or when the underlying handle was already invalidated.

Common situations: Double-close in cleanup/finally paths across exceptions; device daemon restarted while the session was open; long-lived process holding a session past device timeout.

Related errors

• open {} device failed
• generate random error
• generate ecc key pair failed
• hash init failed,alg id is {}
• hash update failed

AI-assisted analysis of jumpserver/jumpserver@6ec464fabd (2026-08-28). Data as JSON: /api/errors/5819eec76cf9cb37. Report an issue: GitHub.