This chapter describes the OS specific parts of OTP which relate to Solaris.
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.
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.
This section is about installing an embedded system. The following topics are considered,
Several of the procedures described below require expert knowledge of the Solaris 2 operating system. For most of them super user privilege is needed.
It is recommended that the Embedded Environment is run by an ordinary user, i.e. a user who does not have super user privileges.
Throughout this section we assume that the user name is
otpuser, and that the home directory of that user is,
/export/home/otpuser
Furthermore, we assume that in the home directory of
otpuser, there is a directory named otp, the
full path of which is,
/export/home/otpuser/otp
This directory is the installation directory of the Embedded Environment.
The procedure for installation of an embedded system does not differ from that of an ordinary system (see the Installation Guide), except for the following:
/usr/local/bin.A true embedded system has to start when the system boots. This section accounts for the necessary configurations needed to achieve that.
The embedded system and all the applications will start
automatically if the script file shown below is added to the
/etc/rc3.d directory. The file must be owned and
readable by root, and its name cannot be arbitrarily
assigned. The following name is recommended,
S75otp.system
For further details on initialization (and termination) scripts, and naming thereof, see the Solaris documentation.
#!/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
The file /export/home/otpuser/otp/bin/start referred to
in the above script, is precisely the script start
described in the section Starting Erlang below. The
script variable OTP_ROOT in that start script
corresponds to the example path
/export/home/otpuser/otp
used in this section. The start script should be edited
accordingly.
Use of the killproc procedure in the above script could
be combined with a call to erl_call, e.g.
$SOME_PATH/erl_call -n Node init stop
In order to take Erlang down gracefully see the
erl_call(1) reference manual page for further details
on the use of erl_call. That however requires that
Erlang runs as a distributed node which is not always the
case.
The killproc 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.
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 Installation Problems below).
See also the heart(3) reference manual page in
Kernel.
If the HEART_COMMAND environment variable is to be set
in the start script in the section, Starting
Erlang, and if the value shall be set to the
path of the Solaris reboot command, i.e.
HEART_COMMAND=/usr/sbin/reboot
the ownership and file permissions for /usr/sbin/reboot
must be changed as follows,
chown 0 /usr/sbin/reboot
chmod 4755 /usr/sbin/reboot
See also the heart(3) reference manual page in
Kernel.
When the Erlang runtime system is automatically started from the
S75otp.system script the TERM environment
variable has to be set. The following is a minimal setting,
TERM=sun
which should be added to the start script described in
the section.
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
<ERL_INSTALL_DIR>/README.
The following four installation procedures require super user privilege.
syslog.conf and found in the /etc
directory.
syslog.conf.ORIG but the directory location
is optional. Usually it is /etc.
cp /etc/syslog.conf /etc/syslog.conf.ORIG
syslog.conf.OTP and the
path must be the same as the back-up copy.
syslog.conf(5), by issuing the
command man syslog.conf.
kern.LEVEL (for the possible
values of LEVEL see syslog.conf(5)).
syslog.conf.ORIG and
syslog.conf.OTP files. The file name must be
syslog.otp.
syslog.conf.ORIG and
syslog.conf.OTP files is /etc the line
in syslog.conf.OTP will look like:
kern.LEVEL /etc/syslog.otp
rw-r--r--
file privileges and be owned by root.
chmod 644 /etc/syslog.conf
chmod 644 /etc/syslog.conf.ORIG
chmod 644 /etc/syslog.conf.OTP
syslog.conf.ORIG and
syslog.conf.OTP files are not in the
/etc directory, the file path in the second
and third command must be modified.
mod_syslog utility must be modified.
os_mon
application if the file system by adding
/priv/bin/mod_syslog. The generic full name
of the binary executable file is thus
<OTP_ROOT>/lib/os_mon-<REV>/priv/bin/mod_syslog
Example: If the path to the otp-root is
/usr/otp, thus the path to the os_mon
application is /usr/otp/lib/os_mon-1.0
(assuming revision 1.0) and the full name of the
binary executable file is
/usr/otp/lib/os_mon-1.0/priv/bin/mod_syslog.
rwsr-xr-x file privileges, in particular
the setuid bit of user must be set.
cd <OTP_ROOT>/lib/os_mon-<REV>/priv/bin/mod_syslog
chmod 4755 mod_syslog
chown root mod_syslog
The following procedure does not require root privilege.
os_sup module in the os_mon application
are correct.
/ebin/os_mon.app.
<OTP_ROOT>/lib/os_mon-<REV>/ebin/os_mon.app.
Example: If the path to the otp-root is
/usr/otp, thus the path to the os_mon
application is /usr/otp/lib/os_mon-1.0 (assuming
revision 1.0) and the full name of the binary executable
file is /usr/otp/lib/os_mon-1.0/ebin/os_mon.app.
| Parameter | Function | Standard value |
| start_os_sup | Specifies if os_sup will be started or not. |
true for the first instance on the hardware;
false for the other instances.
|
| os_sup_own | The directory for (1)the back-up copy, (2) the Erlang specific configuration file for syslogd. |
"/etc"
|
| os_sup_syslogconf | The full name for the Solaris standard configuration file for syslogd |
"/etc/syslog.conf"
|
| error_tag | The tag for the messages that are sent to the error logger in the Erlang runtime system. |
std_error
|
If the values listed in the os_mon.app do not suit
your needs, you should not edit that file. Instead
you should override values in a system
configuration file, the full pathname of which is given
on the command line to erl.
Example: The following is an example of the contents of an application configuration file.
[{os_mon, [{start_os_sup, true}, {os_sup_own, "/etc"},
{os_sup_syslogconf, "/etc/syslog.conf"}, {os_sup_errortag, std_error}]}].
See also the os_mon(3), application(3) and
erl(1) reference manual pages.
The hardware watchdog timer which is controlled by the
heart port program requires the FORCEvme
package, which contains the VME bus driver, to be
installed. This driver, however, may clash with the Sun
mcp driver and cause the system to completely refuse to
boot. To cure this problem, the following lines should be
added to /etc/system:
exclude: drv/mcp
exclude: drv/mcpzsa
exclude: drv/mcpp
![]() |
It is recommended that these lines be added to avoid the clash described, which may make it completely impossible to boot the system. |
This section describes how an embedded system is started. There
are four programs involved, and they all normally reside in the
directory <ERL_INSTALL_DIR>/bin. The only exception is
the program start, which may be located anywhere, and
also is the only program that must be modified by the user.
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 to_erl. 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.
Basically, the procedure is as follows. The program
start is called when the machine is started. It calls
run_erl, which sets things up so the operator can attach
to the system. It calls start_erl which calls the
correct version of erlexec (which is located in
<ERL_INSTALL_DIR>/erts-EVsn/bin) with the correct
boot and config files.
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 start and reside in
<ERL_INSTALL_DIR>/bin. Another start program can be
used, by using the configuration parameter start_prg in
the application sasl.
The start program must call run_erl as shown below.
It must also take an optional parameter which defaults to
<ERL_INSTALL_DIR>/releases/start_erl.data.
This program should set static parameters and environment
variables such as -sname Name and HEART_COMMAND
to reboot the machine.
The <RELDIR> directory is where new release packets
are installed, and where the release handler keeps information
about releases. See release_handler(3) in the
application sasl for further information.
The following script illustrates the default behaviour of the program.
#!/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 &
The following script illustrates a modification where the node
is given the name cp1, and the environment variables
HEART_COMMAND and TERM have been added to the
above script.
#!/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 &
If a diskless and/or read-only client node is about to start the
start_erl.data file is located in the client directory at
the master node. Thus, the START_ERL_DATA line should look
like:
CLIENTDIR=$ROOTDIR/clients/clientname
START_ERL_DATA=${1:-$CLIENTDIR/bin/start_erl.data}
This program is used to start the emulator, but you will not
be connected to the shell. to_erl is used to connect to
the Erlang shell.
Usage: run_erl pipe_dir/ log_dir "exec command [parameters ...]"
Where pipe_dir/ should be /tmp/ (to_erl
uses this name by default) and log_dir is where the log
files are written. command [parameters] is executed,
and everything written to stdin and stdout is logged in the
log_dir.
In the log_dir, log files are written. Each logfile
has a name of the form: erlang.log.N 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
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
...
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.
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.
This program is used to attach to a running Erlang runtime
system, started with run_erl.
Usage: to_erl [pipe_name | pipe_dir]
Where pipe_name defaults to /tmp/erlang.pipe.N.
To disconnect from the shell without exiting the Erlang
system, type Ctrl-D.
This program starts the Erlang emulator with parameters
-boot and -config set. It reads data about
where these files are located from a file called
start_erl.data which is located in the <RELDIR>.
Each new release introduces a new data file. This file is
automatically generated by the release handler in Erlang.
The following script illustrates the behaviour of the program.
#!/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 $*
If a diskless and/or read-only client node with the
sasl configuration parameter static_emulator set
to true is about to start the -boot and
-config flags must be changed. As such a client cannot
read a new start_erl.data 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 release_handler
copies this files to the bin directory in the client
directory at the master nodes whenever a new release is made
permanent.
Assuming the same CLIENTDIR as above the last line
should look like:
exec $BINDIR/erlexec -boot $CLIENTDIR/bin/start \
-config $CLIENTDIR/bin/sys $*