[Reliability] socket: too many open files under long-running or high-connection load

[switchtan]

Problem

The server may eventually hit socket: too many open files during long-running operation or under higher connection counts.

Current context

• The original report suspected repeated outbound dials / connection buildup
• A historical comment suggested adding read deadlines, but the issue was never documented as a concrete reproducible reliability task

Impact

• The process becomes unstable under load
• New connections may fail once file descriptors are exhausted

What is still missing

• A reliable reproduction method
• Confirmation whether the root cause is connection leak, missing timeout / close handling, or OS ulimit exhaustion

Suggested next steps

• Reproduce with sustained connection load
• Inspect active file descriptors and connection lifetime
• Add timeouts / idle cleanup if needed
• Document required ulimit -n guidance if the issue is partly environmental

Acceptance criteria

• Reproduction steps are documented
• The process no longer leaks descriptors under the tested scenario, or the remaining operational limits are documented clearly

[switchtan]

i fix a litte stuff in server.go line 60,

	```

SecureCopy(dstServer, client, auth.Encrypt)
readTimeout := 60 * 5 * time.Second
err = dstServer.SetReadDeadline(time.Now().Add(readTimeout))
if err != nil {
log.Println("setReadDeadline failed:", err)
}

[shikanon]

i fix a litte stuff in server.go line 60,

SecureCopy(dstServer, client, auth.Encrypt)
readTimeout := 60 * 5 * time.Second
err = dstServer.SetReadDeadline(time.Now().Add(readTimeout))
if err != nil {
log.Println("setReadDeadline failed:", err)
}

Yes, I am not set timeout to server.