Provided by: erlang-base_21.2.6+dfsg-1_amd64 bug

NAME

       erl - The Erlang emulator.

DESCRIPTION

       The  erl  program starts an Erlang runtime system. The exact details (for example, whether
       erl is a script or a program and which other programs it calls) are system-dependent.

       Windows users probably want to use the werl program instead, which runs in its own  window
       with  scrollbars and supports command-line editing. The erl program on Windows provides no
       line editing in its shell, and on Windows 95 there is no way to scroll back to  text  that
       has scrolled off the screen. The erl program must be used, however, in pipelines or if you
       want to redirect standard input or output.

   Note:
       As from ERTS 5.9 (Erlang/OTP R15B) the runtime system does by default not bind  schedulers
       to logical processors. For more information, see system flag +sbt.

EXPORTS

       erl <arguments>

              Starts an Erlang runtime system.

              The arguments can be divided into emulator flags, flags, and plain arguments:

                * Any argument starting with character + is interpreted as an emulator flag.

                  As indicated by the name, emulator flags control the behavior of the emulator.

                * Any argument starting with character - (hyphen) is interpreted as a flag, which
                  is to be passed to the Erlang part of the runtime system, more specifically  to
                  the init system process, see init(3erl).

                  The init process itself interprets some of these flags, the init flags. It also
                  stores any remaining flags, the user flags. The  latter  can  be  retrieved  by
                  calling init:get_argument/1.

                  A  small  number of "-" flags exist, which now actually are emulator flags, see
                  the description below.

                * Plain arguments are not interpreted in any way. They are  also  stored  by  the
                  init  process and can be retrieved by calling init:get_plain_arguments/0. Plain
                  arguments can occur before the first flag, or after a -- flag. Also, the -extra
                  flag causes everything that follows to become plain arguments.

              Examples:

              % erl +W w -sname arnie +R 9 -s my_init -extra +bertie
              (arnie@host)1> init:get_argument(sname).
              {ok,[["arnie"]]}
              (arnie@host)2> init:get_plain_arguments().
              ["+bertie"]

              Here  +W  w and +R 9 are emulator flags. -s my_init is an init flag, interpreted by
              init. -sname arnie is a user flag, stored by init. It is read by Kernel and  causes
              the  Erlang  runtime system to become distributed. Finally, everything after -extra
              (that is, +bertie) is considered as plain arguments.

              % erl -myflag 1
              1> init:get_argument(myflag).
              {ok,[["1"]]}
              2> init:get_plain_arguments().
              []

              Here the user flag -myflag 1 is passed to and stored by the init process. It  is  a
              user-defined flag, presumably used by some user-defined application.

FLAGS

       In  the  following  list, init flags are marked "(init flag)". Unless otherwise specified,
       all other flags are user  flags,  for  which  the  values  can  be  retrieved  by  calling
       init:get_argument/1.  Notice  that  the list of user flags is not exhaustive, there can be
       more  application-specific  flags  that  instead  are  described  in   the   corresponding
       application documentation.

         -- (init flag):
           Everything  following  --  up  to  the  next flag (-flag or +flag) is considered plain
           arguments and can be retrieved using init:get_plain_arguments/0.

         -Application Par Val:
           Sets the application configuration parameter Par to the value Val for the  application
           Application; see app(5) and application(3erl).

         -args_file FileName:
           Command-line  arguments  are  read from the file FileName. The arguments read from the
           file replace flag '-args_file FileName' on the resulting command line.

           The file FileName is to be a plain text file and can contain comments and command-line
           arguments.  A  comment  begins  with a # character and continues until the next end of
           line character.  Backslash  (\\)  is  used  as  quoting  character.  All  command-line
           arguments  accepted  by erl are allowed, also flag -args_file FileName. Be careful not
           to cause circular dependencies between files containing flag -args_file, though.

           The flag -extra is treated in special way. Its scope ends at  the  end  of  the  file.
           Arguments  following  an  -extra  flag  are  moved on the command line into the -extra
           section, that is, the end of the command line following after an -extra flag.

         -async_shell_start:
           The initial Erlang shell does not read user input until the system boot procedure  has
           been   completed   (Erlang/OTP   5.4   and   later).  This  flag  disables  the  start
           synchronization feature and lets the shell start in parallel  with  the  rest  of  the
           system.

         -boot File:
           Specifies the name of the boot file, File.boot, which is used to start the system; see
           init(3erl). Unless File contains an absolute path, the system searches  for  File.boot
           in the current and $ROOT/bin directories.

           Defaults to $ROOT/bin/start.boot.

         -boot_var Var Dir:
           If  the  boot  script  contains a path variable Var other than $ROOT, this variable is
           expanded to Dir. Used when  applications  are  installed  in  another  directory  than
           $ROOT/lib; see systools:make_script/1,2 in SASL.

         -code_path_cache:
           Enables the code path cache of the code server; see code(3erl).

         -compile Mod1 Mod2 ...:
           Compiles  the  specified  modules  and then terminates (with non-zero exit code if the
           compilation of some file did not succeed). Implies -noinput.

           Not recommended; use erlc instead.

         -config Config:
           Specifies the name of a configuration file, Config.config, which is used to  configure
           applications; see app(5) and application(3erl).

         -connect_all false:
           If  this  flag  is  present,  global  does  not  maintain a fully connected network of
           distributed Erlang nodes, and then  global  name  registration  cannot  be  used;  see
           global(3erl).

         -cookie Cookie:
           Obsolete flag without any effect and common misspelling for -setcookie. Use -setcookie
           instead.

         -detached:
           Starts the Erlang runtime system detached from the system console. Useful for  running
           daemons and backgrounds processes. Implies -noinput.

         -emu_args:
           Useful for debugging. Prints the arguments sent to the emulator.

         -emu_type Type:
           Start  an  emulator  of  a  different  type.  For  example,  to start the lock-counter
           emualator, use -emu_type lcnt. (The emulator must already be built. Use the  configure
           option --enable-lock-counter to build the lock-counter emulator.)

         -env Variable Value:
           Sets  the  host  OS  environment  variable  Variable to the value Value for the Erlang
           runtime system. Example:

         % erl -env DISPLAY gin:0

           In this example, an Erlang runtime system is started with environment variable DISPLAY
           set to gin:0.

         -epmd_module Module (init flag):
           Configures the module responsible to communicate to epmd. Defaults to erl_epmd.

         -eval Expr (init flag):
           Makes init evaluate the expression Expr; see init(3erl).

         -extra (init flag):
           Everything  following  -extra is considered plain arguments and can be retrieved using
           init:get_plain_arguments/0.

         -heart:
           Starts heartbeat monitoring of the Erlang runtime system; see heart(3erl).

         -hidden:
           Starts the Erlang runtime system as a hidden node, if it is run as a distributed node.
           Hidden  nodes  always establish hidden connections to all other nodes except for nodes
           in the same global group. Hidden connections are not published on any of the connected
           nodes, that is, none of the connected nodes are part of the result from nodes/0 on the
           other node. See also hidden global groups; global_group(3erl).

         -hosts Hosts:
           Specifies the IP addresses for the hosts on which Erlang boot servers are running, see
           erl_boot_server(3erl). This flag is mandatory if flag -loader inet is present.

           The  IP  addresses  must  be  specified  in  the  standard  form (four decimal numbers
           separated by periods, for example, "150.236.20.74". Hosts names  are  not  acceptable,
           but a broadcast address (preferably limited to the local network) is.

         -id Id:
           Specifies  the  identity  of  the Erlang runtime system. If it is run as a distributed
           node, Id must be identical to the name supplied together with flag -sname or -name.

         -init_debug:
           Makes init write some debug information while interpreting the boot script.

         -instr (emulator flag):
           Selects an instrumented Erlang runtime system (virtual machine) to run, instead of the
           ordinary  one.  When  running an instrumented runtime system, some resource usage data
           can be obtained and analyzed using the instrument  module.  Functionally,  it  behaves
           exactly like an ordinary Erlang runtime system.

         -loader Loader:
           Specifies  the  method used by erl_prim_loader to load Erlang modules into the system;
           see erl_prim_loader(3erl). Two Loader methods are supported:

           * efile, which means use the local file system, this is the default.

           * inet, which means use a boot server on another machine. The flags  -id,  -hosts  and
             -setcookie must also be specified.

           If Loader is something else, the user-supplied Loader port program is started.

         -make:
           Makes the Erlang runtime system invoke make:all() in the current working directory and
           then terminate; see make(3erl). Implies -noinput.

         -man Module:
           Displays the manual page for the Erlang module Module. Only supported on Unix.

         -mode interactive | embedded:
           Modules are auto loaded when they are first referenced if the runtime system  runs  in
           interactive  mode, which is the default. In embedded mode modules are not auto loaded.
           The latter is recommended when the boot script preloads all modules, as conventionally
           happens in OTP releases. See code(3erl).

         -name Name:
           Makes the Erlang runtime system into a distributed node. This flag invokes all network
           servers necessary for a node to become distributed; see net_kernel(3erl). It  is  also
           ensured  that  epmd runs on the current host before Erlang is started; see epmd(1).and
           the -start_epmd option.

           The node name will be Name@Host, where Host is the fully qualified host  name  of  the
           current host. For short names, use flag -sname instead.

     Warning:
         Starting a distributed node without also specifying -proto_dist inet_tls will expose the
         node to attacks that may give the attacker complete access to the node and in  extension
         the  cluster.  When  using  un-secure  distributed  nodes, make sure that the network is
         configured to keep potential attackers out.

         -noinput:
           Ensures that the Erlang  runtime  system  never  tries  to  read  any  input.  Implies
           -noshell.

         -noshell:
           Starts an Erlang runtime system with no shell. This flag makes it possible to have the
           Erlang runtime system as a component in a series of Unix pipes.

         -nostick:
           Disables the sticky directory facility of the Erlang code server; see code(3erl).

         -oldshell:
           Invokes the old Erlang shell from Erlang/OTP 3.3. The old shell can still be used.

         -pa Dir1 Dir2 ...:
           Adds the specified  directories  to  the  beginning  of  the  code  path,  similar  to
           code:add_pathsa/1.  Note  that  the order of the given directories will be reversed in
           the resulting path.

           As an alternative to -pa, if several directories are to be prepended to the code  path
           and  the  directories  have  a  common  parent directory, that parent directory can be
           specified in environment variable ERL_LIBS; see code(3erl).

         -pz Dir1 Dir2 ...:
           Adds  the  specified  directories  to  the  end  of  the   code   path,   similar   to
           code:add_pathsz/1; see code(3erl).

         -path Dir1 Dir2 ...:
           Replaces the path specified in the boot script; see script(5).

         -proto_dist Proto:

           Specifies a protocol for Erlang distribution:

           inet_tcp:
             TCP over IPv4 (the default)

           inet_tls:
             Distribution  over  TLS/SSL, See the  Using SSL for Erlang Distribution User's Guide
             for details on how to setup a secure distributed node.

           inet6_tcp:
             TCP over IPv6

           For example, to start up IPv6 distributed nodes:

         % erl -name test@ipv6node.example.com -proto_dist inet6_tcp

         -remsh Node:
           Starts Erlang with a remote shell connected to Node.

         -rsh Program:
           Specifies an alternative to rsh for starting a  slave  node  on  a  remote  host;  see
           slave(3erl).

         -run Mod [Func [Arg1, Arg2, ...]] (init flag):
           Makes  init  call  the specified function. Func defaults to start. If no arguments are
           provided, the function is assumed to be of arity 0. Otherwise it is assumed to  be  of
           arity  1,  taking  the  list  [Arg1,Arg2,...] as argument. All arguments are passed as
           strings. See init(3erl).

         -s Mod [Func [Arg1, Arg2, ...]] (init flag):
           Makes init call the specified function. Func defaults to start. If  no  arguments  are
           provided,  the  function is assumed to be of arity 0. Otherwise it is assumed to be of
           arity 1, taking the list [Arg1,Arg2,...] as argument.  All  arguments  are  passed  as
           atoms. See init(3erl).

         -setcookie Cookie:
           Sets the magic cookie of the node to Cookie; see erlang:set_cookie/2.

         -shutdown_time Time:
           Specifies  how  long  time  (in  milliseconds)  the  init  process is allowed to spend
           shutting down the system. If Time  milliseconds  have  elapsed,  all  processes  still
           existing are killed. Defaults to infinity.

         -sname Name:
           Makes  the  Erlang  runtime  system into a distributed node, similar to -name, but the
           host name portion of the node name  Name@Host  will  be  the  short  name,  not  fully
           qualified.

           This  is  sometimes  the  only way to run distributed Erlang if the Domain Name System
           (DNS) is not running. No communication can  exist  between  nodes  running  with  flag
           -sname  and those running with flag -name, as node names must be unique in distributed
           Erlang systems.

     Warning:
         Starting a distributed node without also specifying -proto_dist inet_tls will expose the
         node  to attacks that may give the attacker complete access to the node and in extension
         the cluster. When using un-secure distributed nodes,  make  sure  that  the  network  is
         configured to keep potential attackers out.

         -start_epmd true | false:
           Specifies whether Erlang should start epmd on startup. By default this is true, but if
           you prefer to start epmd manually, set this to false.

           This only applies if Erlang is started as a distributed node, i.e. if -name or  -sname
           is specified. Otherwise, epmd is not started even if -start_epmd true is given.

           Note that a distributed node will fail to start if epmd is not running.

         -version (emulator flag):
           Makes the emulator print its version number. The same as erl +V.

EMULATOR FLAGS

       erl  invokes  the  code  for  the  Erlang  emulator  (virtual machine), which supports the
       following flags:

         +a size:
           Suggested stack size, in kilowords, for threads in the async thread pool. Valid  range
           is  16-8192  kilowords.  The default suggested stack size is 16 kilowords, that is, 64
           kilobyte on 32-bit architectures. This small default size has been chosen because  the
           number of async threads can be large. The default size is enough for drivers delivered
           with Erlang/OTP, but might not be large enough for other dynamically linked-in drivers
           that  use  the  driver_async()  functionality.  Notice that the value passed is only a
           suggestion, and it can even be ignored on some platforms.

         +A size:
           Sets the number of threads in async thread pool. Valid range is 0-1024. Defaults to 1.

         +B [c | d | i]:
           Option c makes Ctrl-C interrupt the current shell instead  of  invoking  the  emulator
           break  handler.  Option d (same as specifying +B without an extra option) disables the
           break handler. Option i makes the emulator ignore any break signal.

           If option c is used with oldshell on Unix,  Ctrl-C  will  restart  the  shell  process
           rather than interrupt it.

           Notice  that  on  Windows,  this flag is only applicable for werl, not erl (oldshell).
           Notice also that Ctrl-Break is used instead of Ctrl-C on Windows.

         +c true | false:
           Enables or disables time correction:

           true:
             Enables time correction. This is the default if time correction is supported on  the
             specific platform.

           false:
             Disables time correction.

           For  backward  compatibility, the boolean value can be omitted. This is interpreted as
           +c false.

         +C no_time_warp | single_time_warp | multi_time_warp:
           Sets time warp mode:

           no_time_warp:
              No time warp mode (the default)

           single_time_warp:
              Single time warp mode

           multi_time_warp:
              Multi-time warp mode

         +d:
           If the emulator detects an internal error (or runs out of  memory),  it,  by  default,
           generates  both  a  crash  dump  and  a core dump. The core dump is, however, not very
           useful as the content of process heaps is destroyed by the crash dump generation.

           Option +d instructs the emulator to produce only a core dump and no crash dump  if  an
           internal error is detected.

           Calling  erlang:halt/1  with  a  string  argument still produces a crash dump. On Unix
           systems, sending an emulator process a SIGUSR1 signal also forces a crash dump.

         +e Number:
           Sets the maximum number of ETS tables. This limit is partially obsolete.

         +ec:
           Forces option compressed on all ETS tables. Only intended for test and evaluation.

         +fnl:
           The virtual machine works with filenames as if they are encoded using the ISO  Latin-1
           encoding, disallowing Unicode characters with code points > 255.

           For  more  information  about  Unicode filenames, see section Unicode Filenames in the
           STDLIB User's Guide. Notice that this value also applies  to  command-line  parameters
           and  environment  variables (see section  Unicode in Environment and Parameters in the
           STDLIB User's Guide).

         +fnu[{w|i|e}]:
           The virtual machine works with filenames as if they are encoded using UTF-8  (or  some
           other system-specific Unicode encoding). This is the default on operating systems that
           enforce Unicode encoding, that is, Windows and MacOS X.

           The +fnu switch can be followed by w, i, or e to control how wrongly encoded filenames
           are to be reported:

           * w  means  that  a  warning  is  sent  to the error_logger whenever a wrongly encoded
             filename is "skipped" in directory listings. This is the default.

           * i means that those wrongly encoded filenames are silently ignored.

           * e means that the API function returns an error whenever a wrongly  encoded  filename
             (or directory name) is encountered.

           Notice  that file:read_link/1 always returns an error if the link points to an invalid
           filename.

           For more information about Unicode filenames, see section  Unicode  Filenames  in  the
           STDLIB  User's  Guide.  Notice that this value also applies to command-line parameters
           and environment variables (see section  Unicode in Environment and Parameters  in  the
           STDLIB User's Guide).

         +fna[{w|i|e}]:
           Selection  between  +fnl  and +fnu is done based on the current locale settings in the
           OS. This means that if you have set your terminal for UTF-8 encoding,  the  filesystem
           is  expected  to use the same encoding for filenames. This is default on all operating
           systems, except MacOS X and Windows.

           The +fna switch can be followed by w, i, or e. This has effect if the locale  settings
           cause  the  behavior of +fnu to be selected; see the description of +fnu above. If the
           locale settings cause the behavior of +fnl to be selected, then w, i,  or  e  have  no
           effect.

           For  more  information  about  Unicode filenames, see section Unicode Filenames in the
           STDLIB User's Guide. Notice that this value also applies  to  command-line  parameters
           and  environment  variables (see section  Unicode in Environment and Parameters in the
           STDLIB User's Guide).

         +hms Size:
           Sets the default heap size of processes to the size Size.

         +hmbs Size:
           Sets the default binary virtual heap size of processes to the size Size.

         +hmax Size:
           Sets the default maximum heap size of processes to the size Size. Defaults to 0, which
           means   that   no   maximum   heap   size   is   used.   For   more  information,  see
           process_flag(max_heap_size, MaxHeapSize).

         +hmaxel true|false:
           Sets whether to send an error logger message or not for processes reaching the maximum
           heap  size.  Defaults  to  true. For more information, see process_flag(max_heap_size,
           MaxHeapSize).

         +hmaxk true|false:
           Sets whether to kill processes reaching the maximum heap size or not. Default to true.
           For more information, see process_flag(max_heap_size, MaxHeapSize).

         +hpds Size:
           Sets the initial process dictionary size of processes to the size Size.

         +hmqd off_heap|on_heap:
           Sets  the  default  value for process flag message_queue_data. Defaults to on_heap. If
           +hmqd is  not  passed,  on_heap  will  be  the  default.  For  more  information,  see
           process_flag(message_queue_data, MQD).

         +IOp PollSets:
           Sets  the  number of IO pollsets to use when polling for I/O. This option is only used
           on platforms that support concurrent updates of a pollset, otherwise the  same  number
           of pollsets are used as IO poll threads. The default is 1.

         +IOt PollThreads:
           Sets  the number of IO poll threads to use when polling for I/O. The maximum number of
           poll threads allowed is 1024. The default is 1.

           A good way to check if more IO poll threads are needed is to use microstate accounting
           and  see what the load of the IO poll thread is. If it is high it could be a good idea
           to add more threads.

         +IOPp PollSetsPercentage:
           Similar to +IOp but uses percentages to set the number of IO pollsets to create, based
           on  the  number  of poll threads configured. If both +IOPp and +IOp are used, +IOPp is
           ignored.

         +IOPt PollThreadsPercentage:
           Similar to +IOt but uses percentages to set the number of IO poll threads  to  create,
           based  on  the number of schedulers configured. If both +IOPt and +IOt are used, +IOPt
           is ignored.

         +l:
           Enables autoload tracing, displaying information while loading code.

         +L:
           Prevents loading information about source filenames and line numbers. This saves  some
           memory,  but  exceptions  do  not  contain  information  about  the filenames and line
           numbers.

         +MFlag Value:
           Memory allocator-specific flags. For more information, see erts_alloc(3erl).

         +pc Range:
           Sets the range  of  characters  that  the  system  considers  printable  in  heuristic
           detection  of  strings.  This  typically  affects  the  shell, debugger, and io:format
           functions (when ~tp is used in the format string).

           Two values are supported for Range:

           latin1:
             The default. Only characters in the ISO Latin-1 range can be  considered  printable.
             This  means  that  a character with a code point > 255 is never considered printable
             and that lists containing such characters are displayed as lists of integers  rather
             than text strings by tools.

           unicode:
             All  printable  Unicode  characters  are  considered  when  determining if a list of
             integers is to be displayed in string syntax. This can give unexpected  results  if,
             for example, your font does not cover all Unicode characters.

           See also io:printable_range/0 in STDLIB.

         +P Number:
           Sets  the  maximum  number  of  simultaneously existing processes for this system if a
           Number is passed as value. Valid range for Number is [1024-134217727]

           NOTE: The actual maximum chosen may be much larger than the Number  passed.  Currently
           the  runtime  system often, but not always, chooses a value that is a power of 2. This
           might, however, be changed in the future. The actual value chosen can  be  checked  by
           calling erlang:system_info(process_limit).

           The default value is 262144

         +Q Number:
           Sets  the  maximum number of simultaneously existing ports for this system if a Number
           is passed as value. Valid range for Number is [1024-134217727]

           NOTE: The actual maximum chosen may be much larger  than  the  actual  Number  passed.
           Currently the runtime system often, but not always, chooses a value that is a power of
           2. This might, however, be changed in the future.  The  actual  value  chosen  can  be
           checked by calling erlang:system_info(port_limit).

           The  default  value  used is normally 65536. However, if the runtime system is able to
           determine maximum amount of file descriptors that it is allowed to open and this value
           is  larger  than  65536, the chosen value will increased to a value larger or equal to
           the maximum amount of file descriptors that can be opened.

           On Windows the default value is set to 8196 because the normal OS limitations are  set
           higher than most machines can handle.

         +R ReleaseNumber:
           Sets the compatibility mode.

           The  distribution  mechanism is not backward compatible by default. This flag sets the
           emulator in compatibility mode with an earlier Erlang/OTP release  ReleaseNumber.  The
           release  number  must  be  in  the  range <current release>-2..<current release>. This
           limits the emulator, making it possible for it to communicate with  Erlang  nodes  (as
           well as C- and Java nodes) running that earlier release.

     Note:
         Ensure that all nodes (Erlang-, C-, and Java nodes) of a distributed Erlang system is of
         the same Erlang/OTP release, or from two different Erlang/OTP releases X  and  Y,  where
         all Y nodes have compatibility mode X.

         +r:
           Forces ETS memory block to be moved on realloc.

         +rg ReaderGroupsLimit:
           Limits  the  number  of  reader  groups  used  by  read/write locks optimized for read
           operations in the Erlang runtime system. By default the reader groups limit is 64.

           When the number of schedulers is less than or equal to the reader groups  limit,  each
           scheduler  has  its own reader group. When the number of schedulers is larger than the
           reader groups limit, schedulers share reader groups. Shared reader groups degrade read
           lock  and  read  unlock  performance  while  many  reader  groups  degrade  write lock
           performance. So, the limit is a tradeoff between performance for read  operations  and
           performance  for  write  operations.  Each  reader  group  consumes  64  byte  in each
           read/write lock.

           Notice that a  runtime  system  using  shared  reader  groups  benefits  from  binding
           schedulers  to logical processors, as the reader groups are distributed better between
           schedulers.

         +S Schedulers:SchedulerOnline:
           Sets the number of scheduler threads to create and scheduler threads  to  set  online.
           The maximum for both values is 1024. If the Erlang runtime system is able to determine
           the  number  of  logical  processors  configured  and  logical  processors  available,
           Schedulers defaults to logical processors configured, and SchedulersOnline defaults to
           logical processors available; otherwise the default values are 1.  Schedulers  can  be
           omitted if :SchedulerOnline is not and conversely. The number of schedulers online can
           be changed at runtime through erlang:system_flag(schedulers_online, SchedulersOnline).

           If Schedulers or SchedulersOnline is specified as a  negative  number,  the  value  is
           subtracted  from  the  default  number  of  logical  processors  configured or logical
           processors available, respectively.

           Specifying value 0 for Schedulers or SchedulersOnline resets the number  of  scheduler
           threads or scheduler threads online, respectively, to its default value.

         +SP SchedulersPercentage:SchedulersOnlinePercentage:
           Similar  to  +S but uses percentages to set the number of scheduler threads to create,
           based on logical processors configured, and scheduler threads to set online, based  on
           logical  processors  available.  Specified  values must be > 0. For example, +SP 50:25
           sets the number of scheduler threads to 50% of the logical processors configured,  and
           the  number  of  scheduler  threads online to 25% of the logical processors available.
           SchedulersPercentage  can  be  omitted  if  :SchedulersOnlinePercentage  is  not   and
           conversely.  The  number  of  schedulers  online  can  be  changed  at runtime through
           erlang:system_flag(schedulers_online, SchedulersOnline).

           This option interacts with +S settings. For example, on a system with 8 logical  cores
           configured  and  8  logical cores available, the combination of the options +S 4:4 +SP
           50:25 (in either order) results in 2 scheduler threads (50%  of  4)  and  1  scheduler
           thread online (25% of 4).

         +SDcpu DirtyCPUSchedulers:DirtyCPUSchedulersOnline:
           Sets  the  number  of  dirty  CPU  scheduler threads to create and dirty CPU scheduler
           threads to set online. The maximum for both values is 1024, and each value is  further
           limited by the settings for normal schedulers:

           * The number of dirty CPU scheduler threads created cannot exceed the number of normal
             scheduler threads created.

           * The number of dirty CPU scheduler threads online cannot exceed the number of  normal
             scheduler threads online.

           For details, see the +S and +SP. By default, the number of dirty CPU scheduler threads
           created equals the number of normal scheduler threads created, and the number of dirty
           CPU  scheduler  threads  online  equals the number of normal scheduler threads online.
           DirtyCPUSchedulers can be omitted if :DirtyCPUSchedulersOnline is not and  conversely.
           The  number  of  dirty  CPU  schedulers  online  can  be  changed  at  runtime through
           erlang:system_flag(dirty_cpu_schedulers_online, DirtyCPUSchedulersOnline).

           The amount of dirty CPU schedulers is limited by the amount of  normal  schedulers  in
           order to limit the effect on processes executing on ordinary schedulers. If the amount
           of dirty CPU schedulers was allowed to  be  unlimited,  dirty  CPU  bound  jobs  would
           potentially starve normal jobs.

         +SDPcpu DirtyCPUSchedulersPercentage:DirtyCPUSchedulersOnlinePercentage:
           Similar  to  +SDcpu  but  uses  percentages  to  set the number of dirty CPU scheduler
           threads to create and the number  of  dirty  CPU  scheduler  threads  to  set  online.
           Specified  values must be > 0. For example, +SDPcpu 50:25 sets the number of dirty CPU
           scheduler threads to 50% of the logical processors configured and the number of  dirty
           CPU   scheduler   threads   online   to  25%  of  the  logical  processors  available.
           DirtyCPUSchedulersPercentage can be omitted if :DirtyCPUSchedulersOnlinePercentage  is
           not  and  conversely.  The  number  of  dirty  CPU schedulers online can be changed at
           runtime            through             erlang:system_flag(dirty_cpu_schedulers_online,
           DirtyCPUSchedulersOnline).

           This  option  interacts  with +SDcpu settings. For example, on a system with 8 logical
           cores configured and 8 logical cores available, the combination of the options  +SDcpu
           4:4  +SDPcpu  50:25 (in either order) results in 2 dirty CPU scheduler threads (50% of
           4) and 1 dirty CPU scheduler thread online (25% of 4).

         +SDio DirtyIOSchedulers:
           Sets the number of dirty I/O scheduler threads to create. Valid range  is  0-1024.  By
           default,  the number of dirty I/O scheduler threads created is 10, same as the default
           number of threads in the async thread pool.

           The amount of dirty IO schedulers is not limited by the amount  of  normal  schedulers
           like the amount of dirty CPU schedulers. This since only I/O bound work is expected to
           execute on dirty I/O schedulers. If the user should schedule CPU bound jobs  on  dirty
           I/O   schedulers,  these  jobs  might  starve  ordinary  jobs  executing  on  ordinary
           schedulers.

         +sFlag Value:
           Scheduling specific flags.

           +sbt BindType:
             Sets scheduler bind type.

             Schedulers can also be bound using flag +stbt. The only difference between these two
             flags is how the following errors are handled:

             * Binding of schedulers is not supported on the specific platform.

             * No  available CPU topology. That is, the runtime system was not able to detect the
               CPU topology automatically, and no user-defined CPU topology was set.

             If any of these errors occur when +sbt has been passed, the runtime system prints an
             error  message,  and  refuses  to start. If any of these errors occur when +stbt has
             been passed, the runtime system silently ignores  the  error,  and  start  up  using
             unbound schedulers.

             Valid BindTypes:

             u:
               unbound  -  Schedulers are not bound to logical processors, that is, the operating
               system decides where the scheduler threads execute, and when to migrate them. This
               is the default.

             ns:
               no_spread  -  Schedulers  with  close  scheduler identifiers are bound as close as
               possible in hardware.

             ts:
               thread_spread - Thread refers to hardware threads (such as Intel's hyper-threads).
               Schedulers  with low scheduler identifiers, are bound to the first hardware thread
               of each core, then schedulers with higher scheduler identifiers are bound  to  the
               second hardware thread of each core,and so on.

             ps:
               processor_spread  -  Schedulers  are  spread  like  thread_spread,  but  also over
               physical processor chips.

             s:
               spread - Schedulers are spread as much as possible.

             nnts:
               no_node_thread_spread - Like thread_spread, but  if  multiple  Non-Uniform  Memory
               Access  (NUMA)  nodes  exist,  schedulers are spread over one NUMA node at a time,
               that is, all logical processors of one  NUMA  node  are  bound  to  schedulers  in
               sequence.

             nnps:
               no_node_processor_spread  -  Like  processor_spread,  but  if  multiple NUMA nodes
               exist, schedulers are spread over one NUMA node at a time, that  is,  all  logical
               processors of one NUMA node are bound to schedulers in sequence.

             tnnps:
               thread_no_node_processor_spread    -   A   combination   of   thread_spread,   and
               no_node_processor_spread. Schedulers are spread over hardware threads across  NUMA
               nodes,  but schedulers are only spread over processors internally in one NUMA node
               at a time.

             db:
               default_bind   -   Binds    schedulers    the    default    way.    Defaults    to
               thread_no_node_processor_spread (which can change in the future).

             Binding  of  schedulers  is  only  supported  on  newer Linux, Solaris, FreeBSD, and
             Windows systems.

             If no CPU topology is available when flag +sbt is  processed  and  BindType  is  any
             other  type  than  u, the runtime system fails to start. CPU topology can be defined
             using flag +sct. Notice that flag +sct can have to be passed before flag +sbt on the
             command line (if no CPU topology has been automatically detected).

             The runtime system does by default not bind schedulers to logical processors.

       Note:
           If  the  Erlang runtime system is the only operating system process that binds threads
           to logical processors, this improves the performance of the runtime  system.  However,
           if  other  operating system processes (for example another Erlang runtime system) also
           bind threads to logical processors, there can be a performance penalty  instead.  This
           performance  penalty  can  sometimes be severe. If so, you are advised not to bind the
           schedulers.

             How schedulers are bound matters. For example, in situations when  there  are  fewer
             running  processes  than  schedulers  online,  the  runtime  system tries to migrate
             processes to schedulers with low scheduler identifiers. The more the schedulers  are
             spread  over the hardware, the more resources are available to the runtime system in
             such situations.

       Note:
           If a scheduler fails to bind, this is often silently ignored,  as  it  is  not  always
           possible to verify valid logical processor identifiers. If an error is reported, it is
           reported to the error_logger. If you want to verify that the schedulers have bound  as
           requested, call erlang:system_info(scheduler_bindings).

           +sbwt none|very_short|short|medium|long|very_long:
             Sets scheduler busy wait threshold. Defaults to medium. The threshold determines how
             long schedulers are to busy wait when running out of work before going to sleep.

       Note:
           This flag can be removed or changed at any time without prior notice.

           +sbwtdcpu none|very_short|short|medium|long|very_long:
             As +sbwt but affects dirty CPU schedulers. Defaults to short.

       Note:
           This flag can be removed or changed at any time without prior notice.

           +sbwtdio none|very_short|short|medium|long|very_long:
             As +sbwt but affects dirty IO schedulers. Defaults to short.

       Note:
           This flag can be removed or changed at any time without prior notice.

           +scl true|false:
             Enables or disables scheduler compaction of load. By default scheduler compaction of
             load is enabled. When enabled, load balancing strives for a load distribution, which
             causes as many scheduler threads as possible to be fully loaded (that  is,  not  run
             out  of  work).  This  is  accomplished  by  migrating  load  (for example, runnable
             processes) into a smaller set of schedulers when schedulers frequently  run  out  of
             work.  When  disabled,  the  frequency  with which schedulers run out of work is not
             taken into account by the load balancing logic.

             +scl false  is  similar  to  +sub  true,  but  +sub  true  also  balances  scheduler
             utilization between schedulers.

           +sct CpuTopology:

             * <Id> = integer(); when 0 =< <Id> =< 65535

             * <IdRange> = <Id>-<Id>

             * <IdOrIdRange> = <Id> | <IdRange>

             * <IdList> = <IdOrIdRange>,<IdOrIdRange> | <IdOrIdRange>

             * <LogicalIds> = L<IdList>

             * <ThreadIds> = T<IdList> | t<IdList>

             * <CoreIds> = C<IdList> | c<IdList>

             * <ProcessorIds> = P<IdList> | p<IdList>

             * <NodeIds> = N<IdList> | n<IdList>

             * <IdDefs>      =      <LogicalIds><ThreadIds><CoreIds><ProcessorIds><NodeIds>     |
               <LogicalIds><ThreadIds><CoreIds><NodeIds><ProcessorIds>

             * CpuTopology = <IdDefs>:<IdDefs> | <IdDefs>

             Sets a user-defined CPU  topology.  The  user-defined  CPU  topology  overrides  any
             automatically  detected  CPU  topology.  The  CPU  topology  is  used  when  binding
             schedulers to logical processors.

             Uppercase letters signify  real  identifiers  and  lowercase  letters  signify  fake
             identifiers  only  used  for description of the topology. Identifiers passed as real
             identifiers can be used by  the  runtime  system  when  trying  to  access  specific
             hardware;  if  they  are  incorrect  the  behavior  is  undefined. Faked logical CPU
             identifiers are not accepted, as there is no point  in  defining  the  CPU  topology
             without  real logical CPU identifiers. Thread, core, processor, and node identifiers
             can be omitted. If omitted, the thread ID defaults to t0, the core  ID  defaults  to
             c0,  the processor ID defaults to p0, and the node ID is left undefined. Either each
             logical processor must belong to only one NUMA node, or no logical  processors  must
             belong to any NUMA nodes.

             Both increasing and decreasing <IdRange>s are allowed.

             NUMA  node  identifiers  are system wide. That is, each NUMA node on the system must
             have  a  unique  identifier.  Processor  identifiers  are  also  system  wide.  Core
             identifiers are processor wide. Thread identifiers are core wide.

             The  order  of  the  identifier types implies the hierarchy of the CPU topology. The
             valid orders are as follows:

             * <LogicalIds><ThreadIds><CoreIds><ProcessorIds><NodeIds>, that is, thread  is  part
               of a core that is part of a processor, which is part of a NUMA node.

             * <LogicalIds><ThreadIds><CoreIds><NodeIds><ProcessorIds>,  that  is, thread is part
               of a core that is part of a NUMA node, which is part of a processor.

             A CPU topology can consist of both processor external, and processor  internal  NUMA
             nodes  as  long  as  each  logical  processor  belongs  to  only  one  NUMA node. If
             <ProcessorIds> is omitted, its default position is before <NodeIds>.  That  is,  the
             default is processor external NUMA nodes.

             If a list of identifiers is used in an <IdDefs>:

             * <LogicalIds> must be a list of identifiers.

             * At  least  one other identifier type besides <LogicalIds> must also have a list of
               identifiers.

             * All lists of identifiers must produce the same number of identifiers.

             A simple example. A single quad core processor can be described as follows:

           % erl +sct L0-3c0-3
           1> erlang:system_info(cpu_topology).
           [{processor,[{core,{logical,0}},
                        {core,{logical,1}},
                        {core,{logical,2}},
                        {core,{logical,3}}]}]

             A more complicated example with two quad core processors, each processor in its  own
             NUMA  node. The ordering of logical processors is a bit weird. This to give a better
             example of identifier lists:

           % erl +sct L0-1,3-2c0-3p0N0:L7,4,6-5c0-3p1N1
           1> erlang:system_info(cpu_topology).
           [{node,[{processor,[{core,{logical,0}},
                               {core,{logical,1}},
                               {core,{logical,3}},
                               {core,{logical,2}}]}]},
            {node,[{processor,[{core,{logical,7}},
                               {core,{logical,4}},
                               {core,{logical,6}},
                               {core,{logical,5}}]}]}]

             As long as real identifiers are correct, it is OK to pass a CPU topology that is not
             a  correct  description  of  the  CPU topology. When used with care this can be very
             useful. This to trick the emulator to bind its schedulers as you want. For  example,
             if  you want to run multiple Erlang runtime systems on the same machine, you want to
             reduce the number of schedulers used and manipulate the CPU topology  so  that  they
             bind  to  different  logical  CPUs. An example, with two Erlang runtime systems on a
             quad core machine:

           % erl +sct L0-3c0-3 +sbt db +S3:2 -detached -noinput -noshell -sname one
           % erl +sct L3-0c0-3 +sbt db +S3:2 -detached -noinput -noshell -sname two

             In this example, each runtime system  have  two  schedulers  each  online,  and  all
             schedulers  online will run on different cores. If we change to one scheduler online
             on one runtime system, and three schedulers online  on  the  other,  all  schedulers
             online will still run on different cores.

             Notice  that  a  faked  CPU topology that does not reflect how the real CPU topology
             looks like is likely to decrease the performance of the runtime system.

             For more information, see erlang:system_info(cpu_topology).

           +sfwi Interval:
             Sets scheduler-forced wakeup interval. All run  queues  are  scanned  each  Interval
             milliseconds.  While  there  are sleeping schedulers in the system, one scheduler is
             woken for each non-empty run queue  found.  Interval  default  to  0,  meaning  this
             feature is disabled.

       Note:
           This  feature  has been introduced as a temporary workaround for long-executing native
           code, and native code that does not bump reductions properly in OTP. When  these  bugs
           have be fixed, this flag will be removed.

           +spp Bool:
             Sets  default  scheduler  hint  for  port  parallelism.  If set to true, the virtual
             machine schedules port tasks when it improves parallelism in the system. If  set  to
             false,  the  virtual  machine  tries  to  perform  port tasks immediately, improving
             latency at the expense of parallelism. Default to false. The  default  used  can  be
             inspected  in  runtime  by calling erlang:system_info(port_parallelism). The default
             can  be  overridden  on   port   creation   by   passing   option   parallelism   to
             erlang:open_port/2.

           +sss size:
             Suggested  stack  size,  in kilowords, for scheduler threads. Valid range is 20-8192
             kilowords. The default suggested stack size is 128 kilowords.

           +sssdcpu size:
             Suggested stack size, in kilowords, for dirty CPU scheduler threads. Valid range  is
             20-8192 kilowords. The default suggested stack size is 40 kilowords.

           +sssdio size:
             Suggested  stack  size, in kilowords, for dirty IO scheduler threads. Valid range is
             20-8192 kilowords. The default suggested stack size is 40 kilowords.

           +stbt BindType:
             Tries to set the scheduler bind type. The same as flag +sbt except how  some  errors
             are handled. For more information, see +sbt.

           +sub true|false:
             Enables  or  disables  scheduler utilization balancing of load. By default scheduler
             utilization balancing is disabled  and  instead  scheduler  compaction  of  load  is
             enabled, which strives for a load distribution that causes as many scheduler threads
             as possible to be fully loaded (that is,  not  run  out  of  work).  When  scheduler
             utilization  balancing  is  enabled,  the  system instead tries to balance scheduler
             utilization between schedulers. That is, strive for equal scheduler  utilization  on
             all schedulers.

             +sub  true  is only supported on systems where the runtime system detects and uses a
             monotonically increasing high-resolution clock. On other systems, the runtime system
             fails to start.

             +sub  true  implies  +scl  false. The difference between +sub true and +scl false is
             that +scl false does not try to balance the scheduler utilization.

           +swct very_eager|eager|medium|lazy|very_lazy:
             Sets scheduler wake cleanup  threshold.  Defaults  to  medium.  Controls  how  eager
             schedulers are to be requesting wakeup because of certain cleanup operations. When a
             lazy setting is used, more outstanding cleanup operations can be left undone while a
             scheduler  is  idling. When an eager setting is used, schedulers are more frequently
             woken, potentially increasing CPU-utilization.

       Note:
           This flag can be removed or changed at any time without prior notice.

           +sws default|legacy:
             Sets scheduler wakeup strategy. Default strategy changed in  ERTS  5.10  (Erlang/OTP
             R16A).  This  strategy  was known as proposal in Erlang/OTP R15. The legacy strategy
             was used as default from R13 up to and including R15.

       Note:
           This flag can be removed or changed at any time without prior notice.

           +swt very_low|low|medium|high|very_high:
             Sets scheduler wakeup threshold. Defaults to medium. The threshold  determines  when
             to wake up sleeping schedulers when more work than can be handled by currently awake
             schedulers exists. A low threshold causes earlier  wakeups,  and  a  high  threshold
             causes later wakeups. Early wakeups distribute work over multiple schedulers faster,
             but work does more easily bounce between schedulers.

       Note:
           This flag can be removed or changed at any time without prior notice.

           +swtdcpu very_low|low|medium|high|very_high:
             As +swt but affects dirty CPU schedulers. Defaults to medium.

       Note:
           This flag can be removed or changed at any time without prior notice.

           +swtdio very_low|low|medium|high|very_high:
             As +swt but affects dirty IO schedulers. Defaults to medium.

       Note:
           This flag can be removed or changed at any time without prior notice.

         +t size:
           Sets the maximum  number  of  atoms  the  virtual  machine  can  handle.  Defaults  to
           1,048,576.

         +T Level:
           Enables  modified  timing  and sets the modified timing level. Valid range is 0-9. The
           timing of the runtime system is changed. A high level usually means a  greater  change
           than  a  low  level. Changing the timing can be very useful for finding timing-related
           bugs.

           Modified timing affects the following:

           Process spawning:
             A process calling spawn, spawn_link, spawn_monitor, or spawn_opt  is  scheduled  out
             immediately  after completing the call. When higher modified timing levels are used,
             the caller also sleeps for a while after it is scheduled out.

           Context reductions:
             The number of reductions a process is allowed to use before it is scheduled  out  is
             increased or reduced.

           Input reductions:
             The number of reductions performed before checking I/O is increased or reduced.

     Note:
         Performance  suffers  when  modified  timing  is enabled. This flag is only intended for
         testing and debugging.

         return_to and return_from trace messages are lost when tracing on the spawn BIFs.

         This flag can be removed or changed at any time without prior notice.

         +v:
           Verbose.

         +V:
           Makes the emulator print its version number.

         +W w | i | e:
           Sets the mapping of warning messages for error_logger.  Messages  sent  to  the  error
           logger  using one of the warning routines can be mapped to errors (+W e), warnings (+W
           w), or information reports (+W i). Defaults to warnings. The current  mapping  can  be
           retrieved    using    error_logger:warning_map/0.    For    more    information,   see
           error_logger:warning_map/0 in Kernel.

         +zFlag Value:
           Miscellaneous flags:

           +zdbbl size:
             Sets the distribution buffer busy limit (dist_buf_busy_limit)  in  kilobytes.  Valid
             range is 1-2097151. Defaults to 1024.

             A  larger  buffer  limit  allows processes to buffer more outgoing messages over the
             distribution. When the buffer limit has been  reached,  sending  processes  will  be
             suspended  until  the  buffer  size has shrunk. The buffer limit is per distribution
             channel. A higher limit gives lower latency and higher throughput at the expense  of
             higher memory use.

           +zdntgc time:
             Sets  the  delayed  node  table  garbage  collection time (delayed_node_table_gc) in
             seconds. Valid values are either infinity or an integer in  the  range  0-100000000.
             Defaults to 60.

             Node table entries that are not referred linger in the table for at least the amount
             of time that this parameter determines. The lingering  prevents  repeated  deletions
             and insertions in the tables from occurring.

ENVIRONMENT VARIABLES

         ERL_CRASH_DUMP:
           If  the  emulator  needs  to  write  a  crash  dump, the value of this variable is the
           filename of the crash dump file. If the variable is not set, the  name  of  the  crash
           dump file is erl_crash.dump in the current directory.

         ERL_CRASH_DUMP_NICE:
           Unix  systems:  If the emulator needs to write a crash dump, it uses the value of this
           variable to set the nice value for the process,  thus  lowering  its  priority.  Valid
           range  is  1-39 (higher values are replaced with 39). The highest value, 39, gives the
           process the lowest priority.

         ERL_CRASH_DUMP_SECONDS:
           Unix systems: This variable gives the number of seconds that the emulator  is  allowed
           to  spend  writing  a  crash  dump. When the given number of seconds have elapsed, the
           emulator is terminated.

           ERL_CRASH_DUMP_SECONDS=0:
             If the variable is set to 0 seconds, the runtime system does  not  even  attempt  to
             write  the crash dump file. It only terminates. This is the default if option -heart
             is passed to erl and ERL_CRASH_DUMP_SECONDS is not set.

           ERL_CRASH_DUMP_SECONDS=S:
             If the variable is set to a positive value S, wait for S  seconds  to  complete  the
             crash dump file and then terminates the runtime system with a SIGALRM signal.

           ERL_CRASH_DUMP_SECONDS=-1:
             A  negative  value causes the termination of the runtime system to wait indefinitely
             until the crash dump file has been completly written. This is the default if  option
             -heart is not passed to erl and ERL_CRASH_DUMP_SECONDS is not set.

           See also heart(3erl).

         ERL_CRASH_DUMP_BYTES:
           This variable sets the maximum size of a crash dump file in bytes. The crash dump will
           be truncated if this limit is exceeded. If the variable is not set, no size  limit  is
           enforced  by  default.  If  the variable is set to 0, the runtime system does not even
           attempt to write a crash dump file.

           Introduced in ERTS 8.1.2 (Erlang/OTP 19.2).

         ERL_AFLAGS:
           The content of this variable is added to the beginning of the command line for erl.

           Flag -extra is treated in a special way. Its scope ends at the end of the  environment
           variable  content.  Arguments  following  an -extra flag are moved on the command line
           into section -extra, that is, the end of the command line following an -extra flag.

         ERL_ZFLAGS and ERL_FLAGS:
           The content of these variables are added to the end of the command line for erl.

           Flag -extra is treated in a special way. Its scope ends at the end of the  environment
           variable  content.  Arguments  following  an -extra flag are moved on the command line
           into section -extra, that is, the end of the command line following an -extra flag.

         ERL_LIBS:
           Contains a list of additional library directories that the code  server  searches  for
           applications and adds to the code path; see code(3erl).

         ERL_EPMD_ADDRESS:
           Can  be  set  to a comma-separated list of IP addresses, in which case the epmd daemon
           listens only on the specified address(es)  and  on  the  loopback  address  (which  is
           implicitly added to the list if it has not been specified).

         ERL_EPMD_PORT:
           Can  contain  the  port  number  to use when communicating with epmd. The default port
           works fine in most cases. A  different  port  can  be  specified  to  allow  nodes  of
           independent clusters to co-exist on the same host. All nodes in a cluster must use the
           same epmd port number.

SIGNALS

       On Unix systems, the Erlang runtime will interpret two types of signals.

         SIGUSR1:
           A SIGUSR1 signal forces a crash dump.

         SIGTERM:
           A SIGTERM will produce a stop message to the init process. This  is  equivalent  to  a
           init:stop/0 call.

           Introduced in ERTS 8.3 (Erlang/OTP 19.3)

       The signal SIGUSR2 is reserved for internal usage. No other signals are handled.

CONFIGURATION

       The  standard  Erlang/OTP  system  can  be  reconfigured to change the default behavior on
       startup.

         The .erlang startup file:
           When Erlang/OTP is started, the system searches for a file named .erlang in the user's
           home directory.

           If  an .erlang file is found, it is assumed to contain valid Erlang expressions. These
           expressions are evaluated as if they were input to the shell.

           A typical .erlang file contains a set of search paths, for example:

         io:format("executing user profile in HOME/.erlang\n",[]).
         code:add_path("/home/calvin/test/ebin").
         code:add_path("/home/hobbes/bigappl-1.2/ebin").
         io:format(".erlang rc finished\n",[]).

         user_default and shell_default:
           Functions in the shell that are not prefixed by  a  module  name  are  assumed  to  be
           functional  objects  (funs),  built-in  functions  (BIFs),  or  belong  to  the module
           user_default or shell_default.

           To include private shell commands, define them in a module user_default  and  add  the
           following argument as the first line in the .erlang file:

         code:load_abs("..../user_default").

         erl:
           If  the  contents  of  .erlang  are  changed  and a private version of user_default is
           defined, the Erlang/OTP environment can be customized. More powerful  changes  can  be
           made  by  supplying  command-line  arguments  in  the  startup  script  erl.  For more
           information, see init(3erl).

SEE ALSO

       epmd(1),   erl_prim_loader(3erl),   erts_alloc(3erl),    init(3erl),    application(3erl),
       auth(3erl), code(3erl), erl_boot_server(3erl), heart(3erl), net_kernel(3erl), make(3erl)