shithub: riscv

ref: bf7e8777f391caa82705a0b64709a95672d2632c
dir: /sys/man/4/snap/

View raw version
.TH SNAP 4
.SH NAME
snap, snapfs \- create and mount process snapshots
.SH SYNOPSIS
.B snap 
[
.B -o
.I file
]
.I pid...
.PP
.B snapfs
[
.B -a
]
[
.B -m 
.I mtpt
]
.I file...
.SH DESCRIPTION
.I Snap
and 
.I snapfs
allow one to save and restore (static) process images,
usually for debugging
on a different machine or at a different time.
.PP
.I Snap
writes a snapshot 
(see 
.IR snap (6))
of the named processes to
.I file 
(default standard output).
Both memory and text images are saved.
.PP
.I Snapfs
is a file server that
recreates the
.B /proc
directories for the processes in the snapshot.
By default, it mounts the new directories
into 
.B /proc
before the current entries.
The 
.B -m
option can be used to specify
an alternate mountpoint,
while
.B -a
will cause it to mount the new directories
after the current entries.
.SH EXAMPLE
Suppose
.I page
has hung viewing Postscript on your terminal, but the author is gone for the rest of
the month and you want to make sure the process
is still around for debugging on his return.
You can save the errant processes with
.IP
.EX
snap -o page.snap `{psu | awk '$NF ~ /page|gs/ {print $2}'}
.EE
.PP
When the author returns, he can add the process images to his name space
by running
.IP
.EX
snapfs page.snap
.EE
.PP
and then use a conventional
debugger to debug them.
.SH SOURCE
.B /sys/src/cmd/snap
.SH SEE ALSO
.IR acid (1),
.IR db (1),
.IR proc (3),
.IR snap (6)
.SH BUGS
The snapshots take up about as much disk space
as the processes they contain did memory.
Compressing them when not in use is recommended,
as is storing them on a rewritable disk.
.PP
.I Pid
as a non-numeric string is unimplemented; it has to be a number.