System Principles
User's Guide
Version 5.7.5

Chapters

• System Principles
  • Top of chapter
  • Starting the System
  • Restarting and Stopping the System
  • Boot Scripts
  • Code Loading Strategy
  • File Types
• Error Logging
  • Top of chapter
  • Error Information From the Runtime System
  • SASL Error Logging
• Creating a First Target System
  • Top of chapter
  • Introduction
  • Creating a Target System
  • Installing a Target System
  • Starting a Target System
  • System Configuration Parameters
  • Differences from the Install Script
  • Listing of target_system.erl

1 System Principles

1.1  Starting the System

An Erlang runtime system is started with the command erl:

% erl
Erlang (BEAM) emulator version 5.2.3.5 [hipe] [threads:0]

Eshell V5.2.3.5  (abort with ^G)
1> 

erl understands a number of command line arguments, see erl(1). A number of them are also described in this chapter.

Application programs can access the values of the command line arguments by calling one of the functions init:get_argument(Key), or init:get_arguments(). See init(3).

1.2  Restarting and Stopping the System

The runtime system can be halted by calling halt/0,1. See erlang(3).

The module init contains function for restarting, rebooting and stopping the runtime system. See init(3).

init:restart()
init:reboot()
init:stop()

Also, the runtime system will terminate if the Erlang shell is terminated.

1.3  Boot Scripts

The runtime system is started using a boot script. The boot script contains instructions on which code to load and which processes and applications to start.

A boot script file has the extension .script. The runtime system uses a binary version of the script. This binary boot script file has the extension .boot.

Which boot script to use is specified by the command line flag -boot. The extension .boot should be omitted. Example, using the boot script start_all.boot:

% erl -boot start_all

If no boot script is specified, it defaults to ROOT/bin/start, see Default Boot Scripts below.

The command line flag -init_debug makes the init process write some debug information while interpreting the boot script:

% erl -init_debug
{progress,preloaded}
{progress,kernel_load_completed}
{progress,modules_loaded}
{start,heart}
{start,error_logger}
...

See script(4) for a detailed description of the syntax and contents of the boot script.

Default Boot Scripts

Erlang/OTP comes with two boot scripts:

start_clean.boot

Loads the code for and starts the applications Kernel and STDLIB.

start_sasl.boot

Loads the code for and starts the applications Kernel, STDLIB and SASL.

Which of start_clean and start_sasl to use as default is decided by the user when installing Erlang/OTP using Install. The user is asked "Do you want to use a minimal system startup instead of the SASL startup". If the answer is yes, then start_clean is used, otherwise start_sasl is used. A copy of the selected boot script is made, named start.boot and placed in the ROOT/bin directory.

User-Defined Boot Scripts

It is sometimes useful or necessary to create a user-defined boot script. This is true especially when running Erlang in embedded mode, see Code Loading Strategy.

It is possible to write a boot script manually. The recommended way to create a boot script, however, is to generate the boot script from a release resource file Name.rel, using the function systools:make_script/1,2. This requires that the source code is structured as applications according to the OTP design principles. (The program does not have to be started in terms of OTP applications but can be plain Erlang).

Read more about .rel files in OTP Design Principles and rel(4).

The binary boot script file Name.boot is generated from the boot script file Name.script using the function systools:script2boot(File).

1.4  Code Loading Strategy

The runtime system can be started in either embedded or interactive mode. Which one is decided by the command line flag -mode.

% erl -mode embedded

Default mode is interactive.

• In embedded mode, all code is loaded during system start-up according to the boot script. (Code can also be loaded later by explicitly ordering the code server to do so).
• In interactive mode, code is dynamically loaded when first referenced. When a call to a function in a module is made, and the module is not loaded, the code server searches the code path and loads the module into the system.

Initially, the code path consists of the current working directory and all object code directories under ROOT/lib, where ROOT is the installation directory of Erlang/OTP. Directories can be named Name[-Vsn] and the code server, by default, chooses the directory with the highest version number among those which have the same Name. The -Vsn suffix is optional. If an ebin directory exists under the Name[-Vsn] directory, it is this directory which is added to the code path.

The code path can be extended by using the command line flags -pa Directories and -pz Directories. These will add Directories to the head or end of the code path, respectively. Example

% erl -pa /home/arne/mycode

The code server module code contains a number of functions for modifying and checking the search path, see code(3).

1.5  File Types

The following file types are defined in Erlang/OTP: