509
edits
Changes
Jump to navigation
Jump to search
mLine 2:
Line 2: + + + + + +
no edit summary
{{Note|If a checkpoint has been created with <code>--allow-uprobes</code>, this option '''must''' be specified during restore and any relevant uprobes '''must''' remain active. This option does not create or manage uprobes; it only instructs CRIU to accept the presence of the corresponding VMAs.}}
{{Note|If a checkpoint has been created with <code>--allow-uprobes</code>, this option '''must''' be specified during restore and any relevant uprobes '''must''' remain active. This option does not create or manage uprobes; it only instructs CRIU to accept the presence of the corresponding VMAs.}}
== Description ==
User-space probes (uprobes) let you instrument functions in user processes. When a uprobe is triggered for the first time in a process, the kernel automatically creates a dedicated VMA for uprobes. This mapping is not removed even if the uprobe itself is later deleted. As a result, a process may retain a ''uprobes VMA'' long after probes have been removed.
By default, CRIU refuses to checkpoint a process that has a uprobes VMA, since restoring it without the corresponding probes can change execution semantics. The <code>--allow-uprobes</code> flag tells CRIU to proceed anyway. On restore users need to ensure that any uprobes that were active for the checkpointed processes are still installed on the restore host before resuming execution. If a restored process executes at an address that had been uprobe'd but the probe is no longer active, the kernel delivers <code>SIGTRAP</code>. Without a handler for <code>SIGTRAP</code>, the process will terminate and may produce a core dump.