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           Indicates  if the system is to load code dynamically (interactive),
260           or if all code is to be loaded during system initialization (embed‐
261           ded); see code(3). Defaults to interactive.
262
263         -name Name:
264           Makes  the Erlang runtime system into a distributed node. This flag
265           invokes all network servers necessary for a node to become distrib‐
266           uted;  see  net_kernel(3). It is also ensured that epmd runs on the
267           current  host  before  Erlang  is  started;  see  epmd(1).and   the
268           -start_epmd option.
269
270           The  node name will be Name@Host, where Host is the fully qualified
271           host name of the current host. For short  names,  use  flag  -sname
272           instead.
273
274     Warning:
275         Starting  a  distributed  node  without  also  specifying -proto_dist
276         inet_tls will expose the node to attacks that may give  the  attacker
277         complete  access to the node and in extension the cluster. When using
278         un-secure distributed nodes, make sure that the network is configured
279         to keep potential attackers out.
280
281
282         -noinput:
283           Ensures  that  the  Erlang  runtime  system never tries to read any
284           input. Implies -noshell.
285
286         -noshell:
287           Starts an Erlang runtime system with no shell. This flag  makes  it
288           possible  to  have  the  Erlang  runtime system as a component in a
289           series of Unix pipes.
290
291         -nostick:
292           Disables the sticky directory facility of the Erlang  code  server;
293           see code(3).
294
295         -oldshell:
296           Invokes the old Erlang shell from Erlang/OTP 3.3. The old shell can
297           still be used.
298
299         -pa Dir1 Dir2 ...:
300           Adds the specified directories to the beginning of the  code  path,
301           similar  to  code:add_pathsa/1.  Note  that  the order of the given
302           directories will be reversed in the resulting path.
303
304           As an  alternative  to  -pa,  if  several  directories  are  to  be
305           prepended to the code path and the directories have a common parent
306           directory, that parent directory can be  specified  in  environment
307           variable ERL_LIBS; see code(3).
308
309         -pz Dir1 Dir2 ...:
310           Adds the specified directories to the end of the code path, similar
311           to code:add_pathsz/1; see code(3).
312
313         -path Dir1 Dir2 ...:
314           Replaces the path specified in the boot script; see script(4).
315
316         -proto_dist Proto:
317
318
319           Specifies a protocol for Erlang distribution:
320
321           inet_tcp:
322             TCP over IPv4 (the default)
323
324           inet_tls:
325             Distribution over TLS/SSL, See the  Using SSL for Erlang  Distri‐
326             bution User's Guide for details on how to setup a secure distrib‐
327             uted node.
328
329           inet6_tcp:
330             TCP over IPv6
331
332           For example, to start up IPv6 distributed nodes:
333
334         % erl -name test@ipv6node.example.com -proto_dist inet6_tcp
335
336         -remsh Node:
337           Starts Erlang with a remote shell connected to Node.
338
339         -rsh Program:
340           Specifies an alternative to rsh for starting  a  slave  node  on  a
341           remote host; see slave(3).
342
343         -run Mod [Func [Arg1, Arg2, ...]] (init flag):
344           Makes  init call the specified function. Func defaults to start. If
345           no arguments are provided, the function is assumed to be  of  arity
346           0.  Otherwise  it  is  assumed  to  be  of arity 1, taking the list
347           [Arg1,Arg2,...] as argument. All arguments are passed  as  strings.
348           See init(3).
349
350         -s Mod [Func [Arg1, Arg2, ...]] (init flag):
351           Makes  init call the specified function. Func defaults to start. If
352           no arguments are provided, the function is assumed to be  of  arity
353           0.  Otherwise  it  is  assumed  to  be  of arity 1, taking the list
354           [Arg1,Arg2,...] as argument. All arguments are passed as atoms. See
355           init(3).
356
357         -setcookie Cookie:
358           Sets    the   magic   cookie   of   the   node   to   Cookie;   see
359           erlang:set_cookie/2.
360
361         -shutdown_time Time:
362           Specifies how long time  (in  milliseconds)  the  init  process  is
363           allowed  to  spend  shutting  down the system. If Time milliseconds
364           have elapsed, all processes still existing are killed. Defaults  to
365           infinity.
366
367         -sname Name:
368           Makes the Erlang runtime system into a distributed node, similar to
369           -name, but the host name portion of the node name Name@Host will be
370           the short name, not fully qualified.
371
372           This  is  sometimes  the  only way to run distributed Erlang if the
373           Domain Name System (DNS) is not running. No communication can exist
374           between  nodes running with flag -sname and those running with flag
375           -name, as node names must be unique in distributed Erlang systems.
376
377     Warning:
378         Starting a  distributed  node  without  also  specifying  -proto_dist
379         inet_tls  will  expose the node to attacks that may give the attacker
380         complete access to the node and in extension the cluster. When  using
381         un-secure distributed nodes, make sure that the network is configured
382         to keep potential attackers out.
383
384
385         -start_epmd true | false:
386           Specifies whether Erlang should start epmd on startup.  By  default
387           this is true, but if you prefer to start epmd manually, set this to
388           false.
389
390           This only applies if Erlang is started as a distributed node,  i.e.
391           if  -name  or  -sname  is specified. Otherwise, epmd is not started
392           even if -start_epmd true is given.
393
394           Note that a distributed node will fail to start if epmd is not run‐
395           ning.
396
397         -smp [enable|auto|disable]:
398           -smp  enable and -smp start the Erlang runtime system with SMP sup‐
399           port enabled. This can fail if no runtime system with  SMP  support
400           is  available.  -smp auto starts the Erlang runtime system with SMP
401           support enabled if it is available and more than one  logical  pro‐
402           cessor  is  detected.  -smp disable starts a runtime system without
403           SMP support. The runtime system without SMP support  is  deprecated
404           and will be removed in a future major release.
405
406     Note:
407         See also flag+S.
408
409
410         -version (emulator flag):
411           Makes the emulator print its version number. The same as erl +V.
412

EMULATOR FLAGS

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

ENVIRONMENT VARIABLES

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

SIGNALS

1341       On  Unix  systems,  the Erlang runtime will interpret two types of sig‐
1342       nals.
1343
1344         SIGUSR1:
1345           A SIGUSR1 signal forces a crash dump.
1346
1347         SIGTERM:
1348           A SIGTERM will produce a stop message to the init process. This  is
1349           equivalent to a init:stop/0 call.
1350
1351           Introduced in ERTS 8.3 (Erlang/OTP 19.3)
1352
1353       The signal SIGUSR2 is reserved for internal usage. No other signals are
1354       handled.
1355

CONFIGURATION

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

SEE ALSO

1395       epmd(1),  erl_prim_loader(3),  erts_alloc(3),  init(3), application(3),
1396       auth(3), code(3), erl_boot_server(3), heart(3), net_kernel(3), make(3)
1397
1398
1399
1400Ericsson AB                      erts 9.3.3.10                          erl(1)
Impressum