1erl(1)                           User Commands                          erl(1)
2
3
4

NAME

6       erl - The Erlang emulator.
7

DESCRIPTION

9       The erl program starts an Erlang runtime system. The exact details (for
10       example, whether erl is a script or a program and which other  programs
11       it calls) are system-dependent.
12
13       Windows users probably want to use the werl program instead, which runs
14       in its own window with scrollbars and  supports  command-line  editing.
15       The  erl  program on Windows provides no line editing in its shell, and
16       on Windows 95 there is no way to scroll back to text that has  scrolled
17       off  the screen. The erl program must be used, however, in pipelines or
18       if you want to redirect standard input or output.
19
20   Note:
21       As from ERTS 5.9 (Erlang/OTP R15B) the runtime system does  by  default
22       not  bind  schedulers  to logical processors. For more information, see
23       system flag +sbt.
24
25

EXPORTS

27       erl <arguments>
28
29              Starts an Erlang runtime system.
30
31              The arguments can be divided into  emulator  flags,  flags,  and
32              plain arguments:
33
34                * Any  argument starting with character + is interpreted as an
35                  emulator flag.
36
37                  As indicated by the name, emulator flags control the  behav‐
38                  ior of the emulator.
39
40                * Any  argument  starting  with character - (hyphen) is inter‐
41                  preted as a flag, which is to be passed to the  Erlang  part
42                  of  the runtime system, more specifically to the init system
43                  process, see init(3).
44
45                  The init process itself interprets some of these flags,  the
46                  init  flags.  It  also  stores any remaining flags, the user
47                  flags. The latter can be retrieved by calling init:get_argu‐
48                  ment/1.
49
50                  A  small  number  of "-" flags exist, which now actually are
51                  emulator flags, see the description below.
52
53                * Plain arguments are not interpreted in  any  way.  They  are
54                  also  stored  by  the  init  process and can be retrieved by
55                  calling  init:get_plain_arguments/0.  Plain  arguments   can
56                  occur  before  the first flag, or after a -- flag. Also, the
57                  -extra flag causes everything that follows to  become  plain
58                  arguments.
59
60              Examples:
61
62              % erl +W w -sname arnie +R 9 -s my_init -extra +bertie
63              (arnie@host)1> init:get_argument(sname).
64              {ok,[["arnie"]]}
65              (arnie@host)2> init:get_plain_arguments().
66              ["+bertie"]
67
68              Here  +W  w  and  +R 9 are emulator flags. -s my_init is an init
69              flag, interpreted by init. -sname arnie is a user  flag,  stored
70              by init. It is read by Kernel and causes the Erlang runtime sys‐
71              tem to become  distributed.  Finally,  everything  after  -extra
72              (that is, +bertie) is considered as plain arguments.
73
74              % erl -myflag 1
75              1> init:get_argument(myflag).
76              {ok,[["1"]]}
77              2> init:get_plain_arguments().
78              []
79
80              Here the user flag -myflag 1 is passed to and stored by the init
81              process. It is a user-defined  flag,  presumably  used  by  some
82              user-defined application.
83

FLAGS

85       In the following list, init flags are marked "(init flag)". Unless oth‐
86       erwise specified, all other flags are user flags, for which the  values
87       can  be  retrieved by calling init:get_argument/1. Notice that the list
88       of user flags is not exhaustive, there can be more application-specific
89       flags that instead are described in the corresponding application docu‐
90       mentation.
91
92         -- (init flag):
93           Everything following -- up to the next flag  (-flag  or  +flag)  is
94           considered   plain   arguments   and   can   be   retrieved   using
95           init:get_plain_arguments/0.
96
97         -Application Par Val:
98           Sets the application configuration parameter Par to the  value  Val
99           for the application Application; see app(4) and application(3).
100
101         -args_file FileName:
102           Command-line  arguments  are read from the file FileName. The argu‐
103           ments read from the file replace flag '-args_file FileName' on  the
104           resulting command line.
105
106           The  file  FileName is to be a plain text file and can contain com‐
107           ments and command-line arguments. A comment begins with a # charac‐
108           ter  and  continues until the next end of line character. Backslash
109           (\\) is used  as  quoting  character.  All  command-line  arguments
110           accepted  by  erl  are  allowed,  also flag -args_file FileName. Be
111           careful not to cause circular dependencies between files containing
112           flag -args_file, though.
113
114           The  flag  -extra  is treated in special way. Its scope ends at the
115           end of the file. Arguments following an -extra flag  are  moved  on
116           the  command  line into the -extra section, that is, the end of the
117           command line following after an -extra flag.
118
119         -async_shell_start:
120           The initial Erlang shell does not read user input until the  system
121           boot  procedure has been completed (Erlang/OTP 5.4 and later). This
122           flag disables the start synchronization feature and lets the  shell
123           start in parallel with the rest of the system.
124
125         -boot File:
126           Specifies  the  name  of the boot file, File.boot, which is used to
127           start the system; see init(3). Unless  File  contains  an  absolute
128           path,  the  system  searches  for  File.boot  in  the  current  and
129           $ROOT/bin directories.
130
131           Defaults to $ROOT/bin/start.boot.
132
133         -boot_var Var Dir:
134           If the boot script contains a path variable Var other  than  $ROOT,
135           this  variable  is  expanded  to  Dir.  Used  when applications are
136           installed  in  another   directory   than   $ROOT/lib;   see   sys‐
137           tools:make_script/1,2 in SASL.
138
139         -code_path_cache:
140           Enables the code path cache of the code server; see code(3).
141
142         -compile Mod1 Mod2 ...:
143           Compiles  the  specified modules and then terminates (with non-zero
144           exit code if the compilation of some file did not succeed). Implies
145           -noinput.
146
147           Not recommended; use erlc instead.
148
149         -config Config:
150           Specifies the name of a configuration file, Config.config, which is
151           used to configure applications; see app(4) and application(3).
152
153         -connect_all false:
154           If this flag is present, global does not maintain a fully connected
155           network of distributed Erlang nodes, and then global name registra‐
156           tion cannot be used; see global(3).
157
158         -cookie Cookie:
159           Obsolete flag without any effect and common misspelling  for  -set‐
160           cookie. Use -setcookie instead.
161
162         -detached:
163           Starts  the Erlang runtime system detached from the system console.
164           Useful for  running  daemons  and  backgrounds  processes.  Implies
165           -noinput.
166
167         -emu_args:
168           Useful for debugging. Prints the arguments sent to the emulator.
169
170         -emu_type Type:
171           Start  an  emulator  of a different type. For example, to start the
172           lock-counter emualator, use  -emu_type  lcnt.  (The  emulator  must
173           already be built. Use the configure option --enable-lock-counter to
174           build the lock-counter emulator.)
175
176         -env Variable Value:
177           Sets the host OS environment variable Variable to the  value  Value
178           for the Erlang runtime system. Example:
179
180         % erl -env DISPLAY gin:0
181
182           In  this example, an Erlang runtime system is started with environ‐
183           ment variable DISPLAY set to gin:0.
184
185         -epmd_module Module (init flag):
186           Configures the module responsible to communicate to epmd.  Defaults
187           to erl_epmd.
188
189         -eval Expr (init flag):
190           Makes init evaluate the expression Expr; see init(3).
191
192         -extra (init flag):
193           Everything  following  -extra is considered plain arguments and can
194           be retrieved using init:get_plain_arguments/0.
195
196         -heart:
197           Starts heartbeat monitoring  of  the  Erlang  runtime  system;  see
198           heart(3).
199
200         -hidden:
201           Starts  the Erlang runtime system as a hidden node, if it is run as
202           a distributed node. Hidden nodes always  establish  hidden  connec‐
203           tions to all other nodes except for nodes in the same global group.
204           Hidden connections are not published on any of the connected nodes,
205           that  is,  none  of the connected nodes are part of the result from
206           nodes/0  on  the  other  node.  See  also  hidden  global   groups;
207           global_group(3).
208
209         -hosts Hosts:
210           Specifies  the  IP  addresses  for  the  hosts on which Erlang boot
211           servers are running, see erl_boot_server(3). This flag is mandatory
212           if flag -loader inet is present.
213
214           The IP addresses must be specified in the standard form (four deci‐
215           mal numbers separated by  periods,  for  example,  "150.236.20.74".
216           Hosts names are not acceptable, but a broadcast address (preferably
217           limited to the local network) is.
218
219         -id Id:
220           Specifies the identity of the Erlang runtime system. If it  is  run
221           as  a  distributed  node, Id must be identical to the name supplied
222           together with flag -sname or -name.
223
224         -init_debug:
225           Makes init write some debug information while interpreting the boot
226           script.
227
228         -instr (emulator flag):
229           Selects  an instrumented Erlang runtime system (virtual machine) to
230           run, instead of the ordinary one. When running an instrumented run‐
231           time  system, some resource usage data can be obtained and analyzed
232           using the instrument module. Functionally, it behaves exactly  like
233           an ordinary Erlang runtime system.
234
235         -loader Loader:
236           Specifies the method used by erl_prim_loader to load Erlang modules
237           into the system; see erl_prim_loader(3).  Two  Loader  methods  are
238           supported:
239
240           * efile,  which  means  use  the  local  file  system,  this is the
241             default.
242
243           * inet, which means use a boot server on another machine. The flags
244             -id, -hosts and -setcookie must also be specified.
245
246           If  Loader is something else, the user-supplied Loader port program
247           is started.
248
249         -make:
250           Makes the Erlang runtime system invoke make:all()  in  the  current
251           working  directory  and then terminate; see make(3). Implies -noin‐
252           put.
253
254         -man Module:
255           Displays the manual page for the Erlang module  Module.  Only  sup‐
256           ported on Unix.
257
258         -mode interactive | embedded:
259           Modules  are auto loaded when they are first referenced if the run‐
260           time system runs in interactive mode,  which  is  the  default.  In
261           embedded  mode  modules  are  not auto loaded. The latter is recom‐
262           mended when the boot script preloads all modules, as conventionally
263           happens in OTP releases. See code(3).
264
265         -name Name:
266           Makes  the Erlang runtime system into a distributed node. This flag
267           invokes all network servers necessary for a node to become distrib‐
268           uted;  see  net_kernel(3). It is also ensured that epmd runs on the
269           current  host  before  Erlang  is  started;  see  epmd(1).and   the
270           -start_epmd option.
271
272           The  node name will be Name@Host, where Host is the fully qualified
273           host name of the current host. For short  names,  use  flag  -sname
274           instead.
275
276     Warning:
277         Starting  a  distributed  node  without  also  specifying -proto_dist
278         inet_tls will expose the node to attacks that may give  the  attacker
279         complete  access to the node and in extension the cluster. When using
280         un-secure distributed nodes, make sure that the network is configured
281         to keep potential attackers out.
282
283
284         -noinput:
285           Ensures  that  the  Erlang  runtime  system never tries to read any
286           input. Implies -noshell.
287
288         -noshell:
289           Starts an Erlang runtime system with no shell. This flag  makes  it
290           possible  to  have  the  Erlang  runtime system as a component in a
291           series of Unix pipes.
292
293         -nostick:
294           Disables the sticky directory facility of the Erlang  code  server;
295           see code(3).
296
297         -oldshell:
298           Invokes the old Erlang shell from Erlang/OTP 3.3. The old shell can
299           still be used.
300
301         -pa Dir1 Dir2 ...:
302           Adds the specified directories to the beginning of the  code  path,
303           similar  to  code:add_pathsa/1.  Note  that  the order of the given
304           directories will be reversed in the resulting path.
305
306           As an  alternative  to  -pa,  if  several  directories  are  to  be
307           prepended to the code path and the directories have a common parent
308           directory, that parent directory can be  specified  in  environment
309           variable ERL_LIBS; see code(3).
310
311         -pz Dir1 Dir2 ...:
312           Adds the specified directories to the end of the code path, similar
313           to code:add_pathsz/1; see code(3).
314
315         -path Dir1 Dir2 ...:
316           Replaces the path specified in the boot script; see script(4).
317
318         -proto_dist Proto:
319
320
321           Specifies a protocol for Erlang distribution:
322
323           inet_tcp:
324             TCP over IPv4 (the default)
325
326           inet_tls:
327             Distribution over TLS/SSL, See the  Using SSL for Erlang  Distri‐
328             bution User's Guide for details on how to setup a secure distrib‐
329             uted node.
330
331           inet6_tcp:
332             TCP over IPv6
333
334           For example, to start up IPv6 distributed nodes:
335
336         % erl -name test@ipv6node.example.com -proto_dist inet6_tcp
337
338         -remsh Node:
339           Starts Erlang with a remote shell connected to Node.
340
341         -rsh Program:
342           Specifies an alternative to rsh for starting  a  slave  node  on  a
343           remote host; see slave(3).
344
345         -run Mod [Func [Arg1, Arg2, ...]] (init flag):
346           Makes  init call the specified function. Func defaults to start. If
347           no arguments are provided, the function is assumed to be  of  arity
348           0.  Otherwise  it  is  assumed  to  be  of arity 1, taking the list
349           [Arg1,Arg2,...] as argument. All arguments are passed  as  strings.
350           See init(3).
351
352         -s Mod [Func [Arg1, Arg2, ...]] (init flag):
353           Makes  init call the specified function. Func defaults to start. If
354           no arguments are provided, the function is assumed to be  of  arity
355           0.  Otherwise  it  is  assumed  to  be  of arity 1, taking the list
356           [Arg1,Arg2,...] as argument. All arguments are passed as atoms. See
357           init(3).
358
359         -setcookie Cookie:
360           Sets    the   magic   cookie   of   the   node   to   Cookie;   see
361           erlang:set_cookie/2.
362
363         -shutdown_time Time:
364           Specifies how long time  (in  milliseconds)  the  init  process  is
365           allowed  to  spend  shutting  down the system. If Time milliseconds
366           have elapsed, all processes still existing are killed. Defaults  to
367           infinity.
368
369         -sname Name:
370           Makes the Erlang runtime system into a distributed node, similar to
371           -name, but the host name portion of the node name Name@Host will be
372           the short name, not fully qualified.
373
374           This  is  sometimes  the  only way to run distributed Erlang if the
375           Domain Name System (DNS) is not running. No communication can exist
376           between  nodes running with flag -sname and those running with flag
377           -name, as node names must be unique in distributed Erlang systems.
378
379     Warning:
380         Starting a  distributed  node  without  also  specifying  -proto_dist
381         inet_tls  will  expose the node to attacks that may give the attacker
382         complete access to the node and in extension the cluster. When  using
383         un-secure distributed nodes, make sure that the network is configured
384         to keep potential attackers out.
385
386
387         -start_epmd true | false:
388           Specifies whether Erlang should start epmd on startup.  By  default
389           this is true, but if you prefer to start epmd manually, set this to
390           false.
391
392           This only applies if Erlang is started as a distributed node,  i.e.
393           if  -name  or  -sname  is specified. Otherwise, epmd is not started
394           even if -start_epmd true is given.
395
396           Note that a distributed node will fail to start if epmd is not run‐
397           ning.
398
399         -version (emulator flag):
400           Makes the emulator print its version number. The same as erl +V.
401

EMULATOR FLAGS

403       erl  invokes  the code for the Erlang emulator (virtual machine), which
404       supports the following flags:
405
406         +a size:
407           Suggested stack size, in kilowords, for threads in the async thread
408           pool. Valid range is 16-8192 kilowords. The default suggested stack
409           size is 16 kilowords, that is, 64 kilobyte on 32-bit architectures.
410           This small default size has been chosen because the number of async
411           threads can be large. The default size is enough for drivers deliv‐
412           ered  with  Erlang/OTP,  but  might  not  be large enough for other
413           dynamically linked-in drivers that use the driver_async() function‐
414           ality.  Notice  that  the value passed is only a suggestion, and it
415           can even be ignored on some platforms.
416
417         +A size:
418           Sets the number of threads in async thread  pool.  Valid  range  is
419           0-1024. Defaults to 1.
420
421         +B [c | d | i]:
422           Option c makes Ctrl-C interrupt the current shell instead of invok‐
423           ing the emulator break handler. Option d  (same  as  specifying  +B
424           without an extra option) disables the break handler. Option i makes
425           the emulator ignore any break signal.
426
427           If option c is used with oldshell on Unix, Ctrl-C will restart  the
428           shell process rather than interrupt it.
429
430           Notice  that on Windows, this flag is only applicable for werl, not
431           erl (oldshell). Notice also that  Ctrl-Break  is  used  instead  of
432           Ctrl-C on Windows.
433
434         +c true | false:
435           Enables or disables time correction:
436
437           true:
438             Enables  time  correction. This is the default if time correction
439             is supported on the specific platform.
440
441           false:
442             Disables time correction.
443
444           For backward compatibility, the boolean value can be omitted.  This
445           is interpreted as +c false.
446
447         +C no_time_warp | single_time_warp | multi_time_warp:
448           Sets time warp mode:
449
450           no_time_warp:
451              No time warp mode (the default)
452
453           single_time_warp:
454              Single time warp mode
455
456           multi_time_warp:
457              Multi-time warp mode
458
459         +d:
460           If  the emulator detects an internal error (or runs out of memory),
461           it, by default, generates both a crash dump and a  core  dump.  The
462           core  dump  is,  however, not very useful as the content of process
463           heaps is destroyed by the crash dump generation.
464
465           Option +d instructs the emulator to produce only a core dump and no
466           crash dump if an internal error is detected.
467
468           Calling erlang:halt/1 with a string argument still produces a crash
469           dump. On Unix systems, sending an emulator process a SIGUSR1 signal
470           also forces a crash dump.
471
472         +e Number:
473           Sets  the  maximum  number  of  ETS tables. This limit is partially
474           obsolete.
475
476         +ec:
477           Forces option compressed on all ETS tables. Only intended for  test
478           and evaluation.
479
480         +fnl:
481           The  virtual  machine  works  with filenames as if they are encoded
482           using the ISO Latin-1 encoding, disallowing Unicode characters with
483           code points > 255.
484
485           For  more  information about Unicode filenames, see section Unicode
486           Filenames in the STDLIB User's Guide. Notice that this  value  also
487           applies  to  command-line parameters and environment variables (see
488           section  Unicode in Environment and Parameters in the STDLIB User's
489           Guide).
490
491         +fnu[{w|i|e}]:
492           The  virtual  machine  works  with filenames as if they are encoded
493           using UTF-8 (or some other system-specific Unicode encoding).  This
494           is  the default on operating systems that enforce Unicode encoding,
495           that is, Windows and MacOS X.
496
497           The +fnu switch can be followed by  w,  i,  or  e  to  control  how
498           wrongly encoded filenames are to be reported:
499
500           * w  means  that  a  warning is sent to the error_logger whenever a
501             wrongly encoded filename is "skipped" in directory listings. This
502             is the default.
503
504           * i  means  that  those  wrongly  encoded  filenames  are  silently
505             ignored.
506
507           * e means that the API function returns an error whenever a wrongly
508             encoded filename (or directory name) is encountered.
509
510           Notice  that  file:read_link/1  always returns an error if the link
511           points to an invalid filename.
512
513           For more information about Unicode filenames, see  section  Unicode
514           Filenames  in  the STDLIB User's Guide. Notice that this value also
515           applies to command-line parameters and environment  variables  (see
516           section  Unicode in Environment and Parameters in the STDLIB User's
517           Guide).
518
519         +fna[{w|i|e}]:
520           Selection between +fnl and +fnu is done based on the current locale
521           settings  in  the OS. This means that if you have set your terminal
522           for UTF-8 encoding, the filesystem is  expected  to  use  the  same
523           encoding  for  filenames. This is default on all operating systems,
524           except MacOS X and Windows.
525
526           The +fna switch can be followed by w, i, or e. This has  effect  if
527           the  locale settings cause the behavior of +fnu to be selected; see
528           the description of +fnu above. If the  locale  settings  cause  the
529           behavior of +fnl to be selected, then w, i, or e have no effect.
530
531           For  more  information about Unicode filenames, see section Unicode
532           Filenames in the STDLIB User's Guide. Notice that this  value  also
533           applies  to  command-line parameters and environment variables (see
534           section  Unicode in Environment and Parameters in the STDLIB User's
535           Guide).
536
537         +hms Size:
538           Sets the default heap size of processes to the size Size.
539
540         +hmbs Size:
541           Sets  the default binary virtual heap size of processes to the size
542           Size.
543
544         +hmax Size:
545           Sets the default maximum heap size of processes to the  size  Size.
546           Defaults  to  0, which means that no maximum heap size is used. For
547           more information, see process_flag(max_heap_size, MaxHeapSize).
548
549         +hmaxel true|false:
550           Sets whether to send an error logger message or not  for  processes
551           reaching the maximum heap size. Defaults to true. For more informa‐
552           tion, see process_flag(max_heap_size, MaxHeapSize).
553
554         +hmaxk true|false:
555           Sets whether to kill processes reaching the maximum  heap  size  or
556           not.    Default    to    true.    For    more    information,   see
557           process_flag(max_heap_size, MaxHeapSize).
558
559         +hpds Size:
560           Sets the initial process dictionary size of processes to  the  size
561           Size.
562
563         +hmqd off_heap|on_heap:
564           Sets   the  default  value  for  process  flag  message_queue_data.
565           Defaults to on_heap. If +hmqd is not passed, on_heap  will  be  the
566           default. For more information, see process_flag(message_queue_data,
567           MQD).
568
569         +IOp PollSets:
570           Sets the number of IO pollsets to use when polling  for  I/O.  This
571           option is only used on platforms that support concurrent updates of
572           a pollset, otherwise the same number of pollsets  are  used  as  IO
573           poll threads. The default is 1.
574
575         +IOt PollThreads:
576           Sets the number of IO poll threads to use when polling for I/O. The
577           maximum number of poll threads allowed is 1024. The default is 1.
578
579           A good way to check if more IO poll threads are needed  is  to  use
580           microstate  accounting  and see what the load of the IO poll thread
581           is. If it is high it could be a good idea to add more threads.
582
583         +IOPp PollSetsPercentage:
584           Similar to +IOp but uses  percentages  to  set  the  number  of  IO
585           pollsets to create, based on the number of poll threads configured.
586           If both +IOPp and +IOp are used, +IOPp is ignored.
587
588         +IOPt PollThreadsPercentage:
589           Similar to +IOt but uses percentages to set the number of  IO  poll
590           threads to create, based on the number of schedulers configured. If
591           both +IOPt and +IOt are used, +IOPt is ignored.
592
593         +l:
594           Enables autoload  tracing,  displaying  information  while  loading
595           code.
596
597         +L:
598           Prevents  loading  information about source filenames and line num‐
599           bers. This saves some memory, but exceptions do not contain  infor‐
600           mation about the filenames and line numbers.
601
602         +MFlag Value:
603           Memory   allocator-specific   flags.   For  more  information,  see
604           erts_alloc(3).
605
606         +pc Range:
607           Sets the range of characters that the system considers printable in
608           heuristic  detection  of strings. This typically affects the shell,
609           debugger, and io:format functions (when ~tp is used in  the  format
610           string).
611
612           Two values are supported for Range:
613
614           latin1:
615             The default. Only characters in the ISO Latin-1 range can be con‐
616             sidered printable. This means that a character with a code  point
617             >  255  is  never  considered printable and that lists containing
618             such characters are displayed as lists of  integers  rather  than
619             text strings by tools.
620
621           unicode:
622             All  printable Unicode characters are considered when determining
623             if a list of integers is to be displayed in string  syntax.  This
624             can  give  unexpected results if, for example, your font does not
625             cover all Unicode characters.
626
627           See also io:printable_range/0 in STDLIB.
628
629         +P Number:
630           Sets the maximum number of simultaneously  existing  processes  for
631           this  system if a Number is passed as value. Valid range for Number
632           is [1024-134217727]
633
634           NOTE: The actual maximum chosen may be much larger than the  Number
635           passed. Currently the runtime system often, but not always, chooses
636           a value that is a power of 2. This might, however,  be  changed  in
637           the  future.  The  actual  value  chosen  can be checked by calling
638           erlang:system_info(process_limit).
639
640           The default value is 262144
641
642         +Q Number:
643           Sets the maximum number of simultaneously existing ports  for  this
644           system  if  a  Number is passed as value. Valid range for Number is
645           [1024-134217727]
646
647           NOTE: The actual maximum chosen may be much larger than the  actual
648           Number  passed. Currently the runtime system often, but not always,
649           chooses a value that is a power  of  2.  This  might,  however,  be
650           changed  in  the  future. The actual value chosen can be checked by
651           calling erlang:system_info(port_limit).
652
653           The default value used is normally 65536. However, if  the  runtime
654           system is able to determine maximum amount of file descriptors that
655           it is allowed to open and this value is larger than 65536, the cho‐
656           sen  value will increased to a value larger or equal to the maximum
657           amount of file descriptors that can be opened.
658
659           On Windows the default value is set to 8196 because the  normal  OS
660           limitations are set higher than most machines can handle.
661
662         +R ReleaseNumber:
663           Sets the compatibility mode.
664
665           The  distribution  mechanism is not backward compatible by default.
666           This flag sets the emulator in compatibility mode with  an  earlier
667           Erlang/OTP release ReleaseNumber. The release number must be in the
668           range <current release>-2..<current release>. This limits the  emu‐
669           lator,  making  it possible for it to communicate with Erlang nodes
670           (as well as C- and Java nodes) running that earlier release.
671
672     Note:
673         Ensure that all nodes (Erlang-, C-, and Java nodes) of a  distributed
674         Erlang  system is of the same Erlang/OTP release, or from two differ‐
675         ent Erlang/OTP releases X and Y, where all Y nodes have compatibility
676         mode X.
677
678
679         +r:
680           Forces ETS memory block to be moved on realloc.
681
682         +rg ReaderGroupsLimit:
683           Limits  the  number of reader groups used by read/write locks opti‐
684           mized for read operations in the Erlang runtime system. By  default
685           the reader groups limit is 64.
686
687           When  the  number of schedulers is less than or equal to the reader
688           groups limit, each scheduler has its own  reader  group.  When  the
689           number of schedulers is larger than the reader groups limit, sched‐
690           ulers share reader groups. Shared reader groups degrade  read  lock
691           and  read unlock performance while many reader groups degrade write
692           lock performance. So, the limit is a tradeoff  between  performance
693           for  read  operations  and  performance  for write operations. Each
694           reader group consumes 64 byte in each read/write lock.
695
696           Notice that a runtime system using shared  reader  groups  benefits
697           from binding schedulers to logical processors, as the reader groups
698           are distributed better between schedulers.
699
700         +S Schedulers:SchedulerOnline:
701           Sets the number  of  scheduler  threads  to  create  and  scheduler
702           threads  to set online. The maximum for both values is 1024. If the
703           Erlang runtime system is able to determine the  number  of  logical
704           processors  configured and logical processors available, Schedulers
705           defaults to logical  processors  configured,  and  SchedulersOnline
706           defaults  to  logical  processors  available; otherwise the default
707           values are 1. Schedulers can be omitted if :SchedulerOnline is  not
708           and  conversely.  The number of schedulers online can be changed at
709           runtime through erlang:system_flag(schedulers_online, SchedulersOn‐
710           line).
711
712           If  Schedulers  or SchedulersOnline is specified as a negative num‐
713           ber, the value is subtracted from the  default  number  of  logical
714           processors  configured  or  logical  processors  available, respec‐
715           tively.
716
717           Specifying value 0 for Schedulers or  SchedulersOnline  resets  the
718           number  of  scheduler  threads or scheduler threads online, respec‐
719           tively, to its default value.
720
721         +SP SchedulersPercentage:SchedulersOnlinePercentage:
722           Similar to +S but uses percentages to set the number  of  scheduler
723           threads  to  create,  based  on  logical processors configured, and
724           scheduler threads to set online, based on logical processors avail‐
725           able. Specified values must be > 0. For example, +SP 50:25 sets the
726           number of scheduler threads to 50% of the logical  processors  con‐
727           figured,  and  the number of scheduler threads online to 25% of the
728           logical processors available. SchedulersPercentage can  be  omitted
729           if :SchedulersOnlinePercentage is not and conversely. The number of
730           schedulers online can be changed  at  runtime  through  erlang:sys‐
731           tem_flag(schedulers_online, SchedulersOnline).
732
733           This  option  interacts  with +S settings. For example, on a system
734           with 8 logical cores configured and 8 logical cores available,  the
735           combination  of  the  options  +S  4:4  +SP 50:25 (in either order)
736           results in 2 scheduler threads (50% of 4) and  1  scheduler  thread
737           online (25% of 4).
738
739         +SDcpu DirtyCPUSchedulers:DirtyCPUSchedulersOnline:
740           Sets  the number of dirty CPU scheduler threads to create and dirty
741           CPU scheduler threads to set online. The maximum for both values is
742           1024,  and each value is further limited by the settings for normal
743           schedulers:
744
745           * The number of dirty CPU scheduler threads created  cannot  exceed
746             the number of normal scheduler threads created.
747
748           * The  number  of  dirty CPU scheduler threads online cannot exceed
749             the number of normal scheduler threads online.
750
751           For details, see the +S and +SP. By default, the  number  of  dirty
752           CPU scheduler threads created equals the number of normal scheduler
753           threads created, and the number  of  dirty  CPU  scheduler  threads
754           online equals the number of normal scheduler threads online. Dirty‐
755           CPUSchedulers can be omitted if  :DirtyCPUSchedulersOnline  is  not
756           and  conversely.  The  number of dirty CPU schedulers online can be
757           changed  at  runtime  through   erlang:system_flag(dirty_cpu_sched‐
758           ulers_online, DirtyCPUSchedulersOnline).
759
760           The amount of dirty CPU schedulers is limited by the amount of nor‐
761           mal schedulers in order to limit the effect on processes  executing
762           on  ordinary  schedulers. If the amount of dirty CPU schedulers was
763           allowed to be unlimited, dirty CPU  bound  jobs  would  potentially
764           starve normal jobs.
765
766         +SDPcpu DirtyCPUSchedulersPercentage:DirtyCPUSchedulersOnlinePercent‐
767         age:
768           Similar to +SDcpu but uses percentages to set the number  of  dirty
769           CPU  scheduler threads to create and the number of dirty CPU sched‐
770           uler threads to set online. Specified values must be > 0. For exam‐
771           ple,  +SDPcpu  50:25 sets the number of dirty CPU scheduler threads
772           to 50% of the logical processors configured and the number of dirty
773           CPU  scheduler  threads  online  to  25%  of the logical processors
774           available. DirtyCPUSchedulersPercentage can be omitted if  :DirtyC‐
775           PUSchedulersOnlinePercentage  is  not and conversely. The number of
776           dirty CPU schedulers online  can  be  changed  at  runtime  through
777           erlang:system_flag(dirty_cpu_schedulers_online,  DirtyCPUScheduler‐
778           sOnline).
779
780           This option interacts with +SDcpu settings. For example, on a  sys‐
781           tem  with 8 logical cores configured and 8 logical cores available,
782           the combination of the options +SDcpu 4:4 +SDPcpu 50:25 (in  either
783           order)  results  in  2 dirty CPU scheduler threads (50% of 4) and 1
784           dirty CPU scheduler thread online (25% of 4).
785
786         +SDio DirtyIOSchedulers:
787           Sets the number of dirty I/O scheduler  threads  to  create.  Valid
788           range  is  0-1024.  By  default,  the number of dirty I/O scheduler
789           threads created is 10, same as the default number of threads in the
790           async thread pool.
791
792           The  amount  of dirty IO schedulers is not limited by the amount of
793           normal schedulers like the amount of  dirty  CPU  schedulers.  This
794           since  only  I/O  bound  work  is  expected to execute on dirty I/O
795           schedulers. If the user should schedule CPU bound jobs on dirty I/O
796           schedulers,  these  jobs  might  starve  ordinary jobs executing on
797           ordinary schedulers.
798
799         +sFlag Value:
800           Scheduling specific flags.
801
802           +sbt BindType:
803             Sets scheduler bind type.
804
805             Schedulers can also be bound using flag +stbt. The  only  differ‐
806             ence between these two flags is how the following errors are han‐
807             dled:
808
809             * Binding of schedulers is not supported on  the  specific  plat‐
810               form.
811
812             * No  available CPU topology. That is, the runtime system was not
813               able to detect the CPU topology  automatically,  and  no  user-
814               defined CPU topology was set.
815
816             If  any of these errors occur when +sbt has been passed, the run‐
817             time system prints an error message, and refuses to start. If any
818             of  these  errors  occur  when +stbt has been passed, the runtime
819             system silently ignores the error, and  start  up  using  unbound
820             schedulers.
821
822             Valid BindTypes:
823
824             u:
825               unbound  - Schedulers are not bound to logical processors, that
826               is, the operating system decides where  the  scheduler  threads
827               execute, and when to migrate them. This is the default.
828
829             ns:
830               no_spread  -  Schedulers  with  close scheduler identifiers are
831               bound as close as possible in hardware.
832
833             ts:
834               thread_spread - Thread refers  to  hardware  threads  (such  as
835               Intel's  hyper-threads).  Schedulers with low scheduler identi‐
836               fiers, are bound to the first hardware  thread  of  each  core,
837               then  schedulers with higher scheduler identifiers are bound to
838               the second hardware thread of each core,and so on.
839
840             ps:
841               processor_spread - Schedulers are  spread  like  thread_spread,
842               but also over physical processor chips.
843
844             s:
845               spread - Schedulers are spread as much as possible.
846
847             nnts:
848               no_node_thread_spread  -  Like  thread_spread,  but if multiple
849               Non-Uniform Memory Access (NUMA) nodes  exist,  schedulers  are
850               spread  over one NUMA node at a time, that is, all logical pro‐
851               cessors of one NUMA node are bound to schedulers in sequence.
852
853             nnps:
854               no_node_processor_spread - Like processor_spread, but if multi‐
855               ple  NUMA nodes exist, schedulers are spread over one NUMA node
856               at a time, that is, all logical processors of one NUMA node are
857               bound to schedulers in sequence.
858
859             tnnps:
860               thread_no_node_processor_spread     -    A    combination    of
861               thread_spread,  and  no_node_processor_spread.  Schedulers  are
862               spread  over hardware threads across NUMA nodes, but schedulers
863               are only spread over processors internally in one NUMA node  at
864               a time.
865
866             db:
867               default_bind  -  Binds  schedulers the default way. Defaults to
868               thread_no_node_processor_spread  (which  can  change   in   the
869               future).
870
871             Binding  of schedulers is only supported on newer Linux, Solaris,
872             FreeBSD, and Windows systems.
873
874             If no CPU topology is available when flag +sbt is  processed  and
875             BindType  is  any  other type than u, the runtime system fails to
876             start. CPU topology can be defined using flag +sct.  Notice  that
877             flag  +sct  can have to be passed before flag +sbt on the command
878             line (if no CPU topology has been automatically detected).
879
880             The runtime system does by default not bind schedulers to logical
881             processors.
882
883       Note:
884           If  the  Erlang runtime system is the only operating system process
885           that binds threads to logical processors, this improves the perfor‐
886           mance  of  the  runtime  system. However, if other operating system
887           processes (for example another Erlang  runtime  system)  also  bind
888           threads  to  logical processors, there can be a performance penalty
889           instead. This performance penalty can sometimes be severe.  If  so,
890           you are advised not to bind the schedulers.
891
892
893             How schedulers are bound matters. For example, in situations when
894             there are fewer running processes  than  schedulers  online,  the
895             runtime  system tries to migrate processes to schedulers with low
896             scheduler identifiers. The more the schedulers  are  spread  over
897             the  hardware,  the  more  resources are available to the runtime
898             system in such situations.
899
900       Note:
901           If a scheduler fails to bind, this is often silently ignored, as it
902           is  not  always  possible to verify valid logical processor identi‐
903           fiers. If an error is reported, it is reported to the error_logger.
904           If  you want to verify that the schedulers have bound as requested,
905           call erlang:system_info(scheduler_bindings).
906
907
908           +sbwt none|very_short|short|medium|long|very_long:
909             Sets scheduler busy  wait  threshold.  Defaults  to  medium.  The
910             threshold  determines  how  long schedulers are to busy wait when
911             running out of work before going to sleep.
912
913       Note:
914           This flag can be removed or  changed  at  any  time  without  prior
915           notice.
916
917
918           +sbwtdcpu none|very_short|short|medium|long|very_long:
919             As +sbwt but affects dirty CPU schedulers. Defaults to short.
920
921       Note:
922           This  flag  can  be  removed  or  changed at any time without prior
923           notice.
924
925
926           +sbwtdio none|very_short|short|medium|long|very_long:
927             As +sbwt but affects dirty IO schedulers. Defaults to short.
928
929       Note:
930           This flag can be removed or  changed  at  any  time  without  prior
931           notice.
932
933
934           +scl true|false:
935             Enables  or  disables  scheduler  compaction  of load. By default
936             scheduler compaction of load is enabled. When enabled, load  bal‐
937             ancing  strives  for  a  load  distribution, which causes as many
938             scheduler threads as possible to be fully loaded  (that  is,  not
939             run  out  of  work).  This is accomplished by migrating load (for
940             example, runnable processes) into a  smaller  set  of  schedulers
941             when  schedulers  frequently  run out of work. When disabled, the
942             frequency with which schedulers run out of work is not taken into
943             account by the load balancing logic.
944
945             +scl  false  is similar to +sub true, but +sub true also balances
946             scheduler utilization between schedulers.
947
948           +sct CpuTopology:
949
950
951             * <Id> = integer(); when 0 =< <Id> =< 65535
952
953             * <IdRange> = <Id>-<Id>
954
955             * <IdOrIdRange> = <Id> | <IdRange>
956
957             * <IdList> = <IdOrIdRange>,<IdOrIdRange> | <IdOrIdRange>
958
959             * <LogicalIds> = L<IdList>
960
961             * <ThreadIds> = T<IdList> | t<IdList>
962
963             * <CoreIds> = C<IdList> | c<IdList>
964
965             * <ProcessorIds> = P<IdList> | p<IdList>
966
967             * <NodeIds> = N<IdList> | n<IdList>
968
969             * <IdDefs>       =       <LogicalIds><ThreadIds><CoreIds><Proces‐
970               sorIds><NodeIds>         |         <LogicalIds><ThreadIds><Cor‐
971               eIds><NodeIds><ProcessorIds>
972
973             * CpuTopology = <IdDefs>:<IdDefs> | <IdDefs>
974
975             Sets a user-defined CPU topology. The user-defined  CPU  topology
976             overrides any automatically detected CPU topology. The CPU topol‐
977             ogy is used when binding schedulers to logical processors.
978
979             Uppercase letters signify real identifiers and lowercase  letters
980             signify  fake identifiers only used for description of the topol‐
981             ogy. Identifiers passed as real identifiers can be  used  by  the
982             runtime  system  when trying to access specific hardware; if they
983             are incorrect the behavior is undefined. Faked logical CPU  iden‐
984             tifiers  are  not  accepted, as there is no point in defining the
985             CPU topology without real logical CPU identifiers. Thread,  core,
986             processor,  and  node identifiers can be omitted. If omitted, the
987             thread ID defaults to t0, the core ID defaults to c0, the proces‐
988             sor  ID defaults to p0, and the node ID is left undefined. Either
989             each logical processor must belong to only one NUMA node,  or  no
990             logical processors must belong to any NUMA nodes.
991
992             Both increasing and decreasing <IdRange>s are allowed.
993
994             NUMA node identifiers are system wide. That is, each NUMA node on
995             the system must have a unique identifier.  Processor  identifiers
996             are also system wide. Core identifiers are processor wide. Thread
997             identifiers are core wide.
998
999             The order of the identifier types implies the  hierarchy  of  the
1000             CPU topology. The valid orders are as follows:
1001
1002             * <LogicalIds><ThreadIds><CoreIds><ProcessorIds><NodeIds>,   that
1003               is, thread is part of a core that is part of a processor, which
1004               is part of a NUMA node.
1005
1006             * <LogicalIds><ThreadIds><CoreIds><NodeIds><ProcessorIds>,   that
1007               is, thread is part of a core that is part of a NUMA node, which
1008               is part of a processor.
1009
1010             A  CPU  topology can consist of both processor external, and pro‐
1011             cessor internal NUMA nodes as  long  as  each  logical  processor
1012             belongs  to only one NUMA node. If <ProcessorIds> is omitted, its
1013             default position is before <NodeIds>. That  is,  the  default  is
1014             processor external NUMA nodes.
1015
1016             If a list of identifiers is used in an <IdDefs>:
1017
1018             * <LogicalIds> must be a list of identifiers.
1019
1020             * At  least  one  other identifier type besides <LogicalIds> must
1021               also have a list of identifiers.
1022
1023             * All lists of identifiers must produce the same number of  iden‐
1024               tifiers.
1025
1026             A  simple  example. A single quad core processor can be described
1027             as follows:
1028
1029           % erl +sct L0-3c0-3
1030           1> erlang:system_info(cpu_topology).
1031           [{processor,[{core,{logical,0}},
1032                        {core,{logical,1}},
1033                        {core,{logical,2}},
1034                        {core,{logical,3}}]}]
1035
1036             A more complicated example with two quad  core  processors,  each
1037             processor  in  its own NUMA node. The ordering of logical proces‐
1038             sors is a bit weird. This to give a better example of  identifier
1039             lists:
1040
1041           % erl +sct L0-1,3-2c0-3p0N0:L7,4,6-5c0-3p1N1
1042           1> erlang:system_info(cpu_topology).
1043           [{node,[{processor,[{core,{logical,0}},
1044                               {core,{logical,1}},
1045                               {core,{logical,3}},
1046                               {core,{logical,2}}]}]},
1047            {node,[{processor,[{core,{logical,7}},
1048                               {core,{logical,4}},
1049                               {core,{logical,6}},
1050                               {core,{logical,5}}]}]}]
1051
1052             As  long  as real identifiers are correct, it is OK to pass a CPU
1053             topology that is not a correct description of the  CPU  topology.
1054             When  used  with  care this can be very useful. This to trick the
1055             emulator to bind its schedulers as you want. For example, if  you
1056             want  to run multiple Erlang runtime systems on the same machine,
1057             you want to reduce the number of schedulers used  and  manipulate
1058             the  CPU topology so that they bind to different logical CPUs. An
1059             example, with two Erlang runtime systems on a quad core machine:
1060
1061           % erl +sct L0-3c0-3 +sbt db +S3:2 -detached -noinput -noshell -sname one
1062           % erl +sct L3-0c0-3 +sbt db +S3:2 -detached -noinput -noshell -sname two
1063
1064             In this example, each runtime system  have  two  schedulers  each
1065             online, and all schedulers online will run on different cores. If
1066             we change to one scheduler online  on  one  runtime  system,  and
1067             three  schedulers online on the other, all schedulers online will
1068             still run on different cores.
1069
1070             Notice that a faked CPU topology that does not  reflect  how  the
1071             real  CPU  topology  looks like is likely to decrease the perfor‐
1072             mance of the runtime system.
1073
1074             For more information, see erlang:system_info(cpu_topology).
1075
1076           +sfwi Interval:
1077             Sets scheduler-forced wakeup interval. All run queues are scanned
1078             each  Interval  milliseconds. While there are sleeping schedulers
1079             in the system, one scheduler is  woken  for  each  non-empty  run
1080             queue  found. Interval default to 0, meaning this feature is dis‐
1081             abled.
1082
1083       Note:
1084           This feature has been introduced  as  a  temporary  workaround  for
1085           long-executing  native  code,  and  native  code that does not bump
1086           reductions properly in OTP. When these bugs  have  be  fixed,  this
1087           flag will be removed.
1088
1089
1090           +spp Bool:
1091             Sets default scheduler hint for port parallelism. If set to true,
1092             the virtual machine schedules port tasks when it improves  paral‐
1093             lelism  in the system. If set to false, the virtual machine tries
1094             to perform port  tasks  immediately,  improving  latency  at  the
1095             expense of parallelism. Default to false. The default used can be
1096             inspected in runtime by calling erlang:system_info(port_parallel‐
1097             ism).  The  default can be overridden on port creation by passing
1098             option parallelism to erlang:open_port/2.
1099
1100           +sss size:
1101             Suggested stack size, in kilowords, for scheduler threads.  Valid
1102             range  is  20-8192 kilowords. The default suggested stack size is
1103             128 kilowords.
1104
1105           +sssdcpu size:
1106             Suggested stack size,  in  kilowords,  for  dirty  CPU  scheduler
1107             threads.  Valid range is 20-8192 kilowords. The default suggested
1108             stack size is 40 kilowords.
1109
1110           +sssdio size:
1111             Suggested stack  size,  in  kilowords,  for  dirty  IO  scheduler
1112             threads.  Valid range is 20-8192 kilowords. The default suggested
1113             stack size is 40 kilowords.
1114
1115           +stbt BindType:
1116             Tries to set the scheduler bind  type.  The  same  as  flag  +sbt
1117             except  how  some  errors  are handled. For more information, see
1118             +sbt.
1119
1120           +sub true|false:
1121             Enables or disables  scheduler utilization balancing of load.  By
1122             default  scheduler  utilization balancing is disabled and instead
1123             scheduler compaction of load is enabled, which strives for a load
1124             distribution that causes as many scheduler threads as possible to
1125             be fully loaded (that is, not run out of  work).  When  scheduler
1126             utilization  balancing  is  enabled,  the system instead tries to
1127             balance scheduler utilization between schedulers. That is, strive
1128             for equal scheduler utilization on all schedulers.
1129
1130             +sub  true  is only supported on systems where the runtime system
1131             detects  and  uses  a  monotonically  increasing  high-resolution
1132             clock. On other systems, the runtime system fails to start.
1133
1134             +sub  true  implies  +scl false. The difference between +sub true
1135             and +scl false is that +scl false does not  try  to  balance  the
1136             scheduler utilization.
1137
1138           +swct very_eager|eager|medium|lazy|very_lazy:
1139             Sets  scheduler  wake cleanup threshold. Defaults to medium. Con‐
1140             trols how eager schedulers are to be requesting wakeup because of
1141             certain  cleanup  operations.  When  a lazy setting is used, more
1142             outstanding cleanup operations can be left undone while a  sched‐
1143             uler  is  idling.  When  an eager setting is used, schedulers are
1144             more frequently woken, potentially increasing CPU-utilization.
1145
1146       Note:
1147           This flag can be removed or  changed  at  any  time  without  prior
1148           notice.
1149
1150
1151           +sws default|legacy:
1152             Sets  scheduler wakeup strategy. Default strategy changed in ERTS
1153             5.10 (Erlang/OTP R16A). This strategy was known  as  proposal  in
1154             Erlang/OTP  R15. The legacy strategy was used as default from R13
1155             up to and including R15.
1156
1157       Note:
1158           This flag can be removed or  changed  at  any  time  without  prior
1159           notice.
1160
1161
1162           +swt very_low|low|medium|high|very_high:
1163             Sets  scheduler wakeup threshold. Defaults to medium. The thresh‐
1164             old determines when to wake up sleeping schedulers when more work
1165             than  can  be handled by currently awake schedulers exists. A low
1166             threshold causes earlier wakeups, and  a  high  threshold  causes
1167             later wakeups. Early wakeups distribute work over multiple sched‐
1168             ulers faster, but work does more  easily  bounce  between  sched‐
1169             ulers.
1170
1171       Note:
1172           This  flag  can  be  removed  or  changed at any time without prior
1173           notice.
1174
1175
1176           +swtdcpu very_low|low|medium|high|very_high:
1177             As +swt but affects dirty CPU schedulers. Defaults to medium.
1178
1179       Note:
1180           This flag can be removed or  changed  at  any  time  without  prior
1181           notice.
1182
1183
1184           +swtdio very_low|low|medium|high|very_high:
1185             As +swt but affects dirty IO schedulers. Defaults to medium.
1186
1187       Note:
1188           This  flag  can  be  removed  or  changed at any time without prior
1189           notice.
1190
1191
1192         +t size:
1193           Sets the maximum number of atoms the virtual  machine  can  handle.
1194           Defaults to 1,048,576.
1195
1196         +T Level:
1197           Enables  modified  timing and sets the modified timing level. Valid
1198           range is 0-9. The timing of the runtime system is changed.  A  high
1199           level usually means a greater change than a low level. Changing the
1200           timing can be very useful for finding timing-related bugs.
1201
1202           Modified timing affects the following:
1203
1204           Process spawning:
1205             A process calling spawn, spawn_link, spawn_monitor, or  spawn_opt
1206             is  scheduled  out  immediately  after  completing the call. When
1207             higher modified timing levels are used, the  caller  also  sleeps
1208             for a while after it is scheduled out.
1209
1210           Context reductions:
1211             The number of reductions a process is allowed to use before it is
1212             scheduled out is increased or reduced.
1213
1214           Input reductions:
1215             The  number  of  reductions  performed  before  checking  I/O  is
1216             increased or reduced.
1217
1218     Note:
1219         Performance  suffers  when  modified  timing is enabled. This flag is
1220         only intended for testing and debugging.
1221
1222         return_to and return_from trace messages are lost when tracing on the
1223         spawn BIFs.
1224
1225         This flag can be removed or changed at any time without prior notice.
1226
1227
1228         +v:
1229           Verbose.
1230
1231         +V:
1232           Makes the emulator print its version number.
1233
1234         +W w | i | e:
1235           Sets  the  mapping  of  warning messages for error_logger. Messages
1236           sent to the error logger using one of the warning routines  can  be
1237           mapped  to  errors  (+W e), warnings (+W w), or information reports
1238           (+W i). Defaults to warnings. The current mapping can be  retrieved
1239           using   error_logger:warning_map/0.   For   more  information,  see
1240           error_logger:warning_map/0 in Kernel.
1241
1242         +zFlag Value:
1243           Miscellaneous flags:
1244
1245           +zdbbl size:
1246             Sets the distribution buffer busy limit (dist_buf_busy_limit)  in
1247             kilobytes. Valid range is 1-2097151. Defaults to 1024.
1248
1249             A  larger  buffer  limit allows processes to buffer more outgoing
1250             messages over the distribution. When the buffer  limit  has  been
1251             reached,  sending  processes  will  be suspended until the buffer
1252             size has shrunk. The buffer limit is per distribution channel.  A
1253             higher  limit  gives  lower  latency and higher throughput at the
1254             expense of higher memory use.
1255
1256           +zdntgc time:
1257             Sets   the   delayed   node   table   garbage   collection   time
1258             (delayed_node_table_gc)  in  seconds.  Valid  values  are  either
1259             infinity or an integer in the range 0-100000000. Defaults to 60.
1260
1261             Node table entries that are not referred linger in the table  for
1262             at  least  the amount of time that this parameter determines. The
1263             lingering prevents  repeated  deletions  and  insertions  in  the
1264             tables from occurring.
1265
1266           +ztma true | false:
1267             Enables  or disables support for tuple module apply in the emula‐
1268             tor. This is a transitional  flag  for  running  code  that  uses
1269             parameterized  modules  and was compiled under OTP 20 or earlier.
1270             For future compatibility, the modules will need to be  recompiled
1271             with the +tuple_calls compiler option. Defaults to false.
1272

ENVIRONMENT VARIABLES

1274         ERL_CRASH_DUMP:
1275           If  the  emulator  needs  to  write a crash dump, the value of this
1276           variable is the filename of the crash dump file. If the variable is
1277           not  set,  the name of the crash dump file is erl_crash.dump in the
1278           current directory.
1279
1280         ERL_CRASH_DUMP_NICE:
1281           Unix systems: If the emulator needs to write a crash dump, it  uses
1282           the  value  of this variable to set the nice value for the process,
1283           thus lowering its priority. Valid range is 1-39 (higher values  are
1284           replaced  with  39).  The  highest value, 39, gives the process the
1285           lowest priority.
1286
1287         ERL_CRASH_DUMP_SECONDS:
1288           Unix systems: This variable gives the number of  seconds  that  the
1289           emulator  is  allowed to spend writing a crash dump. When the given
1290           number of seconds have elapsed, the emulator is terminated.
1291
1292           ERL_CRASH_DUMP_SECONDS=0:
1293             If the variable is set to 0 seconds, the runtime system does  not
1294             even  attempt  to  write the crash dump file. It only terminates.
1295             This is the default  if  option  -heart  is  passed  to  erl  and
1296             ERL_CRASH_DUMP_SECONDS is not set.
1297
1298           ERL_CRASH_DUMP_SECONDS=S:
1299             If  the variable is set to a positive value S, wait for S seconds
1300             to complete the crash dump file and then terminates  the  runtime
1301             system with a SIGALRM signal.
1302
1303           ERL_CRASH_DUMP_SECONDS=-1:
1304             A  negative value causes the termination of the runtime system to
1305             wait indefinitely until the crash dump file  has  been  completly
1306             written.  This  is  the default if option -heart is not passed to
1307             erl and ERL_CRASH_DUMP_SECONDS is not set.
1308
1309           See also heart(3).
1310
1311         ERL_CRASH_DUMP_BYTES:
1312           This variable sets the maximum size of a crash dump file in  bytes.
1313           The  crash dump will be truncated if this limit is exceeded. If the
1314           variable is not set, no size limit is enforced by default.  If  the
1315           variable  is  set to 0, the runtime system does not even attempt to
1316           write a crash dump file.
1317
1318           Introduced in ERTS 8.1.2 (Erlang/OTP 19.2).
1319
1320         ERL_AFLAGS:
1321           The content of this variable is added to the beginning of the  com‐
1322           mand line for erl.
1323
1324           Flag  -extra is treated in a special way. Its scope ends at the end
1325           of the environment variable content. Arguments following an  -extra
1326           flag  are  moved  on the command line into section -extra, that is,
1327           the end of the command line following an -extra flag.
1328
1329         ERL_ZFLAGS and ERL_FLAGS:
1330           The content of these variables are added to the end of the  command
1331           line for erl.
1332
1333           Flag  -extra is treated in a special way. Its scope ends at the end
1334           of the environment variable content. Arguments following an  -extra
1335           flag  are  moved  on the command line into section -extra, that is,
1336           the end of the command line following an -extra flag.
1337
1338         ERL_LIBS:
1339           Contains a list of additional library  directories  that  the  code
1340           server  searches  for  applications  and adds to the code path; see
1341           code(3).
1342
1343         ERL_EPMD_ADDRESS:
1344           Can be set to a comma-separated list of IP addresses, in which case
1345           the  epmd  daemon  listens only on the specified address(es) and on
1346           the loopback address (which is implicitly added to the list  if  it
1347           has not been specified).
1348
1349         ERL_EPMD_PORT:
1350           Can  contain  the  port number to use when communicating with epmd.
1351           The default port works fine in most cases. A different port can  be
1352           specified to allow nodes of independent clusters to co-exist on the
1353           same host. All nodes in a cluster must use the same epmd port  num‐
1354           ber.
1355

SIGNALS

1357       On  Unix  systems,  the Erlang runtime will interpret two types of sig‐
1358       nals.
1359
1360         SIGUSR1:
1361           A SIGUSR1 signal forces a crash dump.
1362
1363         SIGTERM:
1364           A SIGTERM will produce a stop message to the init process. This  is
1365           equivalent to a init:stop/0 call.
1366
1367           Introduced in ERTS 8.3 (Erlang/OTP 19.3)
1368
1369       The signal SIGUSR2 is reserved for internal usage. No other signals are
1370       handled.
1371

CONFIGURATION

1373       The standard Erlang/OTP  system  can  be  reconfigured  to  change  the
1374       default behavior on startup.
1375
1376         The .erlang startup file:
1377           When  Erlang/OTP  is  started, the system searches for a file named
1378           .erlang in the user's home directory.
1379
1380           If an .erlang file is found, it is assumed to contain valid  Erlang
1381           expressions.  These expressions are evaluated as if they were input
1382           to the shell.
1383
1384           A typical .erlang file contains a set of search paths, for example:
1385
1386         io:format("executing user profile in HOME/.erlang\n",[]).
1387         code:add_path("/home/calvin/test/ebin").
1388         code:add_path("/home/hobbes/bigappl-1.2/ebin").
1389         io:format(".erlang rc finished\n",[]).
1390
1391         user_default and shell_default:
1392           Functions in the shell that are not prefixed by a module  name  are
1393           assumed to be functional objects (funs), built-in functions (BIFs),
1394           or belong to the module user_default or shell_default.
1395
1396           To  include  private  shell  commands,  define  them  in  a  module
1397           user_default  and  add  the following argument as the first line in
1398           the .erlang file:
1399
1400         code:load_abs("..../user_default").
1401
1402         erl:
1403           If the contents of .erlang are changed and  a  private  version  of
1404           user_default  is defined, the Erlang/OTP environment can be custom‐
1405           ized. More powerful changes can be made by  supplying  command-line
1406           arguments  in  the  startup  script  erl. For more information, see
1407           init(3).
1408

SEE ALSO

1410       epmd(1), erl_prim_loader(3),  erts_alloc(3),  init(3),  application(3),
1411       auth(3), code(3), erl_boot_server(3), heart(3), net_kernel(3), make(3)
1412
1413
1414
1415Ericsson AB                      erts 10.3.5.2                          erl(1)
Impressum