Changes

34 bytes removed ,  19:28, 26 November 2013
Reformatted
Line 1: Line 1:  
CRIU cannot dump ''all'' the possible states applications can live in. This article summarizes our experience in that area.
 
CRIU cannot dump ''all'' the possible states applications can live in. This article summarizes our experience in that area.
   −
== External resources ==
+
;External resources
    
By default CRIU allows to dump the set of processes and their resources if this set has no connections outside. However, in some situations it makes sense to ignore this external connection on dump and recreate one on restore. So, what this "connection outside" is? For example:
 
By default CRIU allows to dump the set of processes and their resources if this set has no connections outside. However, in some situations it makes sense to ignore this external connection on dump and recreate one on restore. So, what this "connection outside" is? For example:
   −
; UNIX socket
+
* UNIX socket: Application may have a UNIX socket connected to some other app and the latter one is not dumped. This is called [[external UNIX socket]].
: Application may have a UNIX socket connected to some other app and the latter one is not dumped. This is called [[external UNIX socket]].
+
* TTY, group and session:  If you start a program from shell, the tty, process group and session of the new program can be shared with the shell itself. People often meet this when they try CRIU for the first tome on a [[simple loop]].
 +
* [[TCP connection]]: This socket is literally an external connection, so CRIU should be explicitly allowed to dump one.
   −
; TTY, group and session
+
;File locks
: If you start a program from shell, the tty, process group and session of the new program can be shared with the shell itself. People often meet this when they try CRIU for the first tome on a [[simple loop]].
  −
 
  −
; [[TCP connection]]
  −
: This socket is literally an external connection, so CRIU should be explicitly allowed to dump one.
  −
 
  −
== File locks ==
      
A file lock is an object, that belongs to some filesystem. On dump it's impossible to find out whether this lock help by one task ''can'' be used by some other. Thus, CRIU doesn't dump tasks with held locks. The <code>--file-locks</code> CLI option tells CRIU to dump the lock.
 
A file lock is an object, that belongs to some filesystem. On dump it's impossible to find out whether this lock help by one task ''can'' be used by some other. Thus, CRIU doesn't dump tasks with held locks. The <code>--file-locks</code> CLI option tells CRIU to dump the lock.
   −
== Devices ==
+
;Devices
    
If a task has opened or mapped any character or block device, this typically means, it wants some connection to the hardware. In this case dump (and restore) is impossible. The exception is virtual devices like null, zero, etc. and TUN network device (used by OpenVPN).
 
If a task has opened or mapped any character or block device, this typically means, it wants some connection to the hardware. In this case dump (and restore) is impossible. The exception is virtual devices like null, zero, etc. and TUN network device (used by OpenVPN).
   −
== Tasks with debugger attached ==
+
;Tasks with debugger attached
    
CRIU uses the same API as debuggers do to get some tasks' state and this API (the ptrace one) doesn't allow for multiple debuggers to explore a task. Thus tasks under gdb or strace cannot be dumped.
 
CRIU uses the same API as debuggers do to get some tasks' state and this API (the ptrace one) doesn't allow for multiple debuggers to explore a task. Thus tasks under gdb or strace cannot be dumped.
   −
== Task from different user (for non root) ==
+
;Task from different user (for non root)
    
For security reasons, if CRIU is requested by non-root to dump some other task, it doesn't do it unless the dumpee belongs to the same user.
 
For security reasons, if CRIU is requested by non-root to dump some other task, it doesn't do it unless the dumpee belongs to the same user.
   −
== UNIX sockets with relative path ==
+
;UNIX sockets with relative path
    
For bound unix sockets kernel only provides the path with this the bind() syscall was called. If the path is relative we have no reliable way to find the exact socket location out and just refuse to dump the task.
 
For bound unix sockets kernel only provides the path with this the bind() syscall was called. If the path is relative we have no reliable way to find the exact socket location out and just refuse to dump the task.