From e5875001247e6a6ac4f474157a51a8c54f94ae49 Mon Sep 17 00:00:00 2001 From: Hans Bolinder Date: Thu, 14 Mar 2013 16:01:25 +0100 Subject: Convert XML files to UTF-8 --- lib/sasl/doc/src/appup.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'lib/sasl/doc/src/appup.xml') diff --git a/lib/sasl/doc/src/appup.xml b/lib/sasl/doc/src/appup.xml index bacfaa76ef..85fcbed3ba 100644 --- a/lib/sasl/doc/src/appup.xml +++ b/lib/sasl/doc/src/appup.xml @@ -1,10 +1,10 @@ - +
- 19972012 + 19972013 Ericsson AB. All Rights Reserved. -- cgit v1.2.3 From 8eb20d1fb0eb3a3b96d5e80e2e2617f893ef6986 Mon Sep 17 00:00:00 2001 From: Siri Hansen Date: Thu, 20 Feb 2014 16:45:28 +0100 Subject: Add info about upgrade of core applications In ref man for appup and in system documentation, design prinsiples, add a warning related to upgrade when version of erts, kernel, stdlib or sasl is changed. This will cause an emulator restart where new version of emulator and core applications will startup together with old versions of other applications. Care must be taken to avoid problems due to backwards incompatibility. --- lib/sasl/doc/src/appup.xml | 23 ++++++++++++++++++++--- 1 file changed, 20 insertions(+), 3 deletions(-) (limited to 'lib/sasl/doc/src/appup.xml') diff --git a/lib/sasl/doc/src/appup.xml b/lib/sasl/doc/src/appup.xml index 85fcbed3ba..95f315d269 100644 --- a/lib/sasl/doc/src/appup.xml +++ b/lib/sasl/doc/src/appup.xml @@ -4,7 +4,7 @@
- 19972013 + 19972014 Ericsson AB. All Rights Reserved. @@ -84,6 +84,9 @@ version identifier must be specified as a binary, e.g.

<<"2\\.1\\.[0-9]+">>

will match all versions 2.1.x, where x is any number.

+

Note that the regular expression must match the complete + version string, so the above example will work for for + e.g. 2.1.1, but not for 2.1.1.1

@@ -339,7 +342,7 @@ restart_new_emulator version of erts, kernel, stdlib and sasl are used when the emulator restarts. Only one restart_new_emulator instruction is allowed in the relup, and it shall be placed - first. systools:make_relup3,4 + first. systools:make_relup/3,4 will ensure this when the relup is generated. The rest of the relup script is executed after the restart as a part of the boot script.

@@ -347,11 +350,25 @@ restart_new_emulator completed. To programatically find out if the upgrade is complete, call - release_handler:which_releases and check if the + release_handler:which_releases/0,1 and check if the expected release has status current.

The new release must still be made permanent after the upgrade is completed. Otherwise, the old emulator is started in case of an emulator restart.

+ +

As stated above, the restart_new_emulator + instruction causes the emulator to be restarted with new + versions of erts, kernel, stdlib and + sasl. All other applications, however, will at startup + be running their old versions in this new emulator. In most + cases this is no problem, but every now and then there will be + incompatible changes to the core applications which may cause + trouble in this setting. Such incompatible changes (when + functions are removed) are normally preceded by a deprecation + over two major releases. To make sure your application is not + crashed by an incompatible change, always remove any call to + deprecated functions as soon as possible.

+ 
 restart_emulator
-- cgit v1.2.3 From a4290bb363fb6f1c593886d4f10a5868d7c9d3b8 Mon Sep 17 00:00:00 2001 From: Siri Hansen Date: Wed, 15 Oct 2014 18:31:13 +0200 Subject: [sasl] Remove undocumented upgrade instruction The upgrade instruction 'remove_module' was added in OTP R7B (and possibly in a patch in R5B or R6B, ticket OTP-3477), and translates to the low level instruction 'remove', but adds the parameter DepMods (modules on which Mod is dependent). The ticket says that "remove_module should be added for symmetry with the add_module instruction". remove_module was never documented or tested, and it was never mentioned in a release note. It therefore seems to be low risk in removing it. The correct instruction to use when removing a module is {delete_module,Mod} which was added in OTP R10B and which is also documented and tested. This translates to low level instructions 'remove' and 'purge' i.e. the module is brutally purged after setting the current code to old. This hardcoded brutal purge is the reason why PrePurge and PostPurge parameters can not be given with the delete_module instruction. The parameter DepMods which was inclued in the remove_module instruction does not exist for delete_module. From the documentation's point of view, this is the same for add_module, and thus the two instructions {add_module,Mod} and {delete_module,Mod} are now symmetric. However, in the code there is a second instruction for adding a module, {add_module,Mod,DepMods}, which is not documented. To add symmetry even for this, {delete_module,Mod,DepMods} is now also added. Documentation is added for all instructions. --- lib/sasl/doc/src/appup.xml | 13 +++++++++++++ 1 file changed, 13 insertions(+) (limited to 'lib/sasl/doc/src/appup.xml') diff --git a/lib/sasl/doc/src/appup.xml b/lib/sasl/doc/src/appup.xml index 95f315d269..f0f41b0c7e 100644 --- a/lib/sasl/doc/src/appup.xml +++ b/lib/sasl/doc/src/appup.xml @@ -180,15 +180,28 @@ Mod when upgrading, and vice versa when downgrading.

 {add_module, Mod}
+{add_module, Mod, DepMods}
   Mod = atom()
+  DepMods = [Mod]

Loads a new module Mod.

+

DepMods defaults to [] and defines which other modules + Mod is dependent on. In relup, instructions + related to these modules will come before the instruction for + loading Mod when upgrading, and vice versa when + downgrading.

 {delete_module, Mod}
+{delete_module, Mod, DepMods}
   Mod = atom()

Deletes a module Mod using the low-level instructions remove and purge.

+

DepMods defaults to [] and defines which other modules + Mod is dependent on. In relup, instructions + related to these modules will come before the instruction for + removing Mod when upgrading, and vice versa when + downgrading.

 {add_application, Application}
 {add_application, Application, Type}
-- 
cgit v1.2.3


From 738c34d4bb8f1a3811acd00af8c6c12107f8315b Mon Sep 17 00:00:00 2001
From: Bruce Yinhe 
Date: Thu, 18 Jun 2015 11:31:02 +0200
Subject: Change license text to APLv2

---
 lib/sasl/doc/src/appup.xml | 21 +++++++++++----------
 1 file changed, 11 insertions(+), 10 deletions(-)

(limited to 'lib/sasl/doc/src/appup.xml')

diff --git a/lib/sasl/doc/src/appup.xml b/lib/sasl/doc/src/appup.xml
index f0f41b0c7e..72333960ec 100644
--- a/lib/sasl/doc/src/appup.xml
+++ b/lib/sasl/doc/src/appup.xml
@@ -8,16 +8,17 @@
       Ericsson AB. All Rights Reserved.
     
     
-      The contents of this file are subject to the Erlang Public License,
-      Version 1.1, (the "License"); you may not use this file except in
-      compliance with the License. You should have received a copy of the
-      Erlang Public License along with this software. If not, it can be
-      retrieved online at http://www.erlang.org/.
-    
-      Software distributed under the License is distributed on an "AS IS"
-      basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See
-      the License for the specific language governing rights and limitations
-      under the License.
+      Licensed under the Apache License, Version 2.0 (the "License");
+      you may not use this file except in compliance with the License.
+      You may obtain a copy of the License at
+ 
+          http://www.apache.org/licenses/LICENSE-2.0
+
+      Unless required by applicable law or agreed to in writing, software
+      distributed under the License is distributed on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+      See the License for the specific language governing permissions and
+      limitations under the License.
     
     
 
-- 
cgit v1.2.3


From f84858101803153a04caeb1b300b80e376fc105d Mon Sep 17 00:00:00 2001
From: xsipewe 
Date: Fri, 2 Oct 2015 13:01:27 +0200
Subject: sasl: Editorial changes

---
 lib/sasl/doc/src/appup.xml | 449 +++++++++++++++++++++++----------------------
 1 file changed, 231 insertions(+), 218 deletions(-)

(limited to 'lib/sasl/doc/src/appup.xml')

diff --git a/lib/sasl/doc/src/appup.xml b/lib/sasl/doc/src/appup.xml
index 72333960ec..b54d2adb19 100644
--- a/lib/sasl/doc/src/appup.xml
+++ b/lib/sasl/doc/src/appup.xml
@@ -29,78 +29,85 @@
appup - Application upgrade file. + Application upgrade file

The application upgrade file defines how an application is upgraded or downgraded in a running system.

-

This file is used by the functions in systools when - generating a release upgrade file relup.

+

This file is used by the functions in + systools + when generating a release upgrade file relup.
- FILE SYNTAX -

The application upgrade file should be called - Application.appup where Application is the name of - the application. The file should be located in the ebin + File Syntax +

The application upgrade file is to be called + Application.appup, where Application is the + application name. The file is to be located in the ebin directory for the application.

The .appup file contains one single Erlang term, which defines the instructions used to upgrade or downgrade - the application. The file has the following syntax:

+ the application. The file has the following syntax:

{Vsn, [{UpFromVsn, Instructions}, ...], - [{DownToVsn, Instructions}, ...]}. - - - -

Vsn = string() is the current version of - the application.

- - -

UpFromVsn = string() | binary() is an earlier - version of the application to upgrade from. If it is a - string, it will be interpreted as a specific version - number. If it is a binary, it will be interpreted as a - regular expression which can match multiple version - numbers.

- - -

DownToVsn = string() | binary() is an earlier - version of the application to downgrade to. If it is a - string, it will be interpreted as a specific version - number. If it is a binary, it will be interpreted as a - regular expression which can match multiple version - numbers.

- - -

Instructions is a list of release upgrade instructions, see below. It is recommended to use + [{DownToVsn, Instructions}, ...]}. + + Vsn = string() +

Current application version.

 + UpFromVsn = string() | binary() +

An earlier + application version to upgrade from. If it is a + string, it is interpreted as a specific version + number. If it is a binary, it is interpreted as a + regular expression that can match multiple version + numbers.

 + DownToVsn = string() | binary() +

An earlier + application version to downgrade to. If it is a + string, it is interpreted as a specific version + number. If it is a binary, it is interpreted as a + regular expression that can match multiple version + numbers.

 + Instructions +

A list of release upgrade instructions, see + Release + Upgrade Instructions. It is recommended to use high-level instructions only. These are automatically translated to low-level instructions by systools when - creating the relup file.

- - -

In order to avoid duplication of upgrade instructions it is - allowed to use regular expressions to specify the UpFromVsn - and DownToVsn. To be considered a regular expression, the - version identifier must be specified as a binary, e.g.

- <<"2\\.1\\.[0-9]+">> -

will match all versions 2.1.x, where x is any number.

-

Note that the regular expression must match the complete - version string, so the above example will work for for - e.g. 2.1.1, but not for 2.1.1.1

+ creating the relup file.

+ +

To avoid duplication of upgrade instructions, it is + allowed to use regular expressions to specify UpFromVsn + and DownToVsn. To be considered a regular expression, the + version identifier must be specified as a binary. For example, + the following match all versions 2.1.x, where x is + any number:

+ +<<"2\\.1\\.[0-9]+">> +

Notice that the regular expression must match the complete + version string, so this example works for, for example, + 2.1.1, but not for 2.1.1.1.

- RELEASE UPGRADE INSTRUCTIONS + + Release Upgrade Instructions

Release upgrade instructions are interpreted by the release handler when an upgrade or downgrade is made. For more - information about release handling, refer to OTP Design Principles.

-

A process is said to use a module Mod, if + information about release handling, see + OTP + Design Principles in System Documentation.

+

A process is said to use a module Mod if Mod is listed in the Modules part of the child - specification used to start the process, see supervisor(3). - In the case of gen_event, an event manager process is said to use - Mod if Mod is an installed event handler.

-

High-level instructions

+ specification used to start the process, see + supervisor(3). + In the case of + gen_event, + an event manager process is said to use Mod if Mod + is an installed event handler.

+ +
+ High-Level Instructions 
 {update, Mod}
 {update, Mod, supervisor}
@@ -116,52 +123,68 @@
   Change = soft | {advanced,Extra}
     Extra = term()
   PrePurge = PostPurge = soft_purge | brutal_purge
-  DepMods = [Mod]
-
-

Synchronized code replacement of processes using the module - Mod. All those processes are suspended using - sys:suspend, the new version of the module is loaded and - then the processes are resumed using sys:resume.

-

Change defaults to soft and defines the type of - code change. If it is set to {advanced,Extra}, processes - implemented using gen_server, gen_fsm or gen_event will transform - their internal state by calling the callback function - code_change. Special processes will call the callback + DepMods = [Mod] +

Synchronized code replacement of processes using module + Mod.

+

All those processes are suspended using + sys:suspend, + the new module version is loaded, and + then the processes are resumed using + sys:resume.

+ + Change +

Defaults to soft and defines the type of + code change. If it is set to {advanced,Extra}, implemented + processes using + gen_server, + gen_fsm, or + gen_event + transform their internal state by calling the callback function + code_change. Special processes call the callback function system_code_change/4. In both cases, the term - Extra is passed as an argument to the callback function.

-

PrePurge defaults to brutal_purge and controls - what action to take with processes that are executing old code - before loading the new version of the module. If the value + Extra is passed as an argument to the callback + function.

 + PrePurge +

Defaults to brutal_purge. It controls + what action to take with processes executing old code + before loading the new module version. If the value is brutal_purge, the processes are killed. If the value is - soft_purge, release_handler:install_release/1 - returns {error,{old_processes,Mod}}.

-

PostPurge defaults to brutal_purge and controls + soft_purge, + release_handler:install_release/1 + returns {error,{old_processes,Mod}}.

 + PostPurge +

Defaults to brutal_purge. It controls what action to take with processes that are executing old code - when the new version of the module has been loaded. If the value + when the new module version has been loaded. If the value is brutal_purge, the code is purged when the release is made permanent and the processes are killed. If the value is - soft_purge, the release handler will purge the old code - when no remaining processes execute the code.

-

DepMods defaults to [] and defines which other modules - Mod is dependent on. In relup, instructions for - suspending processes using Mod will come before + soft_purge, the release handler purges the old code + when no remaining processes execute the code.

 + DepMods +

Defaults to [] and defines other modules that + Mod is dependent on. In the relup file, instructions + for suspending processes using Mod come before instructions for suspending processes using modules in - DepMods when upgrading, and vice versa when downgrading. + DepMods when upgrading, and conversely when downgrading. In case of circular dependencies, the order of the instructions in - the appup script is kept.

-

Timeout defines the timeout when suspending processes. - If no value or default is given, the default value for - sys:suspend is used.

-

ModType defaults to dynamic and specifies if - the code is "dynamic", that is if a process using the module does - spontaneously switch to new code, or if it is "static". - When doing an advanced update and upgrading, the new version of a + the appup file is kept.

 + Timeout +

Defines the time-out when suspending processes. + If no value or default is specified, the default value for + sys:suspend + is used.

 + ModType +

Defaults to dynamic. It specifies if + the code is "dynamic", that is, if a process using the module + spontaneously switches to new code, or if it is "static". + When doing an advanced update and upgrade, the new version of a dynamic module is loaded before the process is asked to change code. When downgrading, the process is asked to change code before loading the new version. For static modules, the new version is loaded before the process is asked to change code, both in the case of upgrading and downgrading. Callback modules are - dynamic.

+ dynamic.

 +

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

@@ -170,239 +193,229 @@
 {load_module, Mod, PrePurge, PostPurge, DepMods}
   Mod = atom()
   PrePurge = PostPurge = soft_purge | brutal_purge
-  DepMods = [Mod]
-
+ DepMods = [Mod]

Simple code replacement of the module Mod.

-

See update above for a description of PrePurge and - PostPurge.

-

DepMods defaults to [] and defines which other modules - Mod is dependent on. In relup, instructions for - loading these modules will come before the instruction for loading - Mod when upgrading, and vice versa when downgrading.

+

For a description of PrePurge and PostPurge, + see update above.

+

DepMods defaults to [] and defines which other modules + Mod is dependent on. In the relup file, instructions for + loading these modules come before the instruction for loading + Mod when upgrading, and conversely when downgrading.

 {add_module, Mod}
 {add_module, Mod, DepMods}
   Mod = atom()
-  DepMods = [Mod]
-
+ DepMods = [Mod]

Loads a new module Mod.

-

DepMods defaults to [] and defines which other modules - Mod is dependent on. In relup, instructions - related to these modules will come before the instruction for - loading Mod when upgrading, and vice versa when +

DepMods defaults to [] and defines which other modules + Mod is dependent on. In the relup file, instructions + related to these modules come before the instruction for + loading Mod when upgrading, and conversely when downgrading.

 {delete_module, Mod}
 {delete_module, Mod, DepMods}
-  Mod = atom()
-
+ Mod = atom()

Deletes a module Mod using the low-level instructions remove and purge.

-

DepMods defaults to [] and defines which other modules - Mod is dependent on. In relup, instructions - related to these modules will come before the instruction for - removing Mod when upgrading, and vice versa when +

DepMods defaults to [] and defines which other modules + Mod is dependent on. In the relup file, instructions + related to these modules come before the instruction for + removing Mod when upgrading, and conversely when downgrading.

 {add_application, Application}
 {add_application, Application, Type}
   Application = atom()
-  Type = permanent | transient | temporary | load | none
-
+ Type = permanent | transient | temporary | load | none

Adding an application means that the modules defined by the modules key in the .app file are loaded using add_module.

Type defaults to permanent and specifies the start type of the application. If Type = permanent | transient | temporary, - the application will be loaded and started in the corresponding way, - see application(3). If Type = load, the application will - only be loaded. If Type = none, the application will be neither - loaded nor started, although the code for its modules will be loaded.

+ the application is loaded and started in the corresponding way, see + application(3). + If Type = load, the application is only loaded. + If Type = none, the application is not loaded and not + started, although the code for its modules is loaded.

 {remove_application, Application}
-  Application = atom()
-
+ Application = atom()

Removing an application means that the application is stopped, - the modules are unloaded using delete_module and then + the modules are unloaded using delete_module, and then the application specification is unloaded from the application controller.

 {restart_application, Application}
-  Application = atom()
-
+ Application = atom()

Restarting an application means that the application is - stopped and then started again similar to using the instructions + stopped and then started again, similar to using the instructions remove_application and add_application in sequence.

-

Low-level instructions

+
+ +
+ Low-Level Instructions 
 {load_object_code, {App, Vsn, [Mod]}}
   App = Mod = atom()
-  Vsn = string()
-
-

Reads each Mod from the directory App-Vsn/ebin as - a binary. It does not load the modules. The instruction should be - placed first in the script in order to read all new code from file - to make the suspend-load-resume cycle less time consuming. After - this instruction has been executed, the code server with the new - version of App.

+ Vsn = string() +

Reads each Mod from directory App-Vsn/ebin as + a binary. It does not load the modules. The instruction is to be + placed first in the script to read all new code from the file + to make the suspend-load-resume cycle less time-consuming.

-point_of_no_return
-
+point_of_no_return

If a crash occurs after this instruction, the system cannot - recover and is restarted from the old version of the release. - The instruction must only occur once in a script. It should be + recover and is restarted from the old release version. + The instruction must only occur once in a script. It is to be placed after all load_object_code instructions.

 {load, {Mod, PrePurge, PostPurge}}
   Mod = atom()
-  PrePurge = PostPurge = soft_purge | brutal_purge
-
+ PrePurge = PostPurge = soft_purge | brutal_purge

Before this instruction occurs, Mod must have been loaded using load_object_code. This instruction loads the module. - PrePurge is ignored. See the high-level instruction - update for a description of PostPurge.

+ PrePurge is ignored. For a description of PostPurge, + see the high-level instruction update earlier.

 {remove, {Mod, PrePurge, PostPurge}}
   Mod = atom()
-  PrePurge = PostPurge = soft_purge | brutal_purge
-
+ PrePurge = PostPurge = soft_purge | brutal_purge

Makes the current version of Mod old. - PrePurge is ignored. See the high-level instruction - update for a description of PostPurge.

+ PrePurge is ignored. For a description of PostPurge, + see the high-level instruction update earlier.

 {purge, [Mod]}
-  Mod = atom()
-
-

Purges each module Mod, that is removes the old code. - Note that any process executing purged code is killed.

+ Mod = atom() +

Purges each module Mod, that is, removes the old code. + Notice that any process executing purged code is killed.

 {suspend, [Mod | {Mod, Timeout}]}
   Mod = atom()
-  Timeout = int()>0 | default | infinity
-
+ Timeout = int()>0 | default | infinity

Tries to suspend all processes using a module Mod. If a - process does not respond, it is ignored. This may cause + process does not respond, it is ignored. This can cause the process to die, either because it crashes when it spontaneously switches to new code, or as a result of a purge operation. If no Timeout is specified or default is - given, the default value for sys:suspend is used.

+ specified, the default value for + sys:suspend + is used.

 {resume, [Mod]}
-  Mod = atom()
-
+ Mod = atom()

Resumes all suspended processes using a module Mod.

 {code_change, [{Mod, Extra}]}
 {code_change, Mode, [{Mod, Extra}]}
   Mod = atom()
   Mode = up | down
-  Extra = term()
-
+ Extra = term()

Mode defaults to up and specifies if it is an - upgrade or downgrade.

-

This instruction sends a code_change system message to - all processes using a module Mod by calling the function - sys:change_code, passing the term Extra as argument.

+ upgrade or downgrade. This instruction sends a code_change + system message to all processes using a module Mod by + calling function + sys:change_code, + passing term Extra as argument.

 {stop, [Mod]}
-  Mod = atom()
-
+ Mod = atom()

Stops all processes using a module Mod by calling - supervisor:terminate_child/2. The instruction is useful + supervisor:terminate_child/2. + This instruction is useful when the simplest way to change code is to stop and restart the - processes which run the code.

+ processes that run the code.

 {start, [Mod]}
-  Mod = atom()
-
+ Mod = atom()

Starts all stopped processes using a module Mod by calling - supervisor:restart_child/2.

+ supervisor:restart_child/2.

 {sync_nodes, Id, [Node]}
 {sync_nodes, Id, {M, F, A}}
   Id = term()
   Node = node()
   M = F = atom()
-  A = [term()]
-
+ A = [term()]

apply(M, F, A) must return a list of nodes.

-

The instruction synchronizes the release installation with other - nodes. Each Node must evaluate this command, with the same +

This instruction synchronizes the release installation with other + nodes. Each Node must evaluate this command with the same Id. The local node waits for all other nodes to evaluate - the instruction before execution continues. In case a node goes + the instruction before execution continues. If a node goes down, it is considered to be an unrecoverable error, and the local node is restarted from the old release. There is no - timeout for this instruction, which means that it may hang + time-out for this instruction, which means that it can hang forever.

 {apply, {M, F, A}}
   M = F = atom()
-  A = [term()]
-
-

Evaluates apply(M, F, A). If the instruction appears - before the point_of_no_return instruction, a failure is - caught. release_handler:install_release/1 then returns - {error,{'EXIT',Reason}}, unless {error,Error} is - thrown or returned. Then it returns {error,Error}.

-

If the instruction appears after the point_of_no_return - instruction, and the function call fails, the system is - restarted.

+ A = [term()] +

Evaluates apply(M, F, A).

+

If the instruction appears before instruction + point_of_no_return, a failure is caught. + release_handler:install_release/1 + then returns {error,{'EXIT',Reason}}, unless {error,Error} + is thrown or returned. Then it returns {error,Error}.

+

If the instruction appears after instruction + point_of_no_return and the function call fails, the + system is restarted.

-restart_new_emulator
-
-

This instruction is used when erts, kernel, stdlib or sasl is +restart_new_emulator +

This instruction is used when the application ERTS, + Kernel, STDLIB, or SASL is upgraded. It shuts down the current emulator and starts a new one. All processes are terminated gracefully, and the new - version of erts, kernel, stdlib and sasl are used when the - emulator restarts. Only one restart_new_emulator - instruction is allowed in the relup, and it shall be placed - first. systools:make_relup/3,4 - will ensure this when the relup is generated. The rest of the - relup script is executed after the restart as a part of the boot - script.

-

An info report will be written when the upgrade is - completed. To programatically find out if the upgrade is - complete, + version of ERTS, Kernel, STDLIB, and + SASL are used when the emulator restarts. + Only one restart_new_emulator instruction is allowed + in the relup file, and it must be placed first. + systools:make_relup/3,4 + ensures this when the relup file is generated. The rest of the + instructions in the relup file is executed after the + restart as a part of the boot script.

+

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

The new release must still be made permanent after the upgrade - is completed. Otherwise, the old emulator is started in case of + is completed, otherwise the old emulator is started if there is an emulator restart.

-

As stated above, the restart_new_emulator - instruction causes the emulator to be restarted with new - versions of erts, kernel, stdlib and - sasl. All other applications, however, will at startup - be running their old versions in this new emulator. In most - cases this is no problem, but every now and then there will be - incompatible changes to the core applications which may cause - trouble in this setting. Such incompatible changes (when - functions are removed) are normally preceded by a deprecation - over two major releases. To make sure your application is not - crashed by an incompatible change, always remove any call to - deprecated functions as soon as possible.

+

As stated earlier, instruction restart_new_emulator + causes the emulator to be restarted with new versions of + ERTS, Kernel, STDLIB, and SASL. + However, all other applications do at startup run their old + versions in this new emulator. This is usually no problem, + but every now and then incompatible changes occur to the + core applications, which can cause + trouble in this setting. Such incompatible changes (when + functions are removed) are normally preceded by a deprecation + over two major releases. To ensure that your application is not + crashed by an incompatible change, always remove any call to + deprecated functions as soon as possible.

 
-restart_emulator
-
+restart_emulator

This instruction is similar to restart_new_emulator, - except it shall be placed at the end of the relup script. It is - not related to an upgrade of the emulator or the core + except it must be placed at the end of the relup file. + It is not related to an upgrade of the emulator or the core applications, but can be used by any application when a complete - reboot of the system is reqiured. When generating the - relup, systools:make_relup/3,4 + reboot of the system is required.

+

When generating the relup file, + systools:make_relup/3,4 ensures that there is only one restart_emulator - instruction and that it is the last instruction of the - relup.

+ instruction and that it is the last instruction in the + relup file.

+
- SEE ALSO -

relup(4), - release_handler(3), - supervisor(3), - systools(3)

+ See Also +

release_handler(3), + relup(4), + supervisor(3), + systools(3)

 -- cgit v1.2.3 From d840b24857a1d54419953661f70716c449c11864 Mon Sep 17 00:00:00 2001 From: Raimo Niskanen Date: Thu, 3 Mar 2016 10:54:01 +0100 Subject: Fix most of the system docs and emacs mode --- lib/sasl/doc/src/appup.xml | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) (limited to 'lib/sasl/doc/src/appup.xml') diff --git a/lib/sasl/doc/src/appup.xml b/lib/sasl/doc/src/appup.xml index b54d2adb19..6fbdcb9f5b 100644 --- a/lib/sasl/doc/src/appup.xml +++ b/lib/sasl/doc/src/appup.xml @@ -4,7 +4,7 @@
- 19972014 + 19972016 Ericsson AB. All Rights Reserved. @@ -137,7 +137,8 @@ code change. If it is set to {advanced,Extra}, implemented processes using gen_server, - gen_fsm, or + gen_fsm, + gen_statem, or gen_event transform their internal state by calling the callback function code_change. Special processes call the callback -- cgit v1.2.3