2,257
edits
Changes
Jump to navigation
Jump to search
Line 32:
Line 32: + + + +
+ --shell-job
The '''crtools''' can call your hooks on various stages of dumping/restoring. These hooks are added with the <code>--action-script ''shell-code-to-execute''</code> option. When called, the <code>CRTOOLS_SCRIPT_ACTION</code> environment is set to a value determining which type of action is performed. See [[Action scripts]] for more details.
The '''crtools''' can call your hooks on various stages of dumping/restoring. These hooks are added with the <code>--action-script ''shell-code-to-execute''</code> option. When called, the <code>CRTOOLS_SCRIPT_ACTION</code> environment is set to a value determining which type of action is performed. See [[Action scripts]] for more details.
== Shell jobs C/R ==
When you run some app directly from shell (e.g. -- just launch top) it inherits session ID from bash and uses pty whose other end sits somewhere outside this shell session (e.g. in sshd or xterm). Strictly speaking this app cannot be checkpointed (since session leader, which is bash, is left outside the image, and so is the pty master). Nor it can be restored easily. But sometimes it might make sense to migrate such app by moving it to other session and attaching to different pty slave "on the fly". For such cases the <code>--shell-job</code> option should be used on both stages -- dump and restore. On dump it will allow crtools to ignore the "leaked" session leader and pty master, on restore it will tell crtools to change session, group and attach to existing pty slave.