Connection has been dropped as it reached max idle time of 60 seconds

shubhi
Tera Contributor

yesterday - last edited yesterday

Hi All,

 

During discovering Linux Tessel getting the server is getting discovered and the DB instances hosted are also getting discovered.

 In the process it reads a XML file and at times the step is successful (mostly during scheduled discovery) and fails at times(mostly during quick discovery) with below error

 

2026-02-05 02:06:14: Failed to run command: ls -w 1 <File Location> as superuser. fallback to regular userSSH connection to host, <IP Address>, has been reset unexpectedly, with failure message: Connection has been dropped as it reached max idle time of 60 seconds.

I have tried below but none of it fixed the issue:-

 

1: Checked the timeout setting at Tessel and it is set to 3 min

2: Set following properties at MID server

    mid.ssh.channel_timeout

    mid.sa.ssh.timeout

 

Kindly suggest

0 Helpfuls
  • 77 Views
1 REPLY 1

sivasankari
Tera Guru

37m ago

Hi @shubhi ,

Why Scheduled Discovery Works

With Scheduled Discovery, things move pretty smoothly. It runs a full set of probes one after another, so there’s almost always some activity happening over SSH. Since the connection stays busy and doesn’t sit idle for long, the target server has no reason to close it, and discovery usually finishes without any trouble.

 

Why Quick Discovery Fails

Quick Discovery, on the other hand, is much lighter and more selective. It runs a few probes, then pauses while it processes things like XML files or Tessell steps. During these quiet moments, the SSH session can sit idle for too long. If the Linux server has a strict idle timeout, it assumes the connection is no longer needed and drops it, which is why Quick Discovery tends to fail more often.

 

Things You need to consider before going for quick discovery for these type of devices..

 

1. The Hidden  MID Server Parameter

You mentioned setting mid.ssh.channel_timeout, but there is a more granular parameter often needed for large file reads (like XML parsing).

  • Parameter: mid.ssh.command_timeout_ms

  • Action: Add this to your MID Server's Configuration Parameters (not just properties).

  • Value: Set it to 300000 (5 minutes).

  • Why: channel_timeout handles the socket being open, but command_timeout_ms specifically dictates how long the MID Server will wait for a specific command (like reading that XML) to return data.

2. SSH Keepalives

If there is a firewall between the MID and the Target, it might be killing "idle" connections at exactly the 60-second mark. You can force the MID Server to send "heartbeats" to keep the pipe open.

Add this parameter to the MID Server:

  • Parameter: mid.ssh.keepalive.interval

  • Value: 20 (This sends a packet every 20 seconds)

3.Check Server Configuration

Check the ClientAliveInterval in the /etc/ssh/sshd_config on the target linux serve. If  It currently sets to be in  timing out at 60 seconds, which isn’t quite enough time for the MID server to process large XML files. Increasing the interval to 300 and setting the ClientAliveCountMax to 3 should keep the session stable enough for the discovery to finish.

 

And also go throught this below KBs also : mid.ssh.command_timeout_ms is not working as expected when executing ssh commands with Ssh rest via ...

 

If this works .. Please Mark it as Helpful and please Accept My Solution..

Best Regards,

SIVASANKARI S

 

0 Helpfuls