2,257
edits
Changes
Jump to navigation
Jump to search
Line 10:
Line 10: − * '''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. − * '''[[External bind mounts]]''' + + + + + + + + Line 35:
Line 40: − === Task running in compat mode (x86-64) ===+ − − We don't yet support 32 bit tasks. Though it should be fixed with time. − − === 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. Line 50:
Line 49: + + + Line 55:
Line 57: − + + +
→Half-opened UNIX connections
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:
''Main article: [[External resources]]''
=== File locks ===
=== 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.
''Main article: [[File locks]]''
=== Invisible files ===
Sometimes a file name cannot be found in a filesystem. In this case criu can leave a temporary name for it.
''Main article: [[Invisible files]]''
== Cannot be dumped (yet) ==
== Cannot be dumped (yet) ==
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.
''See also: [[User-mode]]''
=== Sockets other than TCP, UDP, UNIX, packet and netlink ===
=== Sockets other than TCP, UDP, UNIX, packet and netlink ===
=== Cork-ed UDP sockets ===
=== Cork-ed UDP sockets ===
=== Files sent over unix sockets ===
{{Bug|251}}
=== SysVIPC memory segment w/o IPC namespace ===
=== SysVIPC memory segment w/o IPC namespace ===
IPC objects are not tied to any tasks. Thus once CRIU meets an IPC memory attached to a task, it requires the whole IPC namespace to be dumped as well.
IPC objects are not tied to any tasks. Thus once CRIU meets an IPC memory attached to a task, it requires the whole IPC namespace to be dumped as well.
== Dump/restore of graphical applications ===
== Dump/restore of graphical applications ==
Dumping + restoring an application connected to a "real" Xserver (e.g. on your laptop) is impossible now due to part of the app's state is in the Xserver and we don't dump this.
Dumping + restoring an application connected to a "real" Xserver (e.g. on your laptop) is impossible now due to part of the app's state is in the Xserver and we don't dump this.
[[Category:Using]]