Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for December 5, 2013
Deadline scheduling: coming soon?
LWN.net Weekly Edition for November 27, 2013
ACPI for ARM?
LWN.net Weekly Edition for November 21, 2013
What are you going to do with SIP connections? Or with SCTP connections?
This code should properly be in the kernel, possibly integrated with conntrack module of iptables (which seems to be the ideal place for it).
TCP connection hijacking and parasites - as a good thing
Posted Aug 11, 2011 17:16 UTC (Thu) by bronson (subscriber, #4806)
Posted Aug 11, 2011 21:29 UTC (Thu) by Cyberax (✭ supporter ✭, #52523)
However, the proposed solution is what I'd call an example of how NOT to do checkpointing. I've read its code and I'd say that it conclusively proves that there should be kernel-level support for it.
Actually, it should not even be that hard! We already have /proc/pid/fd directory with the list of open handles. So we just need to add, say, /proc/pid/fd-pickle directory with the list of files, containing handles' information. So TCP connections would store their endpoints, sequence numbers, the sets of TCP flags, and probably IPSec state in these files.
Posted Aug 11, 2011 22:27 UTC (Thu) by bronson (subscriber, #4806)
Agreed, the article's technique not the best way of doing it. /proc/pid/fd-pickle seems like it would be somewhat high maint and prone to racing... Is it possible to extract the fd info and other kernel state after the process is frozen?
(asking as someone who has never actually checkpointed a process...)
Posted Aug 11, 2011 22:52 UTC (Thu) by Cyberax (✭ supporter ✭, #52523)
Race conditions would be a problem, but:
1) Checkpoint/restart is inherently racy. Network packets might got lost, connections can time out during migration, etc.
2) It can be mitigated somewhat by providing kernel-level support for freezing.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds