Changes

== TCP connections ==

== TCP connections ==

When dumping and restoring an application having an opened tcp connection you should use the <code>--tcp-established</code> option. When this option is in use crtools will leave the connection(s) locked after dump and will require it(them) to be still locked before restore. There's a [[Simple_TCP_pair|HOWTO page]] describing how to play with this option.

When dumping and restoring an application having an opened TCP connection you should use the <code>--tcp-established</code> option. When this option is in use crtools will leave the connection(s) locked after dump and will require it(them) to be still locked before restore. Article [[Simple TCP pair]] describes how to play with this option.

== Per-task logging on restore ==

== Per-task logging on restore ==

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.

If you want to see how it works, there a nice [[Simple_loop|HOWTO page]] about it.

If you want to see how it works, check [[Simple loop]].

== 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.