From Linux Checkpoint / Restart Wiki
Revision as of 22:49, 17 February 2010 by Orenl (Talk | contribs)

Jump to: navigation, search

A feature being unsupported for checkpoint/restart could mean two things. It could mean that checkpoint on an application using the feature will fail. For instance, if an application has an open fd on an unsupported device or on a file of an unsupported fs, then checkpoint will fail with an informative error message. That is ok.

It could also mean that checkpoint will 'succeed', but restart will fail. Worse, it could mean that restart will 'succeed', but the application will misbehave after restart. For instance, we currently do not address mounts. So if an application has done 'mount(FILE1, FILE2, NULL, MS_BIND, 0)' before being checkpointed, then after restart FILE1 may no longer be bind-mounted onto FILE2.

Supported Architectures

  • x86-32, x86-64
  • PowerPC
  • s390x

Click here for information about architecture specific.

What is Implemented

Task and processess

  • multiple processes and threads
  • zombie processes
  • process ids (pid, pgid, sid)
  • futexes
  • signals
    • signal handling
    • pending signals
  • credentials
    • userid, group
    • POSIX capabilities

Namespaces Multiple namespaces are supported for:

  • user-ns
  • ipc-ns
  • uts-ns (hostname)
  • pid-ns: a single namespace is supported (extension for nested pid-ns will be done in user-space).
  • net-ns: a patch-set is being circulates.

File descriptors

  • regular files and directories:
    • ext2, ext3, ext4
    • affs, befs, bfs, btrfs, cramfs, ecryptfs, fat, freevxfs, hfs, hfsplus, hpfs, hppfs, iso, jffs2, jfs, regular, ntfs, openromfs, qnx4, reiserfs, romfs, squashfs, sysv, ubifs, udf, xfs
  • pipes, FIFOs
  • open devices:
    • /dev/null, zero, random, urandom
    • Unix98 ptys
  • special file descriptors:
    • epoll fd
    • event fd
    • timer fd
    • signal fd


  • unix sockets
  • ipv4 sockets (except time-wait sockets)

IPv4 supports live migration between hosts.


    • message queues
    • semaphores (except undo)
    • shared memory


  • Smack and SELinux LSM labels

What is NOT implemented

(please make each a link to a page describing issues, a design for solving, how we will detect it to refuse checkpoint if we will not support it, and "how ugly it will make the kernel". The table summarizes these details. )

Not Implemented Refuses to Checkpoint
Anticipated Solution Impact
mounts namespaces Yes Clean (the dirty work will be in mounts themselves)
mounts No slightly scary
Network devices Yes

Clean, planned for v20 for veth+macvlan

time-wait inet sockets No

Clean, planned for v20.

unlinked files and directories Yes

Not trivial, but shouldn't be ugly (discussion)

inotify Yes Probably gross due to watches attaching to inodes
fanotify Yes
dnotify No
FUSE Yes Clean but requires per-FUSE-filesystem support
network and distributed filesystems Yes
SYSV IPC: semaphore undo No Small, clean
netlink Yes Clean, low priority.
new, expiremental, and/or
infrastructure-oriented network protocols
Yes Ignore
file locks Yes Trivial and clean, planned for v20.
file leases Yes Trivial and clean, planned for v20.
fowner+sigio Yes Trivial and clean, planned for v20.
ptraced tasks Yes
aio Yes
time namespace N/A
restart of 64-bit task from
32-bit task and vice versa
Yes Probably in userspace
inet6 sockets Yes Previously supported, just need
to add it back in. minor.
Hardware devices
other than those mentioned above.
Includes mmap, /dev/foo, Infiniband devices
Yes (mostly) One idea
System-specific files in sysfs
(things like UUID files)
Personal tools