.TH SNAP 4.SH NAMEsnap, 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][.B -s.I service].I file....SH DESCRIPTION.I Snapand .I snapfsallow one to save and restore (static) process images,usually for debuggingon a different machine or at a different time..PP.I Snapwrites a snapshot (see .IR snap (6))of the named processes to.I file (default standard output).If .I pidis a text stringrather than a process id,.I snapwill save all processes withthat name thatare owned by the current user.Both memory and text images are saved..PP.I Snapfsis a file server thatrecreates the.B /procdirectories for the processes in the snapshot.By default, it mounts the new directoriesinto .B /procbefore the current entries.The .B -moption can be used to specifyan alternate mountpoint,while.B -awill cause it to mount the new directoriesafter the current entries.The .B -soption causes it to serve requests via.BI /srv/ service..SH EXAMPLESuppose.I pagehas hung viewing Postscript on your terminal, but the author is gone for the rest ofthe month and you want to make sure the processis still around for debugging on his return.You can save the errant processes with.IP.EXsnap -o page.snap `{psu | awk '$NF ~ /page|gs/ {print $2}'}.EE.PPWhen the author returns, he can add the process images to his name spaceby running.IP.EXsnapfs page.snap.EE.PPand then use a conventionaldebugger 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 BUGSThe snapshots take up about as much disk spaceas the processes they contain did memory.Compressing them when not in use is recommended,as is storing them on a rewritable disk..PP.I Pidas a non-numeric string is unimplemented; it has to be a number.
.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
]
[
.B -s
.I service
]
.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).
If
.I pid
is a text string
rather than a process id,
.I snap
will save all processes with
that name that
are owned by the current user.
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.
The
.B -s
option causes it to serve requests via
.BI /srv/ service.
.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.