<!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>
distrib
>
Fedora
>
17
>
i386
>
media
>
updates
>
by-pkgid
>
675c8c8167236dfcf8d66da674f931e8
>
files
>
58
