<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html xmlns:fn="http://www.w3.org/2005/02/xpath-functions"> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <link rel="stylesheet" href="../otp_doc.css" type="text/css"> <title>Erlang -- Embedded Solaris</title> </head> <body bgcolor="white" text="#000000" link="#0000ff" vlink="#ff00ff" alink="#ff0000"><div id="container"> <script id="js" type="text/javascript" language="JavaScript" src="../js/flipmenu/flipmenu.js"></script><script id="js2" type="text/javascript" src="../js/erlresolvelinks.js"></script><script language="JavaScript" type="text/javascript"> <!-- function getWinHeight() { var myHeight = 0; if( typeof( window.innerHeight ) == 'number' ) { //Non-IE myHeight = window.innerHeight; } else if( document.documentElement && ( document.documentElement.clientWidth || document.documentElement.clientHeight ) ) { //IE 6+ in 'standards compliant mode' myHeight = document.documentElement.clientHeight; } else if( document.body && ( document.body.clientWidth || document.body.clientHeight ) ) { //IE 4 compatible myHeight = document.body.clientHeight; } return myHeight; } function setscrollpos() { var objf=document.getElementById('loadscrollpos'); document.getElementById("leftnav").scrollTop = objf.offsetTop - getWinHeight()/2; } function addEvent(obj, evType, fn){ if (obj.addEventListener){ obj.addEventListener(evType, fn, true); return true; } else if (obj.attachEvent){ var r = obj.attachEvent("on"+evType, fn); return r; } else { return false; } } addEvent(window, 'load', setscrollpos); //--></script><div id="leftnav"><div class="innertube"> <img alt="Erlang logo" src="../erlang-logo.png"><br><small><a href="users_guide.html">User's Guide</a><br><a href="../pdf/otp-system-documentation-5.9.3.1.pdf">PDF</a><br><a href="../index.html">Top</a></small><p><strong>Embedded Systems</strong><br><strong>User's Guide</strong><br><small>Version 5.9.3.1</small></p> <br><a href="javascript:openAllFlips()">Expand All</a><br><a href="javascript:closeAllFlips()">Contract All</a><p><small><strong>Chapters</strong></small></p> <ul class="flipMenu" imagepath="../js/flipmenu"> <li id="loadscrollpos" title="Embedded Solaris" expanded="true">Embedded Solaris<ul> <li><a href="embedded_solaris.html"> Top of chapter </a></li> <li title="Memory Usage"><a href="embedded_solaris.html#id62876">Memory Usage</a></li> <li title="Disk Space Usage"><a href="embedded_solaris.html#id57490">Disk Space Usage</a></li> <li title="Installation"><a href="embedded_solaris.html#id62882">Installation</a></li> <li title="Starting Erlang"><a href="embedded_solaris.html#id62454">Starting Erlang</a></li> <li title="Programs"><a href="embedded_solaris.html#id62515">Programs</a></li> </ul> </li> <li id="no" title="Windows NT" expanded="false">Windows NT<ul> <li><a href="embedded_nt.html"> Top of chapter </a></li> <li title="Introduction"><a href="embedded_nt.html#id61722">Introduction</a></li> <li title="Memory Usage"><a href="embedded_nt.html#id61734">Memory Usage</a></li> <li title="Disk Space Usage"><a href="embedded_nt.html#id61746">Disk Space Usage</a></li> <li title="Installation"><a href="embedded_nt.html#id60679">Installation</a></li> <li title="Starting Erlang"><a href="embedded_nt.html#id60718">Starting Erlang</a></li> </ul> </li> <li id="no" title="VxWorks" expanded="false">VxWorks<ul> <li><a href="vxworks.html"> Top of chapter </a></li> <li title="Introduction"><a href="vxworks.html#id60803">Introduction</a></li> <li title="Memory Usage"><a href="vxworks.html#id60820">Memory Usage</a></li> <li title="Disk Usage"><a href="vxworks.html#id60832">Disk Usage</a></li> <li title="Installation"><a href="vxworks.html#id60843">Installation</a></li> <li title="OS Specific Functionality/Information"><a href="vxworks.html#id60953">OS Specific Functionality/Information</a></li> <li title="Starting Erlang"><a href="vxworks.html#id61020">Starting Erlang</a></li> </ul> </li> </ul> </div></div> <div id="content"> <div class="innertube"> <h1>1 Embedded Solaris</h1> <p>This chapter describes the OS specific parts of OTP which relate to Solaris. </p> <h3><a name="id62876">1.1 Memory Usage</a></h3> <p>Solaris takes about 17 Mbyte of RAM on a system with 64 Mbyte of total RAM. This leaves about 47 Mbyte for the applications. If the system utilizes swapping, these figures cannot be improved because unnecessary daemon processes are swapped out. However, if swapping is disabled, or if the swap space is of limited resource in the system, it becomes necessary to kill off unnecessary daemon processes. </p> <h3><a name="id57490">1.2 Disk Space Usage</a></h3> <p>The disk space required by Solaris can be minimized by using the Core User support installation. It requires about 80 Mbyte of disk space. This installs only the minimum software required to boot and run Solaris. The disk space can be further reduced by deleting unnecessary individual files. However, unless disk space is a critical resource the effort required and the risks involved may not be justified.</p> <h3><a name="id62882">1.3 Installation</a></h3> <p>This section is about installing an embedded system. The following topics are considered, </p> <ul> <li> <p>Creation of user and installation directory,</p> </li> <li> <p>Installation of embedded system,</p> </li> <li> <p>Configuration for automatic start at reboot,</p> </li> <li> <p>Making a hardware watchdog available,</p> </li> <li> <p>Changing permission for reboot,</p> </li> <li> <p>Patches,</p> </li> <li> <p>Configuration of the OS_Mon application.</p> </li> </ul> <p>Several of the procedures described below require expert knowledge of the Solaris 2 operating system. For most of them super user privilege is needed. </p> <h4>Creation of User and Installation Directory</h4> <p>It is recommended that the Embedded Environment is run by an ordinary user, i.e. a user who does not have super user privileges. </p> <p>Throughout this section we assume that the user name is <span class="code">otpuser</span>, and that the home directory of that user is, </p> <div class="example"><pre> /export/home/otpuser</pre></div> <p>Furthermore, we assume that in the home directory of <span class="code">otpuser</span>, there is a directory named <span class="code">otp</span>, the full path of which is, </p> <div class="example"><pre> /export/home/otpuser/otp</pre></div> <p>This directory is the <strong>installation directory</strong> of the Embedded Environment. </p> <h4>Installation of an Embedded System</h4> <p>The procedure for installation of an embedded system does not differ from that of an ordinary system (see the <strong>Installation Guide</strong>), except for the following: </p> <ul> <li> <p>the (compressed) tape archive file should be extracted in the installation directory as defined above, and,</p> </li> <li> <p>there is no need to link the start script to a standard directory like <span class="code">/usr/local/bin</span>.</p> </li> </ul> <h4>Configuration for Automatic Start at Boot</h4> <p>A true embedded system has to start when the system boots. This section accounts for the necessary configurations needed to achieve that. </p> <p>The embedded system and all the applications will start automatically if the script file shown below is added to the <span class="code">/etc/rc3.d</span> directory. The file must be owned and readable by <span class="code">root</span>, and its name cannot be arbitrarily assigned. The following name is recommended, </p> <div class="example"><pre> S75otp.system</pre></div> <p>For further details on initialization (and termination) scripts, and naming thereof, see the Solaris documentation. </p> <div class="example"><pre> #!/bin/sh # # File name: S75otp.system # Purpose: Automatically starts Erlang and applications when the # system starts # Author: janne@erlang.ericsson.se # Resides in: /etc/rc3.d # if [ ! -d /usr/bin ] then # /usr not mounted exit fi killproc() { # kill the named process(es) pid=`/usr/bin/ps -e | /usr/bin/grep -w $1 | /usr/bin/sed -e 's/^ *//' -e 's/ .*//'` [ "$pid" != "" ] && kill $pid } # Start/stop processes required for Erlang case "$1" in 'start') # Start the Erlang emulator # su - otpuser -c "/export/home/otpuser/otp/bin/start" & ;; 'stop') killproc beam ;; *) echo "Usage: $0 { start | stop }" ;; esac</pre></div> <p>The file <span class="code">/export/home/otpuser/otp/bin/start</span> referred to in the above script, is precisely the script <span class="code">start</span> described in the section <strong>Starting Erlang</strong> below. The script variable <span class="code">OTP_ROOT</span> in that <span class="code">start</span> script corresponds to the example path </p> <div class="example"><pre> /export/home/otpuser/otp</pre></div> <p>used in this section. The <span class="code">start</span> script should be edited accordingly. </p> <p>Use of the <span class="code">killproc</span> procedure in the above script could be combined with a call to <span class="code">erl_call</span>, e.g. </p> <div class="example"><pre> $SOME_PATH/erl_call -n Node init stop</pre></div> <p>In order to take Erlang down gracefully see the <span class="code">erl_call(1)</span> reference manual page for further details on the use of <span class="code">erl_call</span>. That however requires that Erlang runs as a distributed node which is not always the case. </p> <p>The <span class="code">killproc</span> procedure should not be removed: the purpose is here to move from run level 3 (multi-user mode with networking resources) to run level 2 (multi-user mode without such resources), in which Erlang should not run. </p> <h4>Hardware Watchdog</h4> <p>For Solaris running on VME boards from Force Computers, there is a possibility to activate the onboard hardware watchdog, provided a VME bus driver is added to the operating system (see also <strong>Installation Problems</strong> below). </p> <p>See also the <span class="code">heart(3)</span> reference manual page in <strong>Kernel</strong>. </p> <h4>Changing Permissions for Reboot</h4> <p>If the <span class="code">HEART_COMMAND</span> environment variable is to be set in the <span class="code">start</span> script in the section, <strong>Starting Erlang</strong>, and if the value shall be set to the path of the Solaris <span class="code">reboot</span> command, i.e. </p> <div class="example"><pre> HEART_COMMAND=/usr/sbin/reboot</pre></div> <p>the ownership and file permissions for <span class="code">/usr/sbin/reboot</span> must be changed as follows, </p> <div class="example"><pre> chown 0 /usr/sbin/reboot chmod 4755 /usr/sbin/reboot</pre></div> <p>See also the <span class="code">heart(3)</span> reference manual page in <strong>Kernel</strong>. </p> <h4>The TERM Environment Variable</h4> <p>When the Erlang runtime system is automatically started from the <span class="code">S75otp.system</span> script the <span class="code">TERM</span> environment variable has to be set. The following is a minimal setting, </p> <div class="example"><pre> TERM=sun</pre></div> <p>which should be added to the <span class="code">start</span> script described in the section. </p> <h4>Patches</h4> <p>For proper functioning of flushing file system data to disk on Solaris 2.5.1, the version specific patch with number 103640-02 must be added to the operating system. There may be other patches needed, see the release README file <span class="code"><ERL_INSTALL_DIR>/README</span>. </p> <h4>Installation of Module os_sup in Application OS_Mon</h4> <p>The following four installation procedures require super user privilege. </p> <h4>Installation</h4> <ul> <li> <p><strong>Make a copy the Solaris standard configuration file for syslogd.</strong></p> <ul> <li> <p>Make a copy the Solaris standard configuration file for syslogd. This file is usually named <span class="code">syslog.conf</span> and found in the <span class="code">/etc</span> directory.</p> </li> <li> <p>The file name of the copy must be <span class="code">syslog.conf.ORIG</span> but the directory location is optional. Usually it is <span class="code">/etc</span>. </p> <p>A simple way to do this is to issue the command</p> <div class="example"><pre> cp /etc/syslog.conf /etc/syslog.conf.ORIG</pre></div> </li> </ul> </li> <li> <p><strong>Make an Erlang specific configuration file for syslogd.</strong></p> <ul> <li> <p>Make an edited copy of the back-up copy previously made.</p> </li> <li> <p>The file name must be <span class="code">syslog.conf.OTP</span> and the path must be the same as the back-up copy.</p> </li> <li> <p>The format of the configuration file is found in the man page for <span class="code">syslog.conf(5)</span>, by issuing the command <span class="code">man syslog.conf</span>.</p> </li> <li> <p>Usually a line is added which should state:</p> <ul> <li> <p>which types of information that will be supervised by Erlang,</p> </li> <li> <p>the name of the file (actually a named pipe) that should receive the information.</p> </li> </ul> </li> <li> <p>If e.g. only information originating from the unix-kernel should be supervised, the line should begin with <span class="code">kern.LEVEL</span> (for the possible values of <span class="code">LEVEL</span> see <span class="code">syslog.conf(5)</span>).</p> </li> <li> <p>After at least one tab-character, the line added should contain the full name of the named pipe where syslogd writes its information. The path must be the same as for the <span class="code">syslog.conf.ORIG</span> and <span class="code">syslog.conf.OTP</span> files. The file name must be <span class="code">syslog.otp</span>.</p> </li> <li> <p>If the directory for the <span class="code">syslog.conf.ORIG</span> and <span class="code">syslog.conf.OTP</span> files is <span class="code">/etc</span> the line in <span class="code">syslog.conf.OTP</span> will look like:</p> <div class="example"><pre> kern.LEVEL /etc/syslog.otp</pre></div> </li> </ul> </li> <li> <p><strong>Check the file privileges of the configuration files.</strong></p> <ul> <li> <p>The configuration files should have <span class="code">rw-r--r--</span> file privileges and be owned by root.</p> </li> <li> <p>A simple way to do this is to issue the commands</p> <div class="example"><pre> chmod 644 /etc/syslog.conf chmod 644 /etc/syslog.conf.ORIG chmod 644 /etc/syslog.conf.OTP</pre></div> </li> <li> <p><strong>Note:</strong> If the <span class="code">syslog.conf.ORIG</span> and <span class="code">syslog.conf.OTP</span> files are not in the <span class="code">/etc</span> directory, the file path in the second and third command must be modified.</p> </li> </ul> </li> <li> <p><strong>Modify file privileges and ownership of the mod_syslog utility.</strong></p> <ul> <li> <p>The file privileges and ownership of the <span class="code">mod_syslog</span> utility must be modified.</p> </li> <li> <p>The full name of the binary executable file is derived from the position of the <span class="code">os_mon</span> application if the file system by adding <span class="code">/priv/bin/mod_syslog</span>. The generic full name of the binary executable file is thus</p> <div class="example"><pre> <OTP_ROOT>/lib/os_mon-<REV>/priv/bin/mod_syslog</pre></div> <p><strong>Example:</strong> If the path to the otp-root is <span class="code">/usr/otp</span>, thus the path to the <span class="code">os_mon</span> application is <span class="code">/usr/otp/lib/os_mon-1.0</span> (assuming revision 1.0) and the full name of the binary executable file is <span class="code">/usr/otp/lib/os_mon-1.0/priv/bin/mod_syslog</span>.</p> </li> <li> <p>The binary executable file must be owned by root, have <span class="code">rwsr-xr-x</span> file privileges, in particular the setuid bit of user must be set. </p> </li> <li> <p>A simple way to do this is to issue the commands</p> <div class="example"><pre> cd <OTP_ROOT>/lib/os_mon-<REV>/priv/bin/mod_syslog chmod 4755 mod_syslog chown root mod_syslog</pre></div> </li> </ul> </li> </ul> <h4>Testing the Application Configuration File</h4> <p>The following procedure does not require root privilege. </p> <ul> <li> <p>Ensure that the configuration parameters for the <span class="code">os_sup</span> module in the <span class="code">os_mon</span> application are correct.</p> </li> <li> <p>Browse the application configuration file (do <strong>not</strong> edit it). The full name of the application configuration file is derived from the position of the OS_Mon application if the file system by adding <span class="code">/ebin/os_mon.app</span>. </p> <p>The generic full name of the file is thus</p> <div class="example"><pre> <OTP_ROOT>/lib/os_mon-<REV>/ebin/os_mon.app.</pre></div> <p><strong>Example:</strong> If the path to the otp-root is <span class="code">/usr/otp</span>, thus the path to the <span class="code">os_mon</span> application is <span class="code">/usr/otp/lib/os_mon-1.0 </span> (assuming revision 1.0) and the full name of the binary executable file is <span class="code">/usr/otp/lib/os_mon-1.0/ebin/os_mon.app</span>.</p> </li> <li> <p>Ensure that the following configuration parameters are bound to the correct values.</p> </li> </ul> <table border="1" cellpadding="2" cellspacing="0"> <tr> <td align="left" valign="middle"><strong>Parameter</strong></td> <td align="left" valign="middle"><strong>Function</strong></td> <td align="left" valign="middle"><strong>Standard value</strong></td> </tr> <tr> <td align="left" valign="middle">start_os_sup</td> <td align="left" valign="middle">Specifies if os_sup will be started or not.</td> <td align="left" valign="middle"> <span class="code">true</span>for the first instance on the hardware; <span class="code">false</span>for the other instances.</td> </tr> <tr> <td align="left" valign="middle">os_sup_own</td> <td align="left" valign="middle">The directory for (1)the back-up copy, (2) the Erlang specific configuration file for syslogd.</td> <td align="left" valign="middle"><span class="code">"/etc"</span></td> </tr> <tr> <td align="left" valign="middle">os_sup_syslogconf</td> <td align="left" valign="middle">The full name for the Solaris standard configuration file for syslogd </td> <td align="left" valign="middle"><span class="code">"/etc/syslog.conf"</span></td> </tr> <tr> <td align="left" valign="middle">error_tag</td> <td align="left" valign="middle">The tag for the messages that are sent to the error logger in the Erlang runtime system.</td> <td align="left" valign="middle"><span class="code">std_error</span></td> </tr> </table> <em>Table 1.1: Configuration Parameters</em> <p>If the values listed in the <span class="code">os_mon.app</span> do not suit your needs, you should <span class="code">not</span> edit that file. Instead you should <strong>override</strong> values in a <strong>system configuration file</strong>, the full pathname of which is given on the command line to <span class="code">erl</span>. </p> <p><strong>Example:</strong> The following is an example of the contents of an application configuration file.</p> <p></p> <div class="example"><pre> [{os_mon, [{start_os_sup, true}, {os_sup_own, "/etc"}, {os_sup_syslogconf, "/etc/syslog.conf"}, {os_sup_errortag, std_error}]}].</pre></div> <h4>Related Documents</h4> <p>See also the <span class="code">os_mon(3)</span>, <span class="code">application(3)</span> and <span class="code">erl(1)</span> reference manual pages.</p> <h4>Installation Problems</h4> <p>The hardware watchdog timer which is controlled by the <span class="code">heart</span> port program requires the <span class="code">FORCEvme</span> package, which contains the VME bus driver, to be installed. This driver, however, may clash with the Sun <span class="code">mcp</span> driver and cause the system to completely refuse to boot. To cure this problem, the following lines should be added to <span class="code">/etc/system</span>: </p> <ul> <li><span class="code">exclude: drv/mcp</span></li> <li><span class="code">exclude: drv/mcpzsa</span></li> <li><span class="code">exclude: drv/mcpp</span></li> </ul> <div class="warning"> <div class="label">Warning</div> <div class="content"><p> <p>It is recommended that these lines be added to avoid the clash described, which may make it completely impossible to boot the system.</p> </p></div> </div> <h3><a name="id62454">1.4 Starting Erlang</a></h3> <p>This section describes how an embedded system is started. There are four programs involved, and they all normally reside in the directory <span class="code"><ERL_INSTALL_DIR>/bin</span>. The only exception is the program <span class="code">start</span>, which may be located anywhere, and also is the only program that must be modified by the user. </p> <p>In an embedded system there usually is no interactive shell. However, it is possible for an operator to attach to the Erlang system by giving the command <span class="code">to_erl</span>. He is then connected to the Erlang shell, and may give ordinary Erlang commands. All interaction with the system through this shell is logged in a special directory. </p> <p>Basically, the procedure is as follows. The program <span class="code">start</span> is called when the machine is started. It calls <span class="code">run_erl</span>, which sets things up so the operator can attach to the system. It calls <span class="code">start_erl</span> which calls the correct version of <span class="code">erlexec</span> (which is located in <span class="code"><ERL_INSTALL_DIR>/erts-EVsn/bin</span>) with the correct <span class="code">boot</span> and <span class="code">config</span> files. </p> <h3><a name="id62515">1.5 Programs</a></h3> <h4>start</h4> <p>This program is called when the machine is started. It may be modified or re-written to suit a special system. By default, it must be called <span class="code">start</span> and reside in <span class="code"><ERL_INSTALL_DIR>/bin</span>. Another start program can be used, by using the configuration parameter <span class="code">start_prg</span> in the application <span class="code">sasl</span>.</p> <p>The start program must call <span class="code">run_erl</span> as shown below. It must also take an optional parameter which defaults to <span class="code"><ERL_INSTALL_DIR>/releases/start_erl.data</span>. </p> <p>This program should set static parameters and environment variables such as <span class="code">-sname Name</span> and <span class="code">HEART_COMMAND</span> to reboot the machine. </p> <p>The <span class="code"><RELDIR></span> directory is where new release packets are installed, and where the release handler keeps information about releases. See <span class="code">release_handler(3)</span> in the application <span class="code">sasl</span> for further information. </p> <p>The following script illustrates the default behaviour of the program. </p> <div class="example"><pre> #!/bin/sh # Usage: start [DataFile] # ROOTDIR=/usr/local/otp if [ -z "$RELDIR" ] then RELDIR=$ROOTDIR/releases fi START_ERL_DATA=${1:-$RELDIR/start_erl.data} $ROOTDIR/bin/run_erl /tmp/ $ROOTDIR/log "exec $ROOTDIR/bin/start_erl \ $ROOTDIR $RELDIR $START_ERL_DATA" > /dev/null 2>&1 &</pre></div> <p>The following script illustrates a modification where the node is given the name <span class="code">cp1</span>, and the environment variables <span class="code">HEART_COMMAND</span> and <span class="code">TERM</span> have been added to the above script. </p> <div class="example"><pre> #!/bin/sh # Usage: start [DataFile] # HEART_COMMAND=/usr/sbin/reboot TERM=sun export HEART_COMMAND TERM ROOTDIR=/usr/local/otp if [ -z "$RELDIR" ] then RELDIR=$ROOTDIR/releases fi START_ERL_DATA=${1:-$RELDIR/start_erl.data} $ROOTDIR/bin/run_erl /tmp/ $ROOTDIR/log "exec $ROOTDIR/bin/start_erl \ $ROOTDIR $RELDIR $START_ERL_DATA -heart -sname cp1" > /dev/null 2>&1 &</pre></div> <p>If a diskless and/or read-only client node is about to start the <span class="code">start_erl.data</span> file is located in the client directory at the master node. Thus, the <span class="code">START_ERL_DATA</span> line should look like: </p> <div class="example"><pre> CLIENTDIR=$ROOTDIR/clients/clientname START_ERL_DATA=${1:-$CLIENTDIR/bin/start_erl.data}</pre></div> <h4>run_erl</h4> <p>This program is used to start the emulator, but you will not be connected to the shell. <span class="code">to_erl</span> is used to connect to the Erlang shell. </p> <div class="example"><pre> Usage: run_erl pipe_dir/ log_dir "exec command [parameters ...]"</pre></div> <p>Where <span class="code">pipe_dir/</span> should be <span class="code">/tmp/</span> (<span class="code">to_erl</span> uses this name by default) and <span class="code">log_dir</span> is where the log files are written. <span class="code">command [parameters]</span> is executed, and everything written to stdin and stdout is logged in the <span class="code">log_dir</span>. </p> <p>In the <span class="code">log_dir</span>, log files are written. Each logfile has a name of the form: <span class="code">erlang.log.N</span> where N is a generation number, ranging from 1 to 5. Each logfile holds up to 100kB text. As time goes by the following logfiles will be found in the logfile directory</p> <div class="example"><pre> erlang.log.1 erlang.log.1, erlang.log.2 erlang.log.1, erlang.log.2, erlang.log.3 erlang.log.1, erlang.log.2, erlang.log.3, erlang.log.4 erlang.log.2, erlang.log.3, erlang.log.4, erlang.log.5 erlang.log.3, erlang.log.4, erlang.log.5, erlang.log.1 ...</pre></div> <p>with the most recent logfile being the right most in each row of the above list. That is, the most recent file is the one with the highest number, or if there are already four files, the one before the skip. </p> <p>When a logfile is opened (for appending or created) a time stamp is written to the file. If nothing has been written to the log files for 15 minutes, a record is inserted that says that we're still alive. </p> <h4>to_erl</h4> <p>This program is used to attach to a running Erlang runtime system, started with <span class="code">run_erl</span>. </p> <div class="example"><pre> Usage: to_erl [pipe_name | pipe_dir]</pre></div> <p>Where <span class="code">pipe_name</span> defaults to <span class="code">/tmp/erlang.pipe.N</span>. </p> <p>To disconnect from the shell without exiting the Erlang system, type <span class="code">Ctrl-D</span>. </p> <h4>start_erl</h4> <p>This program starts the Erlang emulator with parameters <span class="code">-boot</span> and <span class="code">-config</span> set. It reads data about where these files are located from a file called <span class="code">start_erl.data</span> which is located in the <span class="code"><RELDIR></span>. Each new release introduces a new data file. This file is automatically generated by the release handler in Erlang. </p> <p>The following script illustrates the behaviour of the program. </p> <div class="example"><pre> #!/bin/sh # # This program is called by run_erl. It starts # the Erlang emulator and sets -boot and -config parameters. # It should only be used at an embedded target system. # # Usage: start_erl RootDir RelDir DataFile [ErlFlags ...] # ROOTDIR=$1 shift RELDIR=$1 shift DataFile=$1 shift ERTS_VSN=`awk '{print $1}' $DataFile` VSN=`awk '{print $2}' $DataFile` BINDIR=$ROOTDIR/erts-$ERTS_VSN/bin EMU=beam PROGNAME=`echo $0 | sed 's/.*\///'` export EMU export ROOTDIR export BINDIR export PROGNAME export RELDIR exec $BINDIR/erlexec -boot $RELDIR/$VSN/start -config $RELDIR/$VSN/sys $*</pre></div> <p>If a diskless and/or read-only client node with the <span class="code">sasl</span> configuration parameter <span class="code">static_emulator</span> set to <span class="code">true</span> is about to start the <span class="code">-boot</span> and <span class="code">-config</span> flags must be changed. As such a client cannot read a new <span class="code">start_erl.data</span> file (the file is not possible to change dynamically) the boot and config files are always fetched from the same place (but with new contents if a new release has been installed). The <span class="code">release_handler</span> copies this files to the <span class="code">bin</span> directory in the client directory at the master nodes whenever a new release is made permanent. </p> <p>Assuming the same <span class="code">CLIENTDIR</span> as above the last line should look like: </p> <div class="example"><pre> exec $BINDIR/erlexec -boot $CLIENTDIR/bin/start \ -config $CLIENTDIR/bin/sys $*</pre></div> </div> <div class="footer"> <hr> <p>Copyright © 1997-2012 Ericsson AB. All Rights Reserved.</p> </div> </div> </div></body> </html>