Provided by: erlang-base_24.2.1+dfsg-1ubuntu0.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 [Config ...]:
           Specifies the name of one or more configuration files, Config.config, which is used to
           configure  applications;  see  app(5) and application(3erl). See the documentation for
           the configuration file format for a description of the configuration  format  and  the
           order in which configuration parameters are read.

         -configfd FD [FD ...]:
           Specifies  the  name  of  one  or  more  file  descriptors  (called configuration file
           descriptors from here on) with configuration data for  applications;  see  app(5)  and
           application(3erl).  See  the  documentation  for  the  configuration file format for a
           description  of  the  configuration  format  and  the  order  in  which  configuration
           parameters are read.

           A configuration file descriptor will be read until its end and will then be closed.

           The content of a configuration file descriptor is stored so that it can be reused when
           init:restart/0 or init:restart/1 is called.

           The parameter -configfd 0 implies -noinput.

     Note:
         It is not recommended to use file descriptors  1  (standard  output),  and  2  (standard
         error)  together  with  -configfd  as these file descriptors are typically used to print
         information to the console the program is running in.

           Examples (Unix shell):

         $ erl \ -noshell \ -configfd 3 \ -eval \ 'io:format("~p~n",[application:get_env(kernel, logger_level)]),erlang:halt()' 3< \ <(echo '[{kernel, [{logger_level, warning}]}].')
         {ok,warning}

         $ echo '[{kernel, [{logger_level, warning}]}].' > test1.config
         $ echo '[{kernel, [{logger_level, error}]}].' > test2.config
         $ erl \ -noshell \ -configfd 3 \ -configfd 4 \ -eval \ 'io:format("~p~n",[application:get_env(kernel, logger_level)]),erlang:halt()' \ 3< test1.config 4< test2.config
         {ok,error}

         -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_flavor emu|jit|smp:
           Start an emulator of a different flavor. Normally only one flavor is  available,  more
           can  be  added  by building specific flavors. The currently available flavors are: emu
           and jit. The smp flavor is an alias for the current default flavor.  You  can  combine
           this  flag  with  --emu_type.  You  can  get  the  current  flavor  at  run-time using
           erlang:system_info(emu_flavor). (The emulator with this flavor must be built. You  can
           build  a  specific  flavor  by  doing  make  FLAVOR=$FLAVOR  in  the Erlang/OTP source
           repository.)

         -emu_type Type:
           Start an emulator of  a  different  type.  For  example,  to  start  the  lock-counter
           emulator,  use  -emu_type  lcnt.  You  can  get  the  current  type  at run-time using
           erlang:system_info(build_type). (The emulator of this type 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.

         -erl_epmd_port Port (init flag):
           Configures  the  port  used  by erl_epmd to listen for connection and connect to other
           nodes. See erl_epmd for more details. Defaults to 0.

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

           If Name is set to undefined the node will be started in a special mode optimized to be
           the  temporary  client  of  another node. When enabled the node will request a dynamic
           node name from the first node it connects to. In addition these distribution  settings
           will be set:

         -dist_listen false -hidden -dist_auto_connect never

           Because  -dist_auto_connect  is  set  to  never, the system will have to manually call
           net_kernel:connect_node/1 in order to start  the  distribution.  If  the  distribution
           channel  is  closed,  when  a  node  uses  a dynamic node name, the node will stop the
           distribution and a new call to net_kernel:connect_node/1 has to be made. Note that the
           node name may change if the distribution is dropped and then set up again.

     Note:
         The  dynamic  node name feature is supported from OTP 23. Both the temporary client node
         and the first connected peer node (supplying the dynamic node name) must be at least OTP
         23 for it to work.

     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.

         -no_epmd:
           Specifies that the distributed node does not need epmd at all.

           This option ensures that the Erlang runtime system does not start epmd  and  does  not
           start the erl_epmd process for distribution either.

           This option only works if Erlang is started as a distributed node with the -proto_dist
           option using an alternative protocol for Erlang distribution which does  not  rely  on
           epmd  for  node registration and discovery. For more information, see How to implement
           an Alternative Carrier for the Erlang Distribution.

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

           If no -name or -sname is given the node will be started  using  -sname  undefined.  If
           Node does not contain a hostname, one is automatically taken from -name or -sname

     Note:
         Before OTP-23 the user needed to supply a valid -sname or -name for -remsh to work. This
         is still the case if the target node is not running OTP-23 or later.

         -rsh Program:
           Specifies an alternative to ssh 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.

         -setcookie Node Cookie:
           Sets the magic cookie for 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  1-1024.  The  async
           thread  pool  is  used  by  linked-in drivers to handle work that may take a very long
           time. Since OTP 21 there are very few linked-in  drivers  in  the  default  Erlang/OTP
           distribution that uses the async thread pool. Most of them have been migrated to dirty
           IO schedulers. 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.

         +dcg DecentralizedCounterGroupsLimit:
           Limits the number of decentralized  counter  groups  used  by  decentralized  counters
           optimized for update operations in the Erlang runtime system. By default, the limit is
           256.

           When the number of schedulers is less than or equal to the limit, each  scheduler  has
           its  own  group.  When  the  number  of  schedulers  is  larger than the groups limit,
           schedulers share groups. Shared groups degrade the performance for  updating  counters
           while  many  reader groups degrade the performance for reading counters. So, the limit
           is a tradeoff between performance for  update  operations  and  performance  for  read
           operations. Each group consumes 64 bytes in each counter.

           Notice  that a runtime system using decentralized counter groups benefits from binding
           schedulers to logical  processors,  as  the  groups  are  distributed  better  between
           schedulers with this option.

           This option only affects decentralized counters used for the counters that are keeping
           track of the memory consumption and  the  number  of  terms  in  ETS  tables  of  type
           ordered_set with the write_concurrency option activated.

         +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 MacOS X and Android.

           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  the  default  on  all
           operating systems, except Android, 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 of the message_queue_data process flag. 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.

         +JPperf true|false:
           Enables  or  disables  support  for  the  `perf` profiler when running with the JIT on
           Linux. Defaults to false.

           For more details about how to run perf see the perf support  section  in  the  BeamAsm
           internal documentation.

         +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. If the emulator
           detects that it is subject to a CPU quota, the default value for SchedulersOnline will
           be limited accordingly.

           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.

           Typical users of the dirty CPU schedulers are large garbage collections, json protocol
           encode/decoders written as nifs and matrix manipulation libraries.

           You  can  use msacc(3erl) in order to see the current load of the dirty CPU schedulers
           threads and adjust the number used accordingly.

         +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 1-1024. By
           default, the number of dirty I/O scheduler threads created is 10.

           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.

           Typical users of the dirty IO schedulers are reading and writing to files.

           You can use msacc(3erl) in order to see the current load of the  dirty  IO  schedulers
           threads and adjust the number used accordingly.

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

           +zosrl limit:
             Sets a limit on the  amount  of  outstanding  requests  made  by  a  system  process
             orchestrating  system wide changes. Valid range of this limit is [1, 134217727]. See
             erlang:system_flag(outstanding_system_requests_limit, Limit) for more information.

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)