Advanced usage

This page describes non-standard options that can be useful when using crtools

Evasive devices

Sometimes an application opens a device file and then somehow the path by which it was opened becomes inaccessible (e.g. overmounted or unlinked). In that case crtools cannot easily dump and restore such a process. If you consider that the path doesn't really matter when dumping your apps state you can tell crtools that a device file can be opened by any name, even if the original one is no longer accessible. The option for that is --evasive-devices

External UNIX sockets

Consider an application opens a datagram UNIX socket and connects it to some address. If you will try to dump such app and the server socket for some reason will not be taken in the dumped state (e.g. -- a task holding it is not dumped) the dump will fail. You can override this behavior by allowing crtools to disconnect the client after dump and re-connecting it back on restore by the server socket path using the --ext-unix-sk option.

TCP connections

When dumping and restoring an application having an opened tcp connection you should use the --tcp-established 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.

Per-task logging on restore

By default crtools puts all logs into one log file specified by -o/--log-file option. If you want to split restoration logs on per-pid basis you can use the --log-pid option. The ${pid} task's logs will appear in a ${log-file}.pid

Knowing a new pid of restored task

When you restore a process tree with -n/--namespaces pid option the pid of a new task will be generated by the system (since the pids sitting in image files are treated as virtual, i.e. seen in namespace ones). To find this pid out you can use the --pidfile <file> option to make crtools put the new pid into a pidfile.