aboutsummaryrefslogtreecommitdiffstats
path: root/system/doc/system_principles/create_target.xmlsrc
diff options
context:
space:
mode:
authorHans Bolinder <[email protected]>2015-03-12 15:35:13 +0100
committerBjörn Gustavsson <[email protected]>2015-03-12 17:42:20 +0100
commit0c20078ff0fbad9066c8dd4ebcd6faa0b4f31b42 (patch)
tree379988f5ea4bf36e144c59fa122175badb0df7f1 /system/doc/system_principles/create_target.xmlsrc
parent9fe8adf35c16ab5d4566b03f3b36863c90b5b6dd (diff)
downloadotp-0c20078ff0fbad9066c8dd4ebcd6faa0b4f31b42.tar.gz
otp-0c20078ff0fbad9066c8dd4ebcd6faa0b4f31b42.tar.bz2
otp-0c20078ff0fbad9066c8dd4ebcd6faa0b4f31b42.zip
Update System Principles
Language cleaned up by the technical writers xsipewe and tmanevik from Combitech. Proofreading and corrections by Hans Bolinder.
Diffstat (limited to 'system/doc/system_principles/create_target.xmlsrc')
-rw-r--r--system/doc/system_principles/create_target.xmlsrc367
1 files changed, 171 insertions, 196 deletions
diff --git a/system/doc/system_principles/create_target.xmlsrc b/system/doc/system_principles/create_target.xmlsrc
index a8ee2d1245..7c566229ac 100644
--- a/system/doc/system_principles/create_target.xmlsrc
+++ b/system/doc/system_principles/create_target.xmlsrc
@@ -31,55 +31,54 @@
<rev>A</rev>
<file>create_target.xml</file>
</header>
+ <marker id="creating upgrading target system"></marker>
- <section>
- <title>Introduction</title>
- <p>When creating a system using Erlang/OTP, the most simple way is
- to install Erlang/OTP somewhere, install the application specific
+ <p>When creating a system using Erlang/OTP, the simplest way is
+ to install Erlang/OTP somewhere, install the application-specific
code somewhere else, and then start the Erlang runtime system,
- making sure the code path includes the application specific code.</p>
- <p>Often it is not desirable to use an Erlang/OTP system as is. A
- developer may create new Erlang/OTP compliant applications for a
+ making sure the code path includes the application-specific code.</p>
+ <p>It is often not desirable to use an Erlang/OTP system as is. A
+ developer can create new Erlang/OTP-compliant applications for a
particular purpose, and several original Erlang/OTP applications
- may be irrelevant for the purpose in question. Thus, there is a
+ can be irrelevant for the purpose in question. Thus, there is a
need to be able to create a new system based on a given
- Erlang/OTP system, where dispensable applications are removed,
- and a set of new applications are included. Documentation and
+ Erlang/OTP system, where dispensable applications are removed
+ and new applications are included. Documentation and
source code is irrelevant and is therefore not included in the
new system.</p>
- <p>This chapter is about creating such a system, which we call a
+ <p>This chapter is about creating such a system, which is called a
<em>target system</em>.</p>
- <p>In the following sections we consider creating target systems with
- different requirements of functionality:</p>
+ <p>The following sections deal with target systems
+ with different requirements of functionality:</p>
<list type="bulleted">
- <item>a <em>basic target system</em> that can be started by
- calling the ordinary <c>erl</c> script, </item>
- <item>a <em>simple target system</em> where also code
- replacement in run-time can be performed, and</item>
- <item>an <em>embedded target system</em> where there is also
+ <item>A <em>basic target system</em> that can be started by
+ calling the ordinary <c>erl</c> script.</item>
+ <item>A <em>simple target system</em> where also code
+ replacement in runtime can be performed.</item>
+ <item>An <em>embedded target system</em> where there is also
support for logging output from the system to file for later
inspection, and where the system can be started automatically
- at boot time. </item>
+ at boot time.</item>
</list>
- <p>We only consider the case when Erlang/OTP is running on a UNIX
- system.</p>
- <p>In the <c>sasl</c> application there is an example Erlang
- module <c>target_system.erl</c> that contains functions for
- creating and installing a target system. This module is used in
- the examples below, and the source code of the module is listed
- at the end of this chapter.</p>
- </section>
+ <p>Here is only considered the case when Erlang/OTP is running on a
+ UNIX system.</p>
+ <p>The <c>sasl</c> application includes the example Erlang
+ module <c>target_system.erl</c>, which contains functions for
+ creating and installing a target system. This module is used in
+ the following examples. The source code of the module is listed
+ in <seealso marker="#listing of target system">
+ Listing of target_system.erl</seealso></p>
<section>
<marker id="create"/>
<title>Creating a Target System</title>
<p>It is assumed that you have a working Erlang/OTP system structured
- according to the OTP Design Principles.</p>
- <p><em>Step 1.</em> First create a <c>.rel</c> file (see <seealso
- marker="sasl:rel">rel(4)</seealso>) that specifies the <c>erts</c>
- version and lists all applications that should be included in the
- new basic target system. An example is the following
- <c>mysystem.rel</c> file:</p>
+ according to the OTP design principles.</p>
+ <p><em>Step 1.</em> Create a <c>.rel</c> file (see the
+ <seealso marker="sasl:rel">rel(4)</seealso> manual page in
+ SASL), which specifies the ERTS version and lists
+ all applications that are to be included in the new basic target
+ system. An example is the following <c>mysystem.rel</c> file:</p>
<code type="none">
%% mysystem.rel
{release,
@@ -91,23 +90,23 @@
{pea, "1.0"}]}.</code>
<p>The listed applications are not only original Erlang/OTP
applications but possibly also new applications that you have
- written yourself (here exemplified by the application
- <c>pea</c>). </p>
- <p><em>Step 2.</em> From the directory where the <c>mysystem.rel</c>
- file reside, start the Erlang/OTP system:</p>
+ written (here exemplified by the application Pea (<c>pea</c>)).</p>
+ <p><em>Step 2.</em> Start Erlang/OTP from the directory where
+ the <c>mysystem.rel</c> file resides:</p>
<pre>
os> <input>erl -pa /home/user/target_system/myapps/pea-1.0/ebin</input></pre>
- <p>where also the path to the <c>pea-1.0</c> ebin directory is
- provided. </p>
- <p><em>Step 3.</em> Now create the target system: </p>
+ <p>Here also the path to the <c>pea-1.0</c> ebin directory is
+ provided.</p>
+ <p><em>Step 3.</em> Create the target system:</p>
<pre>
1> <input>target_system:create("mysystem").</input></pre>
- <p>The <c>target_system:create/1</c> function does the following:</p>
+ <p>The function <c>target_system:create/1</c> performs the
+ following:</p>
<list type="ordered">
- <item>Reads the <c>mysystem.rel</c> file, and creates a new file
- <c>plain.rel</c> which is identical to former, except that it
- only lists the <c>kernel</c> and <c>stdlib</c> applications. </item>
- <item>From the <c>mysystem.rel</c> and <c>plain.rel</c> files
+ <item>Reads the file <c>mysystem.rel</c> and creates a new file
+ <c>plain.rel</c> that is identical to the former, except that it
+ only lists the Kernel and STDLIB applications.</item>
+ <item>From the files <c>mysystem.rel</c> and <c>plain.rel</c>
creates the files <c>mysystem.script</c>,
<c>mysystem.boot</c>, <c>plain.script</c>, and
<c>plain.boot</c> through a call to
@@ -124,26 +123,26 @@ releases/mysystem.rel
lib/kernel-2.16.4/
lib/stdlib-1.19.4/
lib/sasl-2.3.4/
-lib/pea-1.0/ </code>
+lib/pea-1.0/</code>
<p>The file <c>releases/FIRST/start.boot</c> is a copy of our
<c>mysystem.boot</c></p>
<p>The release resource file <c>mysystem.rel</c> is duplicated
in the tar file. Originally, this file was only stored in
- the <c>releases</c> directory in order to make it possible
+ the <c>releases</c> directory to make it possible
for the <c>release_handler</c> to extract this file
separately. After unpacking the tar
file, <c>release_handler</c> would automatically copy the
file to <c>releases/FIRST</c>. However, sometimes the tar
file is unpacked without involving
- the <c>release_handler</c> (e.g. when unpacking the first
- target system) and therefore the file is now instead
+ the <c>release_handler</c> (for example, when unpacking the
+ first target system). The file is therefore now instead
duplicated in the tar file so no manual copying is
- necessary.</p>
+ needed.</p>
</item>
- <item>Creates the temporary directory <c>tmp</c> and extracts the tar file
- <c>mysystem.tar.gz</c> into that directory. </item>
- <item>Deletes the <c>erl</c> and <c>start</c> files from
- <c>tmp/erts-5.10.4/bin</c>. These files will be created again from
+ <item>Creates the temporary directory <c>tmp</c> and extracts
+ the tar file <c>mysystem.tar.gz</c> into that directory.</item>
+ <item>Deletes the files <c>erl</c> and <c>start</c> from
+ <c>tmp/erts-5.10.4/bin</c>. These files are created again from
source when installing the release.</item>
<item>Creates the directory <c>tmp/bin</c>.</item>
<item>Copies the previously created file <c>plain.boot</c> to
@@ -151,31 +150,31 @@ lib/pea-1.0/ </code>
<item>Copies the files <c>epmd</c>, <c>run_erl</c>, and
<c>to_erl</c> from the directory <c>tmp/erts-5.10.4/bin</c> to
the directory <c>tmp/bin</c>.</item>
- <item>Creates the directory <c>tmp/log</c>, which will be used
+ <item>Creates the directory <c>tmp/log</c>, which is used
if the system is started as embedded with the <c>bin/start</c>
script.</item>
<item>Creates the file <c>tmp/releases/start_erl.data</c> with
the contents "5.10.4 FIRST". This file is to be passed as data
- file to the <c>start_erl</c> script.
- </item>
+ file to the <c>start_erl</c> script.</item>
<item>Recreates the file <c>mysystem.tar.gz</c> from the directories
- in the directory <c>tmp</c>, and removes <c>tmp</c>.</item>
+ in the directory <c>tmp</c> and removes <c>tmp</c>.</item>
</list>
</section>
<section>
<title>Installing a Target System</title>
<p><em>Step 4.</em> Install the created target system in a
- suitable directory. </p>
+ suitable directory.</p>
<pre>
2> <input>target_system:install("mysystem", "/usr/local/erl-target").</input></pre>
- <p>The function <c>target_system:install/2</c> does the following:
+ <p>The function <c>target_system:install/2</c> performs the following:
</p>
<list type="ordered">
<item>Extracts the tar file <c>mysystem.tar.gz</c> into the target
directory <c>/usr/local/erl-target</c>.</item>
- <item>In the target directory reads the file <c>releases/start_erl.data</c>
- in order to find the Erlang runtime system version ("5.10.4").</item>
+ <item>In the target directory reads the file
+ <c>releases/start_erl.data</c> to find the Erlang runtime system
+ version ("5.10.4").</item>
<item>Substitutes <c>%FINAL_ROOTDIR%</c> and <c>%EMU%</c> for
<c>/usr/local/erl-target</c> and <c>beam</c>, respectively, in
the files <c>erl.src</c>, <c>start.src</c>, and
@@ -184,97 +183,102 @@ lib/pea-1.0/ </code>
<c>start</c>, and <c>run_erl</c> in the target <c>bin</c>
directory.</item>
<item>Finally the target <c>releases/RELEASES</c> file is created
- from data in the <c>releases/mysystem.rel</c> file.</item>
+ from data in the file <c>releases/mysystem.rel</c>.</item>
</list>
</section>
<section>
<marker id="start"/>
<title>Starting a Target System</title>
- <p>Now we have a target system that can be started in various ways.</p>
- <p>We start it as a <em>basic target system</em> by invoking</p>
+ <p>Now we have a target system that can be started in various ways.
+ We start it as a <em>basic target system</em> by invoking:</p>
<pre>
os> <input>/usr/local/erl-target/bin/erl</input></pre>
- <p>where only the <c>kernel</c> and <c>stdlib</c> applications are
- started, i.e. the system is started as an ordinary development
- system. There are only two files needed for all this to work:
- <c>bin/erl</c> file (obtained from <c>erts-5.10.4/bin/erl.src</c>)
- and the <c>bin/start.boot</c> file (a copy of <c>plain.boot</c>).</p>
+ <p>Here only the Kernel and STDLIB applications are
+ started, that is, the system is started as an ordinary development
+ system. Only two files are needed for all this to work:</p>
+ <list type="ordered">
+ <item><c>bin/erl</c> (obtained from
+ <c>erts-5.10.4/bin/erl.src</c>)</item>
+ <item><c>bin/start.boot</c> (a copy of
+ <c>plain.boot</c>)</item>
+ </list>
<p>We can also start a distributed system (requires <c>bin/epmd</c>).</p>
<p>To start all applications specified in the original
- <c>mysystem.rel</c> file, use the <c>-boot</c> flag as follows:</p>
+ <c>mysystem.rel</c> file, use flag <c>-boot</c> as follows:</p>
<pre>
os> <input>/usr/local/erl-target/bin/erl -boot /usr/local/erl-target/releases/FIRST/start</input></pre>
- <p>We start a <em>simple target system</em> as above. The only difference
- is that also the file <c>releases/RELEASES</c> is present for
- code replacement in run-time to work.</p>
- <p>To start an <em>embedded target system</em> the shell script
- <c>bin/start</c> is used. That shell script calls
+ <p>We start a <em>simple target system</em> as above. The only
+ difference is that also the file <c>releases/RELEASES</c> is
+ present for code replacement in runtime to work.</p>
+ <p>To start an <em>embedded target system</em>, the shell script
+ <c>bin/start</c> is used. The script calls
<c>bin/run_erl</c>, which in turn calls <c>bin/start_erl</c>
(roughly, <c>start_erl</c> is an embedded variant of
- <c>erl</c>). </p>
+ <c>erl</c>).</p>
<p>The shell script <c>start</c>, which is generated from
erts-5.10.4/bin/start.src during installation, is only an
- example. You should edit it to suite your needs. Typically it is
+ example. Edit it to suite your needs. Typically it is
executed when the UNIX system boots.</p>
<p><c>run_erl</c> is a wrapper that provides logging of output from
- the run-time system to file. It also provides a simple mechanism
+ the runtime system to file. It also provides a simple mechanism
for attaching to the Erlang shell (<c>to_erl</c>).</p>
- <p><c>start_erl</c> requires the root directory
- (<c>"/usr/local/erl-target"</c>), the releases directory
- (<c>"/usr/local/erl-target/releases"</c>), and the location of
- the <c>start_erl.data</c> file. It reads the run-time system
- version (<c>"5.10.4"</c>) and release version (<c>"FIRST"</c>) from
- the <c>start_erl.data</c> file, starts the run-time system of the
- version found, and provides <c>-boot</c> flag specifying the boot
- file of the release version found
- (<c>"releases/FIRST/start.boot"</c>).</p>
- <p><c>start_erl</c> also assumes that there is <c>sys.config</c> in
- release version directory (<c>"releases/FIRST/sys.config"</c>). That
- is the topic of the next section (see below).</p>
- <p>The <c>start_erl</c> shell script should normally not be
+ <p><c>start_erl</c> requires:</p>
+ <list type="ordered">
+ <item>The root directory (<c>"/usr/local/erl-target"</c>)</item>
+ <item>The releases directory
+ (<c>"/usr/local/erl-target/releases"</c></item>
+ <item>The location of the file <c>start_erl.data</c></item>
+ </list>
+ <p>It performs the following:</p>
+ <list type="ordered">
+ <item>Reads the runtime system version (<c>"5.10.4"</c>) and
+ release version (<c>"FIRST"</c>) from the file
+ <c>start_erl.data</c>.</item>
+ <item>Starts the runtime system of the version found.</item>
+ <item>Provides the flag <c>-boot</c> specifying the boot
+ file of the release version found
+ (<c>"releases/FIRST/start.boot"</c>).</item>
+ </list>
+ <p><c>start_erl</c> also assumes that there is <c>sys.config</c>
+ in the release version directory (<c>"releases/FIRST/sys.config"</c>).
+ That is the topic of the next section.</p>
+ <p>The <c>start_erl</c> shell script is normally not to be
altered by the user.</p>
</section>
<section>
<title>System Configuration Parameters</title>
- <p>As was pointed out above <c>start_erl</c> requires a
- <c>sys.config</c> in the release version directory
- (<c>"releases/FIRST/sys.config"</c>). If there is no such a
- file, the system start will fail. Hence such a file has to
- be added as well.</p>
- <p></p>
- <p>If you have system configuration data that are neither file
- location dependent nor site dependent, it may be convenient to
- create the <c>sys.config</c> early, so that it becomes a part of
+ <p>As was mentioned in the previous section, <c>start_erl</c>
+ requires a <c>sys.config</c> in the release version directory
+ (<c>"releases/FIRST/sys.config"</c>). If there is no such
+ file, the system start fails. Such a file must therefore
+ also be added.</p>
+ <p>If you have system configuration data that is neither
+ file-location-dependent nor site-dependent, it can be convenient
+ to create <c>sys.config</c> early, so it becomes part of
the target system tar file created by
- <c>target_system:create/1</c>. In fact, if you create, in the
- current directory, not only the <c>mysystem.rel</c> file, but
- also a <c>sys.config</c> file, that latter file will be tacitly
+ <c>target_system:create/1</c>. In fact, if you in the
+ current directory create not only the file <c>mysystem.rel</c>,
+ but also file <c>sys.config</c>, the latter file is tacitly
put in the appropriate directory.</p>
</section>
<section>
- <title>Differences from the Install Script</title>
- <p>The above <c>install/2</c> procedure differs somewhat from that
+ <title>Differences From the Install Script</title>
+ <p>The previous <c>install/2</c> procedure differs somewhat from that
of the ordinary <c>Install</c> shell script. In fact, <c>create/1</c>
makes the release package as complete as possible, and leave to the
- <c>install/2</c> procedure to finish by only considering location
- dependent files.</p>
+ <c>install/2</c> procedure to finish by only considering
+ location-dependent files.</p>
</section>
<section>
<title>Creating the Next Version</title>
-
- <p>
- In this example the <c>pea</c> application has been changed, and
- so are <c>erts</c>, <c>kernel</c>, <c>stdlib</c> and
- <c>sasl</c>.
- </p>
-
- <p>
- <em>Step 1.</em> Create the <c>.rel</c> file:
- </p>
+ <p>In this example the Pea application has been changed, and
+ so are the applications ERTS, Kernel, STDLIB
+ and SASL.</p>
+ <p><em>Step 1.</em> Create the file <c>.rel</c>:</p>
<code type="none">
%% mysystem2.rel
{release,
@@ -284,65 +288,49 @@ os> <input>/usr/local/erl-target/bin/erl -boot /usr/local/erl-target/releases/FI
{stdlib, "2.0"},
{sasl, "2.4"},
{pea, "2.0"}]}.</code>
- <p>
- <em>Step 2.</em> Create the application upgrade file (see
- <seealso marker="sasl:appup">appup(4)</seealso>) for <c>pea</c>,
- for example:
- </p>
+ <p><em>Step 2.</em> Create the application upgrade file (see the
+ <seealso marker="sasl:appup">appup(4)</seealso> manual page in
+ SASL) for Pea, for example:</p>
<code type="none">
%% pea.appup
{"2.0",
[{"1.0",[{load_module,pea_lib}]}],
[{"1.0",[{load_module,pea_lib}]}]}.</code>
- <p>
- <em>Step 3.</em> From the directory where the
- <c>mysystem2.rel</c> file reside, start the Erlang/OTP system:
- </p>
+ <p><em>Step 3.</em> From the directory where the file
+ <c>mysystem2.rel</c> resides, start the Erlang/OTP system,
+ giving the path to the new version of Pea:</p>
<pre>
os> <input>erl -pa /home/user/target_system/myapps/pea-2.0/ebin</input></pre>
- <p>giving the path to the new version of <c>pea</c>. </p>
-
- <p>
- <em>Step 4.</em> Create the release upgrade file (see <seealso
- marker="sasl:relup">relup(4)</seealso>):
- </p>
+ <p><em>Step 4.</em> Create the release upgrade file (see the
+ <seealso marker="sasl:relup">relup(4)</seealso> manual page in
+ SASL):</p>
<pre>
-1> <input>systools:make_relup("mysystem2",["mysystem"],["mysystem"],[{path,["/home/user/target_system/myapps/pea-1.0/ebin","/my/old/erlang/lib/*/ebin"]}]).</input></pre>
- <p>
- where <c>"mysystem"</c> is the base release and
- <c>"mysystem2"</c> is the release to upgrade to.
- </p>
- <p>
- Note that the <c>path</c> option is used for pointing out the
+1> <input>systools:make_relup("mysystem2",["mysystem"],["mysystem"],
+ [{path,["/home/user/target_system/myapps/pea-1.0/ebin",
+ "/my/old/erlang/lib/*/ebin"]}]).</input></pre>
+ <p>Here <c>"mysystem"</c> is the base release and
+ <c>"mysystem2"</c> is the release to upgrade to.</p>
+ <p>The <c>path</c> option is used for pointing out the
old version of all applications. (The new versions are already
- in the code path - assuming of course that the erlang node on
+ in the code path - assuming of course that the Erlang node on
which this is executed is running the correct version of
- Erlang/OTP.)
- </p>
- <p>
- <em>Step 5.</em> Create the new release:
- </p>
+ Erlang/OTP.)</p>
+ <p><em>Step 5.</em> Create the new release:</p>
<pre>
2> <input>target_system:create("mysystem2").</input></pre>
- <p>
- Given that the <c>relup</c> file generated in step 4 above is
- now located in the current directory, it will automatically be
- included in the release package.
- </p>
+ <p>Given that the file <c>relup</c> generated in Step 4 is
+ now located in the current directory, it is automatically
+ included in the release package.</p>
</section>
<section>
<title>Upgrading the Target System</title>
- <p>
- This part is done on the target node, and for this example we
+ <p>This part is done on the target node, and for this example we
want the node to be running as an embedded system with the
- <c>-heart</c> option, allowing automatic restart of the
- node. See <seealso marker="#start">Starting a Target
- System</seealso> above for more information.
- </p>
- <p>
- We add <c>-heart</c> to <c>bin/start</c>:
- </p>
+ <c>-heart</c> option, allowing automatic restart of the node.
+ For more information, see <seealso marker="#start">
+ Starting a Target System</seealso>.</p>
+ <p>We add <c>-heart</c> to <c>bin/start</c>:</p>
<code type="none">
#!/bin/sh
ROOTDIR=/usr/local/erl-target/
@@ -354,36 +342,27 @@ fi
START_ERL_DATA=${1:-$RELDIR/start_erl.data}
-$ROOTDIR/bin/run_erl -daemon /tmp/ $ROOTDIR/log "exec $ROOTDIR/bin/start_erl $ROOTDIR $RELDIR $START_ERL_DATA -heart</code>
- <p>
- And we use the simplest possible <c>sys.config</c>, which we
- store in <c>releases/FIRST</c>:
- </p>
+$ROOTDIR/bin/run_erl -daemon /tmp/ $ROOTDIR/log "exec $ROOTDIR/bin/start_erl $ROOTDIR\
+$RELDIR $START_ERL_DATA -heart</code>
+ <p>We use the simplest possible <c>sys.config</c>, which we
+ store in <c>releases/FIRST</c>:</p>
<code type="none">
%% sys.config
[].</code>
- <p>
- Finally, in order to prepare the upgrade, we need to put the new
+ <p>Finally, to prepare the upgrade, we must put the new
release package in the <c>releases</c> directory of the first
- target system:
- </p>
+ target system:</p>
<pre>
os> <input>cp mysystem2.tar.gz /usr/local/erl-target/releases</input></pre>
- <p>
- And assuming that the node has been started like this:
- </p>
+ <p>Assuming that the node has been started as follows:</p>
<pre>
os> <input>/usr/local/erl-target/bin/start</input></pre>
- <p>
- it can be accessed like this:
- </p>
+ <p>It can be accessed as follows:</p>
<pre>
os> <input>/usr/local/erl-target/bin/to_erl /tmp/erlang.pipe.1</input></pre>
- <p>
- Also note that logs can be found in
+ <p>Logs can be found in
<c>/usr/local/erl-target/log</c>. This directory is specified as
- an argument to <c>run_erl</c>in the start script listed above.
- </p>
+ an argument to <c>run_erl</c>in the start script listed above.</p>
<p>
<em>Step 1.</em> Unpack the release:
</p>
@@ -402,18 +381,19 @@ heart: Tue Apr 1 12:15:11 2014: Executed "/usr/local/erl-target/bin/start /usr/
The above return value and output after the call to
<c>release_handler:install_release/1</c> means that the
<c>release_handler</c> has restarted the node by using
- <c>heart</c>. This will always be done when the upgrade involves
- a change of <c>erts</c>, <c>kernel</c>, <c>stdlib</c> or
- <c>sasl</c>. See <seealso marker="upgrade">Upgrade when
- Erlang/OTP has Changed</seealso> for more infomation about this.
+ <c>heart</c>. This is always done when the upgrade involves
+ a change of the applications ERTS, Kernel,
+ STDLIB, or SASL. For more information, see
+ <seealso marker="upgrade">
+ Upgrade when Erlang/OTP has Changed</seealso>.
</p>
<p>
- The node will be accessible via a new pipe:
+ The node is accessible through a new pipe:
</p>
<pre>
os> <input>/usr/local/erl-target/bin/to_erl /tmp/erlang.pipe.2</input></pre>
<p>
- Let's see which releases we have in our system:
+ Check which releases there are in the system:
</p>
<pre>
1> <input>release_handler:which_releases().</input>
@@ -426,7 +406,7 @@ os> <input>/usr/local/erl-target/bin/to_erl /tmp/erlang.pipe.2</input></pre>
<p>
Our new release, "SECOND", is now the current release, but we
can also see that our "FIRST" release is still permanent. This
- means that if the node would be restarted at this point, it
+ means that if the node would be restarted now, it
would come up running the "FIRST" release again.
</p>
<p>
@@ -434,11 +414,9 @@ os> <input>/usr/local/erl-target/bin/to_erl /tmp/erlang.pipe.2</input></pre>
</p>
<pre>
2> <input>release_handler:make_permanent("SECOND").</input></pre>
-
<p>
- Now look at the releases again:
+ Check the releases again:
</p>
-
<pre>
3> <input>release_handler:which_releases().</input>
<output>[{"MYSYSTEM","SECOND",
@@ -447,19 +425,16 @@ os> <input>/usr/local/erl-target/bin/to_erl /tmp/erlang.pipe.2</input></pre>
{"MYSYSTEM","FIRST",
["kernel-2.16.4","stdlib-1.19.4","sasl-2.3.4","pea-1.0"],
old}]</output></pre>
-
<p>
- Here we see that the new release version is <c>permanent</c>, so
- it would be safe to restart the node.
- </p>
-
+ We see that the new release version is <c>permanent</c>, so
+ it would be safe to restart the node.</p>
</section>
<section>
+ <marker id="listing of target system"/>
<title>Listing of target_system.erl</title>
<p>This module can also be found in the <c>examples</c> directory
- of the <c>sasl</c> application.</p>
+ of the SASL application.</p>
<codeinclude file="../../../lib/sasl/examples/src/target_system.erl" tag="%module" type="erl"></codeinclude>
-
</section>
</chapter>