From: Oren Laadan <orenl@cs.columbia.edu>
To: Chris Friesen <cfriesen@nortel.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>,
Greg Kurz <gkurz@fr.ibm.com>,
Linux-Kernel <linux-kernel@vger.kernel.org>,
Dave Hansen <dave@linux.vnet.ibm.com>,
containers@lists.osdl.org,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Ingo Molnar <mingo@elte.hu>
Subject: Re: C/R without "leaks"
Date: Thu, 16 Apr 2009 14:39:05 -0400 [thread overview]
Message-ID: <49E77B49.3020102@cs.columbia.edu> (raw)
In-Reply-To: <49E774B1.5060505@nortel.com>
Chris Friesen wrote:
> Alexey Dobriyan wrote:
>> On Thu, Apr 16, 2009 at 12:42:17AM +0200, Greg Kurz wrote:
>>> On Wed, 2009-04-15 at 23:56 +0400, Alexey Dobriyan wrote:
>>
>>>> There are sockets and live netns as the most complex example. I'm not
>>>> prepared to describe it exactly, but people wishing to do C/R with
>>>> "leaks" should be very careful with their wishes.
>>> They should close their sockets before checkpoint and find/have some way
>>> to reconnect after. This implies some kind of C/R awareness in the code
>>> to be checkpointed.
>>
>> How do you imagine sshd closing sockets and reconnecting?
>
> Don't you already have to handle the case where an sshd connection is
> checkpointed, then the system is shutdown and the restore doesn't happen
> until after the TCP timeout?
Any connection in that case is, of course, lost, and it's up to the
application to do something about it. If the application relies on
the state of the connection, it will have to give up (e.g. sshd, and
ssh, die).
However, there are many application that can withstand connection
lost without crashing. They simply retry (web browser, irc client,
db clients). With time, there may be more applications that are
'c/r-aware'.
Moreover, in some cases you could, on restart, use a wrapper to
create a new connection to somewhere (*), then ask restart(2) to
use that socket instead of the original, such that from the user
point of view things continue to work well, transparently.
(*) that somewhere, could be the original peer, or another server,
if it has a way to somehow continue a cut connection, or a special
wrapper server that you right for that purpose.
Oren.
next prev parent reply other threads:[~2009-04-16 18:41 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-14 3:43 Creating tasks on restart: userspace vs kernel Oren Laadan
2009-04-14 9:59 ` Ingo Molnar
2009-04-14 14:53 ` Oren Laadan
2009-04-14 16:16 ` Serge E. Hallyn
2009-04-14 16:36 ` Alexey Dobriyan
2009-04-14 16:46 ` Alexey Dobriyan
2009-04-14 18:40 ` Oren Laadan
2009-04-14 19:59 ` Alexey Dobriyan
2009-04-14 20:10 ` Oren Laadan
2009-04-14 21:01 ` Alexey Dobriyan
2009-04-15 19:56 ` C/R without "leaks" (was: Re: Creating tasks on restart: userspace vs kernel) Alexey Dobriyan
2009-04-15 21:38 ` C/R without "leaks" Oren Laadan
2009-04-22 0:16 ` Nathan Lynch
2009-04-15 22:42 ` C/R without "leaks" (was: Re: Creating tasks on restart: userspace vs kernel) Greg Kurz
2009-04-16 16:12 ` Alexey Dobriyan
2009-04-16 18:10 ` C/R without "leaks" Chris Friesen
2009-04-16 18:39 ` Oren Laadan [this message]
2009-04-17 9:15 ` Greg Kurz
2009-04-17 9:48 ` Oren Laadan
2009-04-17 12:25 ` Greg Kurz
2009-04-17 8:46 ` C/R without "leaks" (was: Re: Creating tasks on restart: userspace vs kernel) Greg Kurz
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=49E77B49.3020102@cs.columbia.edu \
--to=orenl@cs.columbia.edu \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=cfriesen@nortel.com \
--cc=containers@lists.osdl.org \
--cc=dave@linux.vnet.ibm.com \
--cc=gkurz@fr.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=torvalds@linux-foundation.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