From: query <query.cdac@gmail.com>
To: Glynn Clements <glynn@gclements.plus.com>
Cc: linux-admin@vger.kernel.org
Subject: Re: Preventing SSH timeouts . Some clarification needed
Date: Fri, 11 Jun 2010 12:52:00 +0530 [thread overview]
Message-ID: <AANLkTinx_mZNk42Ha184R2pU0oNXraKvLrZ2opMpqO96@mail.gmail.com> (raw)
In-Reply-To: <19473.31451.610893.474483@cerise.gclements.plus.com>
Clements , thanks for all the detailed explanation . I think things
are clear to me now . Will try to apply the changes in sshd_config .
And Thanks Michael and all for providing insights on the issue .
Thanks
Zaman
On Fri, Jun 11, 2010 at 5:22 AM, Glynn Clements
<glynn@gclements.plus.com> wrote:
>
> query wrote:
>
>> >> okay..Thanks for the clarification . Since the host sometimes
>> >> continues to remain busy for around 2 hours ,
>> >
>> > Busy to the point that ssh/sshd doesn't get *any* CPU time for 2
>> > hours? Either you're misunderstanding something, or that's a seriously
>> > misconfigured server.
>>
>> That is my misunderstanding only .The CPU is 100% busy but it is not
>> that all the 100% is being utilized by our process and no other
>> process is getting the CPU time. I will calculate an optimal value by
>> going through once more over the system during the peak CPU
>> utilization .
>> But I am still confused who is terminating the connection in our case
>> and on how is calculating the timeout value.
>> AS you mentioned in your first comment that it the kernel who is
>> terminating the connection , but based on what it is terminating
>> the connection . As you said earlier , Keep-alive allows us to detect
>> that a host is unreachable (e.g.
>> network failure, system crash, power failure, etc) , It is not going
>> to kill sshd ,
>
> It won't kill sshd; however, if packets (data or keep-alives) which
> are sent to the client stop being acknowledged, operations on the
> socket will eventually fail with ETIMEDOUT. At this point, sshd will
> close the connection of its own accord.
>
> The relevant setting is /proc/sys/net/ipv4/tcp_retries2:
>
> tcp_retries2 (integer; default: 15; since Linux 2.2)
> The maximum number of times a TCP packet is retransmitted in
> established state before giving up. The default value is 15,
> which corresponds to a duration of approximately between 13 to
> 30 minutes, depending on the retransmission timeout. The
> RFC 1122 specified minimum limit of 100 seconds is typically
> deemed too short.
>
> The initial retransmission timeout is determined by the measured
> round-trip latency for the connection. Subsequent retransmissions
> occur at exponentially increasing intervals, capped at 120 seconds.
>
> If keep-alives aren't being sent, the connection can only time out as
> a result of data being sent. If keep-alives are being sent, a timeout
> can occur even if the connection is otherwise idle (that's the purpose
> of keep-alives).
>
> --
> Glynn Clements <glynn@gclements.plus.com>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
prev parent reply other threads:[~2010-06-11 7:22 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-08 9:36 Preventing SSH timeouts . Some clarification needed query
2010-06-08 9:48 ` Michal Nazarewicz
[not found] ` <AANLkTimTjSOmbj_ac4iiUMaHRuvp1-ljW-FUGAQbb1qt@mail.gmail.com>
[not found] ` <87k4q9g31y.fsf@erwin.mina86.com>
2010-06-08 15:10 ` query
2010-06-08 19:48 ` Michal Nazarewicz
2010-06-09 5:33 ` query
2010-06-08 10:39 ` Glynn Clements
2010-06-08 15:10 ` query
2010-06-08 16:19 ` Glynn Clements
2010-06-09 6:44 ` query
2010-06-09 8:15 ` Adam T. Bowen
2010-06-09 10:14 ` Glynn Clements
[not found] ` <AANLkTimDS_IalexVnOKtOuKN8fz13rFumHV8TrjEGtph@mail.gmail.com>
[not found] ` <19471.47290.566464.539451@cerise.gclements.plus.com>
2010-06-10 6:02 ` query
2010-06-10 13:03 ` Glynn Clements
2010-06-10 16:35 ` query
2010-06-10 23:52 ` Glynn Clements
2010-06-11 7:22 ` query [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AANLkTinx_mZNk42Ha184R2pU0oNXraKvLrZ2opMpqO96@mail.gmail.com \
--to=query.cdac@gmail.com \
--cc=glynn@gclements.plus.com \
--cc=linux-admin@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).