*nix Documentation Project
·  Home
 +   man pages
·  Linux HOWTOs
·  FreeBSD Tips
·  *niX Forums

  man pages->IRIX man pages -> cpr (1)              



cpr(1)									cpr(1)

NAME    [Toc]    [Back]

     cpr - checkpoint and restart processes; info query; delete	statefiles
     cview - graphical user interface for checkpoint and restart (CPR)

SYNOPSIS    [Toc]    [Back]

     cpr -c pathname -p	id[:type],[id[:type]...] [ -fgku ]
     cpr -i pathname ...
     cpr [ -j ]	-r pathname ...
     cpr -D pathname ...

     cview [ -display XwindowDisplay ]

DESCRIPTION    [Toc]    [Back]

     IRIX Checkpoint and Restart (CPR) offers a	set of user-transparent
     software management tools,	allowing system	administrators,	operators, and
     users with	suitable privileges to suspend a job or	a set of jobs in midexecution,
	and restart them later on.  The	jobs may be running on a
     single machine or on an array of networking connected machines.  CPR may
     be	used to	enhance	system availability, provide load and resource control
     or	balancing, and to facilitate simulation	or modeling.

     The cview command provides	an X Windows interface to CPR, and is composed
     of	two decks:  the	Checkpoint Control Panel and the Restart Control
     Panel.  See the cview Help	menu for more information.

OPTIONS    [Toc]    [Back]

     Use the -c, -i, -r, and -D	options	to:  create, query, restart, and
     delete checkpoints, respectively.

   Create Checkpoint    [Toc]    [Back]
     -c	  Checkpoint a process or set of processes and create a	statefile
	  directory in pathname, based on the process id specified after -p.

     -f	  Force	overwrite of an	existing pathname, so existing statefiles are
	  replaced with	new ones according to the new checkpoint.

     -g	  Have checkpoint target processes continue running (go) after this
	  checkpoint is	finished.  This	overrides the default WILL policy, and
	  the WILL policy specified in a user's	CPR attribute file.

     -k	  Kill checkpoint target processes after this checkpoint is finished.
	  This is the default WILL policy, but overrides a CONT	setting	in the
	  user's CPR attribute file (see below).

     -u	  Use this option only when issuing a checkpoint immediately before an
	  operating system upgrade.  This forces a save	of all executable
	  files	and DSO	libraries used by the current processes, so that
	  target processes can be restarted in an upgraded environment.	 This
	  flag must be used again if restarted processes must be recursively
	  checkpointed in the new environment.

									Page 1

cpr(1)									cpr(1)

     -p	  Specifies the	process	or set of processes to checkpoint.  Processes
	  may have any type in the following list:

	  PID	  for Unix process and POSIX pthread ID	(the default type)
	  GID	  for Unix process group ID
	  SID	  for Unix process session ID; see termio(7)
	  ASH	  for IRIX Array Session ID; see array_services(5)
	  HID	  for process hierarchy	(tree) rooted at that PID
	  SGP	  for IRIX sproc shared	group; see sproc(2)

     If	type is	not given in a checkpoint request, id is interpreted to	use
     its default type PID.  Here are some examples:

      cpr -c ckpt01 -p 1111
      cpr -c ckpt02 -p 2222:GID

     The first example checkpoints a process with PID 1111 to the statefile
     directory ./ckpt01.  The second example checkpoints all processes with
     process group ID 2222 to the statefile directory ./ckpt02.

     Users may checkpoint a random set of processes into one statefile by
     specifying	more comma-separated ids (with optional	type) after the	-p
     flag, as in this example:

      cpr -c ckpt03 -p 111:GID,222,333:SID

     This saves	all processes with process group ID 111, process ID 222, and
     process session ID	333 into the statefile directory ./ckpt03.

     Only the super user and the owner of a process or set of processes	(the
     checkpoint	owner) can checkpoint the targeted processes.

   Checkpoint Info    [Toc]    [Back]
     -i	statefile ...
	  Provides information about existing CPR statefile(s):	 the statefile
	  revision number, process name(s), credential information of the
	  process, current working directory, open file	information, and the
	  time when the	checkpoint was performed.

   Restart Checkpoint    [Toc]    [Back]
     -r	statefile ...
	  Restarts a process or	set of processes from the statefile.  If a
	  restart involves more	than one processes, the	restart	on all
	  processes has	to succeed before any process starts running;
	  otherwise, all restarts are aborted.

     -j	  Make processes interactive and job controllable.  If a checkpoint is
	  issued against an interactive	process	or a group of processes	rooted
	  at an	interactive process, it	can be restarted interactively with
	  the -j option.  It runs in the foreground, even the original process
	  ran in the background.  Users	may issue job control signals to
	  background the process if desired.  An interactive job is defined as

									Page 2

cpr(1)									cpr(1)

	  a process with a controlling terminal; see termio(7).	 Only one
	  controlling terminal is restored even	if the original	process	had
	  multiple controlling terminals.

     Note that statefile remain	unchanged after	a restart unless users use the
     -D	option to delete the statefile.

     A restart may fail	due to a number	of reasons including:

     Resource Limitation:  This	happens	when the original PID is not available
     and the application may not use another PID; or when certain
     application-related files,	binaries, or libraries are no longer available
     on	the system if the REPLACE or SUBSTITUTE	option was not set at
     checkpoint	time for missing files;	or when	other system resources such as
     memory or disk run	out due	to restart.

     Security and Data Integrity:  Restart fails if the	restarting user	lacks
     the proper	permission to restart the statefile, or	if the restart
     destroys or replaces data without proper permission.  The basic rule is
     that only the superuser and checkpoint owner can restart the processes.
     This implies that if the superuser	checkpoints a process owned by a
     regular user, only	the superuser has permission to	restart	it.

     Other Fatal Failures:  If important parts of the original processes
     cannot be restored	due to any other reasons.

   Delete Checkpoint    [Toc]    [Back]
     -D	statefile ...
	  Delete one or	more statefiles.  After	a successful restart,
	  statefiles might no longer be	needed,	and may	be removed.  The
	  delete option	removes	all files associated with the statefile,
	  including saved open files, mapped files, pipe data, etc.  Only the
	  superuser and	checkpoint owner may delete a statefile	directory.

   Cview Window    [Toc]    [Back]
     How to Checkpoint:	 Under the STEP	I button, select a process or set of
     processes from the	list.  To checkpoint a process group, a	session	group,
     an	IRIX array session, a process hierarchy, or an sproc shared group,
     select a category from the	Individual Process drop-down menu.  In the
     filename field below, enter the name of a directory for storing the
     statefile.	 Click the STEP	II button if you want to change	checkpoint
     options, such as whether to exit or continue the process, or control open
     file and mapped file dispositions.	 Click the STEP	III OK button to
     initiate the checkpoint, or the Cancel Checkpoint button to discontinue.

     How to Restart:  Click the	Restart	Control	Panel tab at the bottom	of the
     cview window.  From the scrolling list of files and directories, select a
     statefile to restart.  Note that all files	and directories	are shown, not
     just statefile directories.  If a statefile is located somewhere besides
     your home directory, change directories using the icon finder at the top.
     Select any	options	you want, such as whether to retain the	original
     process ID, whether to restore the	original working directory, or whether

									Page 3

cpr(1)									cpr(1)

     to	restore	the original root directory.  Click the	OK Go Restart button
     to	initiate restart.

     Querying a	Statefile:  From the scrolling list of files and directories,
     select a statefile	to query.  At the bottom of the	cview window, click
     the Tell Me More About This Statefile button.

     Deleting a	Statefile:  From the scrolling list of files and directories,
     select a statefile	to delete.  At the bottom of the cview window, click
     the Remove	This Statefile button.

     Two signals, SIGCKPT and SIGRESTART, are designed to give application
     programs adequate warning to take special action upon checkpoint or at
     restart time.  The	default	action is to ignore both signals unless
     applications catch	the signals; see signal(2).  By	catching the signals,
     an	application gets an opportunity	to set up its signal handler and be
     prepared for checkpoint or	restart.  An application can clean up files,
     flush buffers, close or reconnect socket connections, etc.

     Meanwhile,	the main CPR process waits as long as necessary	for the
     application to finish the signal handling,	before cpr proceeds with
     further checkpoint	activities after SIGCKPT.  At restart the first	thing
     an	application runs is the	SIGRESTART signal handler, if the application
     is	catching the signal.

     However, these two	signals	(SIGCKPT and SIGRESTART) are not recommended
     for direct	use by applications wishing to be checkpointed.	 Instead,
     applications call atcheckpoin
 to	register event
     handlers for checkpoint and restart, and activate signal handling.	 This
     is	especially important for applications that need	to register multiple
     callback handlers for checkpoint or restart events.

     Warning: if applications catch the	two CPR	signals	directly, it may undo
     all of the	CPR signal handler registration	provided by atcheckpoint(3C)
     and atrestart(3C),	including handlers that	some libraries reserve without
     the application programmer's knowledge.

FILES    [Toc]    [Back]

     statefile	      Directory	containing images of checkpointed processes
     $HOME/.cpr	      User-configurable	options	for checkpoint and restart
     /etc/cpr_proto   Attribute	file prototype for creating $HOME/.cpr

     /usr/lib/X11/app-defaults/Cview  Application defaults file
     /usr/lib/images/Cview.icon	      Image for	minimized window

     The $HOME/.cpr files control CPR behavior,	and consist of one or more
     CKPT attribute definitions, each in the following form:

	  CKPT IDtype IDvalue {
	      policy:  instance:  action

									Page 4

cpr(1)									cpr(1)


     The IDtype	is the same as for the -c option; see above.  The IDvalue is
     the process or process set	ID.  Both can be given as a star (*) to
     represent any IDtype or IDvalue.

     Here are the policy keywords and what they	control:

      FILE   policies of handling open files
      WILL   actions on	the original process after checkpoint
      CDIR   policy on the original working directory; see chdir(2)
      RDIR   policy on the original root directory; see	chroot(2)
      FORK   policy on original	process	ID

     FILE takes	an instance, which is the filename.

     FORK can take instance PID.  If no	instance is specified, the specified
     action is applied to all instances.

     FILE offers the following action keywords:

      MERGE	 upon restart, reopen the file and seek	to the previous	offset
      IGNORE	 upon restart, reopen the file as originally opened
      APPEND	 upon restart, reopen the file for appending
      REPLACE	 save file at checkpoint; replace the original file at restart
      SUBSTITUTE save file at checkpoint; at restart, open the saved file as
		 an anonymous substitute, not touching the original file

     WILL offers the following action keywords:

      EXIT	 the original process exits after checkpoint (default action)
      CONT	 the original process continues	to run after checkpoint

     CDIR and RDIR offer the following action keywords:

      REPLACE	 restore original current working directory or root directory
					  (default action)
      IGNORE	 ignore	original current working directory or root directory;
		 restart according to new process environment

     FORK offers the following action keywords:

      ORIGINAL	 attempt to recover the	original process ID (default action)
      ANY	 it is acceptable to restart using any process ID

NOTES    [Toc]    [Back]

     Due to the	nature of UNIX checkpoint and restart, it is impossible	to
     claim that	everything a process owns or connects with can be restored.
     The bullet	items below attempt to list what is supported, and what	is
     known to be not supported.	 For system objects not	covered	below, safety
     decisions must be made by application programmers and users.

									Page 5

cpr(1)									cpr(1)

     The following system objects are checkpoint-safe:

     o	  UNIX processes, process groups, terminal control sessions, IRIX
	  array	sessions, process hierarchies, sproc(2)	groups,	POSIX pthreads
	  (pthread_create(3P)) and random process sets

     o	  all user memory area,	including user stack and data regions

     o	  system states, including process and user information, signal
	  disposition and signal mask, scheduling information, owner
	  credentials, accounting data,	resource limits, current directory,
	  root directory, locked memory, and user semaphores

     o	  system calls,	if applications	handle return values and error numbers
	  correctly, although slow system calls	may return partial results

     o	  undelivered and queued signals are saved at checkpoint and delivered
	  at restart

     o	  open files (including	NFS-mounted files), mapped files, file locks,
	  and inherited	file descriptors

     o	  special files	/dev/tty, /dev/console,	/dev/zero, /dev/null,

     o	  open pipes, pipeline data and	streams	pipe read and write message

     o	  System V shared memory

     o	  POSIX	semaphores (psema(D3X))

     o	  semaphore and	lock arenas (usinit(3P))

     o	  jobs started with CHALLENGEarray services, provided they have	a
	  unique ASH number; see array_services(5)

     o	  applications using node-lock licenses; see IRIX Checkpoint and
	  Restart Operation Guide on what to do	for applications using
	  floating licenses

     o	  applications using the prctl() PR_ATTACHADDR option; see prctl(2)

     o	  applications using blockproc and unblockproc;	see blockproc(2)

     o	  R10000 counters; see libperfex(3C) and perfex(1)

     The following system objects are not checkpoint-safe:

     o	  network socket connections; see socket(2)

									Page 6

cpr(1)									cpr(1)

     o	  X terminals and X11 client sessions

     o	  special devices such as tape drivers and CDROM

     o	  files	opened with setuid credential that cannot be reestablished

     o	  System V semaphores and messages; see	semop(2) and msgop(2)

     o	  memory mapped	files using the	/dev/mmem file;	see mmap(2)

     o	  open directories

SEE ALSO    [Toc]    [Back]

     atcheckpoint(3C), atrestart(3C), ckpt_create(3), ckpt_remove(3),
     ckpt_restart(3), ckpt_stat(3)
     IRIX Checkpoint and Restart Operation Guide

									PPPPaaaaggggeeee 7777
[ Back ]
 Similar pages
Name OS Title
ckpt_create IRIX checkpoint and restart (CPR) library interfaces
atcheckpoint IRIX add checkpoint and restart (CPR) event handlers
exiwhat Linux programs to query what running exim processes are doing
named.restart FreeBSD stop and restart the name server
ttmedia_Deposit HP-UX send a Deposit request to checkpoint a document
ksd_restart IRIX halt/restart the K-AShare daemon
atinit IRIX halt, start, or restart AppleTalk services
xlate_pro_add_info IRIX set recorded overall info
xlate_get_info IRIX get recorded overall info
db_checkpoint Tru64 Periodically checkpoint the security database log (Enhanced Security)
Copyright © 2004-2005 DeniX Solutions SRL
newsletter delivery service