From e10079c3793da3d0f6d76adaf38422cba63bc427 Mon Sep 17 00:00:00 2001 From: Siri Hansen Date: Mon, 28 Nov 2011 10:39:15 +0100 Subject: Fix minor faults in documentation of release handling Fix typos or minor faults. Move out code listing of target_system.erl, and use codeinclude statement to include this file from sasl/examples directory. --- system/doc/design_principles/release_handling.xml | 44 ++++++++++++----------- 1 file changed, 23 insertions(+), 21 deletions(-) (limited to 'system/doc/design_principles/release_handling.xml') diff --git a/system/doc/design_principles/release_handling.xml b/system/doc/design_principles/release_handling.xml index 8ed36f3c56..4378b6599c 100644 --- a/system/doc/design_principles/release_handling.xml +++ b/system/doc/design_principles/release_handling.xml @@ -178,13 +178,13 @@ Release Handling Instructions

OTP supports a set of release handling instructions - that is used when creating .appup files. The release + that are used when creating .appup files. The release handler understands a subset of these, the low-level instructions. To make it easier for the user, there are also a number of high-level instructions, which are translated to low-level instructions by systools:make_relup.

Here, some of the most frequently used instructions are - described. The complete list of instructions is found in + described. The complete list of instructions can be found in appup(4).

First, some definitions:

@@ -239,9 +239,10 @@

update with argument supervisor is used when changing the start specification of a supervisor. See Appup Cookbook.

-

The release handler finds the processes using a module - to update by traversing the supervision tree of each running - application and checking all the child specifications:

+

When a module is to be updated, the release handler finds + which processes that are using the module by + traversing the supervision tree of each running application + and checking all the child specifications:

{Id, StartFunc, Restart, Shutdown, Type, Modules}

A process is using a module if the name is listed in @@ -265,8 +266,8 @@

The instruction loads the module and is absolutely necessary when running Erlang in embedded mode. It is not strictly required when running Erlang in interactive (default) mode, - since the code server automatically searches for and loads - unloaded modules.

+ since the code server then automatically searches for and + loads unloaded modules.

The opposite of add_module is delete_module which unloads a module:

@@ -294,7 +295,7 @@ the modules are unloaded using a number of delete_module instructions and then the application specification is unloaded from the application controller.

-

Instruction for removing an application:

+

Instruction for restarting an application:

{restart_application, Application}

Restarting an application means that the application is stopped @@ -331,17 +332,17 @@ of the emulator and the core applications. Then it shuts down the current emulator by calling init:reboot(), see init(3). All processes are terminated gracefully and - the system can then be rebooted by the heart program, using - the temporary boot file. After the reboot, the rest of the - relup instructions are executed. This is done as a part of the - boot script.

+ the system is rebooted by the heart program, using the + temporary boot file. After the reboot, the rest of the relup + instructions are executed. This is done as a part of the + temporary boot script.

An info report is written when the upgrade is completed. To programatically find out if the upgrade is complete, - call release_handler:which_releases/0 and check if the - expected release has status current.

-

The new version must be made permanent when the new emulator - is up and running. Otherwise, the old version will be used in - case of a new system reboot.

+ call release_handler:which_releases(current) and check + if it returns the expected (i.e. the new) release.

+

The new release version must be made permanent when the new + emulator is up and running. Otherwise, the old version will be + used in case of a new system reboot.

On UNIX, the release handler tells the heart program which command to use to reboot the system. Note that the environment variable HEART_COMMAND, normally used by the heart @@ -362,8 +363,8 @@ a relup script, and it shall always be placed at the end. If the relup is generated by systools:make_relup/3,4 this is automatically ensured.

-

When the release handler encounters the instruction, it shuts down - the emulator by calling init:reboot(), see +

When the release handler encounters the instruction, it shuts + down the emulator by calling init:reboot(), see init(3). All processes are terminated gracefully and the system can then be rebooted by the heart program using the new release version. No more upgrade instruction will be @@ -581,8 +582,8 @@ release_handler:remove_release(Vsn) => ok [].

2) Start the system as a simple target system. Note that in reality, it should be started as an embedded system. However, - using erl with the correct boot script and .config - file is enough for illustration purposes:

+ using erl with the correct boot script and config file is + enough for illustration purposes:

 % cd $ROOT
 % bin/erl -boot $ROOT/releases/A/start -config $ROOT/releases/A/sys
@@ -617,6 +618,7 @@ lib/ch_app-2/ebin/ch3.beam
 releases/B/start.boot
 releases/B/relup
 releases/B/sys.config
+releases/B/ch_rel-2.rel
 releases/ch_rel-2.rel
     
4) Copy the release package ch_rel-2.tar.gz to
       the $ROOT/releases directory.

-- 
cgit v1.2.3