Provided by: erlang-base_25.3.2.12+dfsg-1ubuntu2_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:
           This flag is deprecated and has been replaced by the kernel application parameter connect_all.

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

         -disable-feature feature:
           Disables the feature feature in the runtime system. The special feature all can be  used  to  disable
           all non permanent features.

         -dist_listen true|false:
           Specifies  whether  this  node  should  be listening for incoming distribution connections or not. By
           default a node will listen for incoming connections. Setting this option to false implies -hidden.

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

         -enable-feature feature:
           Enables the feature feature in the runtime system. The special feature all can be used to enable  all
           features.

         -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 also ensures that epmd  runs  on
           the  current  host before Erlang is started (see epmd(1) and the -start_epmd option) and that a magic
           cookie has been set (see -setcookie).

           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. The node will then request a  dynamic  node  name  from  the  first  node  it
           connects to. Read more in  Dynamic Node Name.

     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.

     Note:
         The  connecting  node  needs to have a proper shell with terminal emulation. This means that UNIX users
         must use an Erlang compiled with terminal capabilities and Windows users must use werl(1).

         -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/1.  See  see  section  Distributed
           Erlang in the Erlang Reference Manual for more details.

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

           If Name is set to undefined the node will be started in a special mode optimized to be the  temporary
           client  of  another  node.  The  node  will  then  request a dynamic node name from the first node it
           connects to. Read more in  Dynamic Node Name.

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

         +IOs true|false:
           Enable or disable scheduler thread poll optimization. Default is true.

           If  enabled,  file  descriptors  that  are  frequently read may be moved to a special pollset used by
           scheduler threads. The objective is to reduce the number of system calls and thereby CPU load, but it
           can in some cases increase scheduling latency for individual file descriptor input events.

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

           This option can be combined multiple times to enable several options:

           dump:
             Gives perf detailed line information, so that the perf annotate feature works.

           map:
             Gives perf a map over all module code, letting it translate machine code addresses to Erlang source
             code  locations.  This  also  enables frame pointers for Erlang code so that perf can walk the call
             stacks of Erlang processes, which costs one extra word per stack frame.

           fp:
             Enables frame pointers independently of the map option.

           no_fp:
             Disables the frame pointers added by the map option.

           true:
             Enables map and dump.

           false:
             Disables all other options.

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

         +pad true|false:
           Since: OTP 25.3

           The boolean value used with the +pad parameter determines the default value of the async_dist process
           flag of newly spawned processes. By default, if no +pad command line option is passed, the async_dist
           flag will be set to false.

           The value used in runtime can be inspected by calling erlang:system_info(async_dist).

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

           +ssrct:
             Skips reading CPU topology.

       Note:
           Reading CPU topology slows down startup when starting many parallel instances of ERTS on systems with
           large amount of cores, using this flag might speed up execution in such scenarios.

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

             This limit only affects processes that have disabled fully asynchronous distributed signaling .

           +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 completely 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 and then filename:basedir(user_config, "erlang").

           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)