From 82dd592d078c473c93ba5cded74f9d71dc504e30 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Bj=C3=B6rn=20Gustavsson?= Date: Thu, 12 Mar 2015 15:35:13 +0100 Subject: Update Embedded Systems User's Guide MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Language cleaned up by the technical writers xsipewe and tmanevik from Combitech. Proofreading and corrections by Björn Gustavsson. --- system/doc/embedded/embedded_nt.xml | 57 +-- system/doc/embedded/embedded_solaris.xml | 774 ++++++++++++++----------------- system/doc/embedded/part.xml | 16 +- 3 files changed, 376 insertions(+), 471 deletions(-) (limited to 'system/doc') diff --git a/system/doc/embedded/embedded_nt.xml b/system/doc/embedded/embedded_nt.xml index 530e3663e4..2e3b32eb84 100644 --- a/system/doc/embedded/embedded_nt.xml +++ b/system/doc/embedded/embedded_nt.xml @@ -31,54 +31,47 @@ PA2 embedded_nt.xml -

This chapter describes the OS specific parts of OTP which relate - to Windows NT. -

+ +

This section describes the operating system-specific parts of OTP + that relate to Windows NT.

+

A normal installation of Windows NT 4.0, with Service Pack 4 or + later, is required for an embedded Windows NT running OTP.

- Introduction -

A normal installation of NT 4.0, with service pack 4 or later, - is required for an embedded Windows NT running OTP.

+ Memory Use +

RAM memory of 96 MB is recommended to run OTP on Windows NT. + A system with less than 64 MB of RAM is not recommended.

- Memory Usage -

RAM memory of 96 MBytes is recommended to run OTP on NT. - A system with less than 64 Mbytes of RAM is not recommended.

+ Disk Space Use +

A minimum Windows NT installation with networking needs 250 MB, + and an extra 130 MB for the swap file.

- Disk Space Usage -

A minimum NT installation with networking needs 250 MB, and - an additional 130 MB for the swap file.

-
- -
- Installation -

Normal NT installation is performed. No additional application - programs are needed, such as Internet explorer or web server. Networking - with TCP/IP is required.

- - Service pack 4 or later must be installed.

+ Installing an Embedded System +

Normal Windows NT installation is performed. No additional + application programs are needed, such as Internet Explorer or + web server. Networking with TCP/IP is required.

+

Service Pack 4 or later must be installed.

Hardware Watchdog -

For Windows NT running on standard PCs with ISA and/or PCI bus - there is a possibility to install an extension card with a hardware - watchdog. -

-

See also the heart(3) reference manual page in - Kernel. -

+

For Windows NT running on standard PCs with ISA and/or PCI bus, + an extension card with a hardware watchdog can be installed.

+

For more information, see the heart(3) manual page in + kernel.

Starting Erlang -

On an embedded system, the erlsrv module should be used, - to install the erlang process as a Windows system service. - This service can start - after NT has booted. See documentation for erlsrv.

+

On an embedded system, the erlsrv module is to be used + to install the Erlang process as a Windows system service. + This service can start after Windows NT has booted.

+

For more information, see the erlsrv manual page + in erts.

diff --git a/system/doc/embedded/embedded_solaris.xml b/system/doc/embedded/embedded_solaris.xml index cab3437725..1861436a8e 100644 --- a/system/doc/embedded/embedded_solaris.xml +++ b/system/doc/embedded/embedded_solaris.xml @@ -31,125 +31,97 @@ B embedded_solaris.xml -

This chapter describes the OS specific parts of OTP which relate - to Solaris. -

+ + +

This section describes the operating system-specific parts + of OTP that relate to Solaris.

- Memory Usage -

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 + Memory Use +

Solaris takes about 17 MB of RAM on a system with 64 MB of + total RAM. This leaves about 47 MB for the applications. If + the system uses 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. -

+ unnecessary daemon processes.

- Disk Space Usage + Disk Space Use

The disk space required by Solaris can be minimized by using the - Core User support installation. It requires about 80 Mbyte of + Core User support installation. It requires about 80 MB of disk space. This installs only the minimum software required to - boot and run Solaris. The disk space can be further reduced by + 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.

+ involved cannot be justified.

- Installation + Installing an Embedded System

This section is about installing an embedded system. - The following topics are considered, -

+ The following topics are considered: +

- -

Creation of user and installation directory,

- - -

Installation of embedded system,

- - -

Configuration for automatic start at reboot,

- - -

Making a hardware watchdog available,

- - -

Changing permission for reboot,

- - -

Patches,

- - -

Configuration of the OS_Mon application.

- + Creating user and installation directory + Installing an embedded system + Configuring automatic start at boot + Making a hardware watchdog available + Changing permission for reboot + Setting TERM environment variable + Adding patches + Installing module os_sup in application os_mon -

Several of the procedures described below require expert - knowledge of the Solaris 2 operating system. For most of them - super user privilege is needed. -

+

Several of the procedures in this section require expert + knowledge of the Solaris operating system. For most of them + super user privilege is needed.

- Creation of User and Installation Directory -

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, -

+ Creating User and Installation Directory +

It is recommended that the embedded environment is run by an + ordinary user, that is, a user who does not have super user + privileges.

+

In this section, it is assumed that the username is + otpuser and that the home directory of that user is:

         /export/home/otpuser
-

Furthermore, we assume that in the home directory of +

It is also assumed that in the home directory of otpuser, there is a directory named otp, the - full path of which is, -

+ full path of which is:

         /export/home/otpuser/otp

This directory is the installation directory of the - Embedded Environment. -

+ embedded environment.

- Installation of an Embedded System -

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: -

+ Installing an Embedded System +

The procedure for installing an embedded system + is the same as for an ordinary system (see + Installation Guide), except for the following:

- -

the (compressed) tape archive file should be - extracted in the installation directory as defined above, - and,

- - -

there is no need to link the start script to a - standard directory like /usr/local/bin.

- + The (compressed) tape archive file is to be extracted in + the installation directory defined above. + It is not needed to link the start script to a standard + directory like /usr/local/bin.
- Configuration for Automatic Start at Boot -

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, -

+ Configuring Automatic Start at Boot +

A true embedded system must start when the system boots. + This section accounts for the necessary configurations + needed to achieve that.

+

The embedded system and all the applications start + automatically if the script file shown below is added to + directory /etc/rc3.d. The file must be owned and + readable by root. 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. -

+

For more details on initialization (and termination) + scripts, and naming thereof, see the Solaris documentation.

 #!/bin/sh
 #  
@@ -187,386 +159,333 @@ case "$1" in
         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 +

File /export/home/otpuser/otp/bin/start referred to + in the above script is precisely the start script + described in Starting Erlang. The script variable OTP_ROOT in that start script - corresponds to the example path -

+ corresponds to the following example path used in this + section:

         /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. -

+

The start script is to be edited accordingly.

+

Use of the killproc procedure in the above script can + be combined with a call to erl_call, for example:

         $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 +

To take Erlang down gracefully, see the erl_call(1) + manual page in erl_interface for details on the use + of erl_call. However, + that requires that Erlang runs as a distributed node, which is + not always the case.

+

The killproc procedure is not to 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. -

+ such resources), in which Erlang is not to run.

- Hardware Watchdog + Making Hardware Watchdog Available

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. -

+ the onboard hardware watchdog can be activated, + provided a VME bus driver is added to the operating system + (see also Installation Problems).

+

See also the heart(3) manual page in kernel.

Changing Permissions for Reboot

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. -

+ in the start script in + Starting Erlang, and if the value is to be set to the + path of the Solaris reboot command, that is:

         HEART_COMMAND=/usr/sbin/reboot
-

the ownership and file permissions for /usr/sbin/reboot - must be changed as follows, -

+

then 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. -

+

See also the heart(3) manual page in kernel.

- The TERM Environment Variable -

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, -

+ Setting TERM Environment Variable +

When the Erlang runtime system is automatically started from + the S75otp.system script, the TERM environment + variable must be set. The following is a minimal setting:

         TERM=sun
-

which should be added to the start script described in - the section. -

+

This is to be added to the start script.

- Patches + Adding Patches

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 - /README]]>. -

+ Solaris 2.5.1, the version-specific patch with number + 103640-02 must be added to the operating system. Other + patches might be needed, see the release README file + /README]]>.

- Installation of Module os_sup in Application OS_Mon + Installing Module os_sup in Application os_mon

The following four installation procedures require super user - privilege. -

- -
- Installation - - -

Make a copy the Solaris standard configuration file for syslogd.

- - -

Make a copy the Solaris standard configuration - file for syslogd. This file is usually named - syslog.conf and found in the /etc - directory.

- - -

The file name of the copy must be - syslog.conf.ORIG but the directory location - is optional. Usually it is /etc. -

-

A simple way to do this is to issue the command

- + privilege:

+ +
+ Installation + + Make a copy of the Solaris standard configuration + file for syslogd: + + Make a copy of the Solaris standard configuration + file for syslogd. This file is usually named + syslog.conf and found in directory /etc. + The filename of the copy must be syslog.conf.ORIG. + The directory location is optional; usually it is /etc. + A simple way to do this is to issue the following command: + cp /etc/syslog.conf /etc/syslog.conf.ORIG - - - -

Make an Erlang specific configuration file for syslogd.

- - -

Make an edited copy of the back-up copy previously - made.

- - -

The file name must be syslog.conf.OTP and the - path must be the same as the back-up copy.

- - -

The format of the configuration file is found in the - man page for syslog.conf(5), by issuing the - command man syslog.conf.

- - -

Usually a line is added which should state:

- - -

which types of information that will be - supervised by Erlang,

- - -

the name of the file (actually a named pipe) - that should receive the information.

- - - - -

If e.g. only information originating from the - unix-kernel should be supervised, the line should - begin with kern.LEVEL (for the possible - values of LEVEL see syslog.conf(5)).

- - -

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 syslog.conf.ORIG and - syslog.conf.OTP files. The file name must be - syslog.otp.

- - -

If the directory for the syslog.conf.ORIG and - syslog.conf.OTP files is /etc the line - in syslog.conf.OTP will look like:

- + + + Make an Erlang-specific configuration file for + syslogd: + + Make an edited copy of the backup copy previously + made. + The filename must be syslog.conf.OTP. The + path must be the same as the backup copy. + The format of the configuration file is found in the + syslog.conf(5) manual page, by issuing the command + man syslog.conf. + Usually a line is added that is to state: + + Which types of information that is to be + supervised by Erlang + The name of the file (actually a named pipe) that + is to receive the information + + + If, for example, only information originating from + the UNIX kernel is to be supervised, the line is to + begin with kern.LEVEL. For the possible + values of LEVEL, see syslog.conf(5). + After at least one tab-character, the line added is to + contain the full name of the named pipe where syslogd + writes its information. The path must be the same as for the + files syslog.conf.ORIG and syslog.conf.OTP. + The filename must be syslog.otp. + If the directory for the files syslog.conf.ORIG + and syslog.conf.OTP is /etc, the line in + syslog.conf.OTP is as follows: + kern.LEVEL /etc/syslog.otp - - - - -

Check the file privileges of the configuration files.

- - -

The configuration files should have rw-r--r-- - file privileges and be owned by root.

- - -

A simple way to do this is to issue the commands

- + + + + Check the file privileges of the configuration + files: + + The configuration files is to have rw-r--r-- + file privileges and be owned by root. + A simple way to do this is to issue these commands: + chmod 644 /etc/syslog.conf chmod 644 /etc/syslog.conf.ORIG chmod 644 /etc/syslog.conf.OTP - - -

Note: If the 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.

- - - - -

Modify file privileges and ownership of the mod_syslog utility.

- - -

The file privileges and ownership of the - mod_syslog utility must be modified.

- - -

The full name of the binary executable file is - derived from the position of the os_mon - application if the file system by adding - /priv/bin/mod_syslog. The generic full name - of the binary executable file is thus

- + Notice that if the files syslog.conf.ORIG and + syslog.conf.OTP are not in directory /etc, + the file path in the second and third command must be + modified. + + + Modify file privileges and ownership of the + mod_syslog utility: + + The file privileges and ownership of the + mod_syslog utility must be modified. +

The full name of the binary executable file is + derived from the position of application os_mon + in the file system by adding + /priv/bin/mod_syslog. The generic full name + of the binary executable file is thus:

+ /lib/os_mon-/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.

- - -

The binary executable file must be owned by root, - have rwsr-xr-x file privileges, in particular - the setuid bit of user must be set. -

- - -

A simple way to do this is to issue the commands

- Example: If the path to otp-root is + /usr/otp, then 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.

+ + The binary executable file must be owned by root, + have rwsr-xr-x file privileges, in particular + the setuid bit of the user must be set. +

A simple way to do this is to issue the following + commands:

+ /lib/os_mon-/priv/bin/mod_syslog chmod 4755 mod_syslog chown root mod_syslog]]> - - - - -
- -
- Testing the Application Configuration File -

The following procedure does not require root privilege. -

- - -

Ensure that the configuration parameters for the - os_sup module in the os_mon application - are correct.

- - -

Browse the application configuration file (do - not 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 - /ebin/os_mon.app. -

-

The generic full name of the file is thus

- + + + +
+ +
+ Testing the Application Configuration File +

The following procedure does not require root privilege:

+ + Ensure that the configuration parameters for the + os_sup module in the os_mon application + are correct. +

Browse the application configuration file (do + not edit it). The full name of the application + configuration file is derived from the position of the + os_mon application in the file system by adding + /ebin/os_mon.app.

+

The generic full name of the file is thus:

+ /lib/os_mon-/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.

- - -

Ensure that the following configuration parameters are - bound to the correct values.

- +

Example: If the path to otp-root is + /usr/otp, then 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.

+ + Ensure that the following configuration parameters have + correct values: - + +
Parameter Function Standard value - start_os_sup - Specifies if os_sup will be started or not. - truefor the first instance on the hardware; falsefor the other instances. + start_os_sup + Specifies if os_sup + is to 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. + os_sup_own + The directory for + (1) back-up copy and (2) Erlang-specific configuration + file for syslogd "/etc" - os_sup_syslogconf - The full name for the Solaris standard configuration file for syslogd + 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. + error_tag + The tag for the + messages that are sent to the error logger in the Erlang + runtime system std_error Configuration Parameters
-

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.

-

- 
+
+        
If the values listed in os_mon.app do not suit
+          your needs, do not edit that file. Instead
+          override the values in a system configuration
+	  file, the full pathname of which is given
+          on the command line to erl.

+        
Example: 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}]}].

-
- -
- Related Documents -

See also the os_mon(3), application(3) and - erl(1) reference manual pages.

-
- Installation Problems -

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: -

+ Related Documents +

See the os_mon(3) application, + the application(3) manual page in kernel, + and the erl(1) manual page in erts.

+
+
+ +
+ Installation Problems +

The hardware watchdog timer, which is controlled by the + heart port program, requires package FORCEvme, + which contains the VME bus driver, to be + installed. However, this driver can clash with the Sun + mcp driver and cause the system to refuse to + boot. To cure this problem, the following lines are + to 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.

+

It is recommended to add these lines to avoid a clash. + The clash can make it impossible to boot the system.
Starting Erlang -

This section describes how an embedded system is started. There - are four programs involved, and they all normally reside in the - directory /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 - /erts-EVsn/bin]]>) with the correct - boot and config files. -

+

This section describes how an embedded system is started. Four + programs are involved and they normally reside in the directory + /bin]]>. The only exception is + the start program, which can be located anywhere, and + is also the only program that must be modified by the user.

+

In an embedded system, there is usually no interactive shell. + However, an operator can attach to the Erlang + system by command to_erl. The operator is then + connected to the Erlang shell and can 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 start program is called when the machine + is started. + It calls run_erl, which sets up things so the + operator can attach to the system. + It calls start_erl, which calls the correct + version of erlexec (which is located in + /erts-EVsn/bin]]>) with the + correct boot and config files. +
Programs -
start -

This program is called when the machine is started. It may - be modified or re-written to suit a special system. By +

This program is called when the machine is started. It can + be modified or rewritten to suit a special system. By default, it must be called start and reside in - /bin]]>. Another start program can be - used, by using the configuration parameter start_prg in - the application sasl.

+ /bin]]>. Another start + program can be used, by using configuration parameter + start_prg in application sasl.

The start program must call run_erl as shown below. - It must also take an optional parameter which defaults to - /releases/start_erl.data]]>. -

-

This program should set static parameters and environment + It must also take an optional parameter, which defaults to + /releases/start_erl.data]]>.

+

This program is to set static parameters and environment variables such as -sname Name and HEART_COMMAND - to reboot the machine. -

-

The ]]> 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. -

+ to reboot the machine.

+

The ]]> directory is where new release + packets are installed, and where the release handler keeps + information about releases. For more information, see the + release_handler(3) manual page in sasl.

The following script illustrates the default behaviour of the - program. -

+ program:

/dev/null 2>&1 &]]>

The following script illustrates a modification where the node - is given the name cp1, and the environment variables + is given the name cp1, and where the environment variables HEART_COMMAND and TERM have been added to the - above script. -

+ previous script:

/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: -

+

If a diskless and/or read-only client node is about to start, + file start_erl.data is located in the client directory at + the master node. Thus, the START_ERL_DATA line is to look + like:

CLIENTDIR=$ROOTDIR/clients/clientname START_ERL_DATA=${1:-$CLIENTDIR/bin/start_erl.data} @@ -620,22 +537,24 @@ START_ERL_DATA=${1:-$CLIENTDIR/bin/start_erl.data} run_erl

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. -

+ 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

- +

Here:

+ + pipe_dir/ is to be /tmp/ (to_erl + uses this name by default). + log_dir is where the log files are written. + command [parameters] is executed. + Everything written to stdin and stdout + is logged in log_dir. + +

Log files are written in log_dir. Each log file + has a name of the form erlang.log.N, where N is a + generation number, ranging from 1 to 5. Each log file holds up + to 100 kB text. As time goes by, the following log files are + found in the log file directory:

+ erlang.log.1 erlang.log.1, erlang.log.2 erlang.log.1, erlang.log.2, erlang.log.3 @@ -643,48 +562,40 @@ 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 most recent log file is the rightmost in each row. 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 log file 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. -

+ that we are still alive.

to_erl

This program is used to attach to a running Erlang runtime - system, started with run_erl. -

+ system, started with run_erl.

Usage: to_erl [pipe_name | pipe_dir] -

Where pipe_name defaults to /tmp/erlang.pipe.N. -

+

Here pipe_name defaults to /tmp/erlang.pipe.N.

To disconnect from the shell without exiting the Erlang - system, type Ctrl-D. -

+ system, type Ctrl-D.

start_erl

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 ]]>. - 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. -

+ -boot and -config set. It reads data about + where these files are located from a file named + start_erl.data, which is located in + ]]>. + 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 +# 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. # @@ -710,22 +621,23 @@ 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 + 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 cannot + be changed 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 + a new release has been installed).

+

The release_handler + copies these 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: -

- + permanent.

+

Assuming the same CLIENTDIR as above, the last line + is to look like:

+ exec $BINDIR/erlexec -boot $CLIENTDIR/bin/start \ -config $CLIENTDIR/bin/sys $*
diff --git a/system/doc/embedded/part.xml b/system/doc/embedded/part.xml index e4366bd2c2..f3b44bf494 100644 --- a/system/doc/embedded/part.xml +++ b/system/doc/embedded/part.xml @@ -31,17 +31,17 @@ C + -

This manual describes the issues that are specific + +

This section describes the issues that are specific for running Erlang on an embedded system. It describes the differences in installing and starting - Erlang compared to how it is done for a non-embedded system. -

-

Note that this is a supplementary document. You still need to - read the Installation Guide. -

-

There is also target architecture specific information in - the top level README file of the Erlang distribution.

+ Erlang compared to how it is done for a non-embedded system.

+

This is a supplementary section. You also need to + read Section 1 Installation Guide.

 +

There is also target architecture-specific information in + the top-level README file of the Erlang distribution.

 -- cgit v1.2.3