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_syslogExample: 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 $*