Changes

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.

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.

== File locks C/R ==

== File locks C/R ==

Some app may use file locks for synchronization. Generally they will use flock or posix file locks, which were achieved by flock or fcntl system calls. For dump/restore, it is hard to be handled perfectly, because we can't guarantee all potential users are dumped for a specific file lock. Right now, we assume that all file lock users are taken into dump, and we should use the --file-locks option on both dump and restore stages if our app may use any file locks. Remember that file locks dump/restore is only safe for container dumping in theory.

Some app may use file locks for synchronization. Generally they will use flock or posix file locks, which were achieved by flock or fcntl system calls. For dump/restore, it is hard to be handled perfectly, because we can't guarantee all potential users are dumped for a specific file lock. Right now, we assume that all file lock users are taken into dump, and we should use the --file-locks option on both dump and restore stages if our app may use any file locks. Remember that file locks dump/restore is only safe for container dumping in theory.