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  oc‐
56                  cur  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  ac‐
110           cepted  by erl are allowed, also flag -args_file FileName. Be care‐
111           ful 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 in‐
136           stalled   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 [Config]:
150           Specifies  the name of one or more configuration files, Config.con‐
151           fig, which is used to configure applications; see app(4) and appli‐
152           cation(3).
153
154         -connect_all false:
155           If this flag is present, global does not maintain a fully connected
156           network of distributed Erlang nodes, and then global name registra‐
157           tion cannot be used; see global(3).
158
159         -cookie Cookie:
160           Obsolete  flag  without any effect and common misspelling for -set‐
161           cookie. Use -setcookie instead.
162
163         -detached:
164           Starts the Erlang runtime system detached from the system  console.
165           Useful  for  running  daemons  and  backgrounds  processes. Implies
166           -noinput.
167
168         -emu_args:
169           Useful for debugging. Prints the arguments sent to the emulator.
170
171         -emu_type Type:
172           Start an emulator of a different type. For example,  to  start  the
173           lock-counter  emualator, use -emu_type lcnt. (The emulator must al‐
174           ready be built. Use the configure option  --enable-lock-counter  to
175           build the lock-counter emulator.)
176
177         -env Variable Value:
178           Sets  the  host OS environment variable Variable to the value Value
179           for the Erlang runtime system. Example:
180
181         % erl -env DISPLAY gin:0
182
183           In this example, an Erlang runtime system is started with  environ‐
184           ment variable DISPLAY set to gin:0.
185
186         -epmd_module Module (init flag):
187           Configures  the module responsible to communicate to epmd. Defaults
188           to erl_epmd.
189
190         -erl_epmd_port Port (init flag):
191           Configures the port used by erl_epmd to listen for  connection  and
192           connect  to other nodes. See erl_epmd for more details. Defaults to
193           0.
194
195         -eval Expr (init flag):
196           Makes init evaluate the expression Expr; see init(3).
197
198         -extra (init flag):
199           Everything following -extra is considered plain arguments  and  can
200           be retrieved using init:get_plain_arguments/0.
201
202         -heart:
203           Starts  heartbeat  monitoring  of  the  Erlang  runtime system; see
204           heart(3).
205
206         -hidden:
207           Starts the Erlang runtime system as a hidden node, if it is run  as
208           a  distributed  node.  Hidden nodes always establish hidden connec‐
209           tions to all other nodes except for nodes in the same global group.
210           Hidden connections are not published on any of the connected nodes,
211           that is, none of the connected nodes are part of  the  result  from
212           nodes/0   on  the  other  node.  See  also  hidden  global  groups;
213           global_group(3).
214
215         -hosts Hosts:
216           Specifies the IP addresses for  the  hosts  on  which  Erlang  boot
217           servers are running, see erl_boot_server(3). This flag is mandatory
218           if flag -loader inet is present.
219
220           The IP addresses must be specified in the standard form (four deci‐
221           mal  numbers  separated  by  periods, for example, "150.236.20.74".
222           Hosts names are not acceptable, but a broadcast address (preferably
223           limited to the local network) is.
224
225         -id Id:
226           Specifies  the  identity of the Erlang runtime system. If it is run
227           as a distributed node, Id must be identical to  the  name  supplied
228           together with flag -sname or -name.
229
230         -init_debug:
231           Makes init write some debug information while interpreting the boot
232           script.
233
234         -instr (emulator flag):
235           Selects an instrumented Erlang runtime system (virtual machine)  to
236           run, instead of the ordinary one. When running an instrumented run‐
237           time system, some resource usage data can be obtained and  analyzed
238           using  the instrument module. Functionally, it behaves exactly like
239           an ordinary Erlang runtime system.
240
241         -loader Loader:
242           Specifies the method used by erl_prim_loader to load Erlang modules
243           into  the  system;  see  erl_prim_loader(3). Two Loader methods are
244           supported:
245
246           * efile, which means use the local file system,  this  is  the  de‐
247             fault.
248
249           * inet, which means use a boot server on another machine. The flags
250             -id, -hosts and -setcookie must also be specified.
251
252           If Loader is something else, the user-supplied Loader port  program
253           is started.
254
255         -make:
256           Makes  the  Erlang  runtime system invoke make:all() in the current
257           working directory and then terminate; see make(3).  Implies  -noin‐
258           put.
259
260         -man Module:
261           Displays  the  manual  page for the Erlang module Module. Only sup‐
262           ported on Unix.
263
264         -mode interactive | embedded:
265           Modules are auto loaded when they are first referenced if the  run‐
266           time  system runs in interactive mode, which is the default. In em‐
267           bedded mode modules are not auto loaded. The latter is  recommended
268           when  the  boot script preloads all modules, as conventionally hap‐
269           pens in OTP releases. See code(3).
270
271         -name Name:
272           Makes the Erlang runtime system into a distributed node. This  flag
273           invokes all network servers necessary for a node to become distrib‐
274           uted; see net_kernel(3). It is also ensured that epmd runs  on  the
275           current   host  before  Erlang  is  started;  see  epmd(1).and  the
276           -start_epmd option.
277
278           The node name will be Name@Host, where Host is the fully  qualified
279           host name of the current host. For short names, use flag -sname in‐
280           stead.
281
282           If Name is set to undefined the node will be started in  a  special
283           mode optimized to be the temporary client of another node. When en‐
284           abled the node will request a dynamic node name from the first node
285           it  connects  to.  In  addition these distribution settings will be
286           set:
287
288         -dist_listen false -hidden -dist_auto_connect never
289
290           Because -dist_auto_connect is set to never, the system will have to
291           manually  call net_kernel:connect_node/1 in order to start the dis‐
292           tribution. If the distribution channel is closed, when a node  uses
293           a  dynamic node name, the node will stop the distribution and a new
294           call to net_kernel:connect_node/1 has to be  made.  Note  that  the
295           node name may change if the distribution is dropped and then set up
296           again.
297
298     Note:
299         The dynamic node name feature is supported from OTP 23. Both the tem‐
300         porary  client  node and the first connected peer node (supplying the
301         dynamic node name) must be at least OTP 23 for it to work.
302
303
304     Warning:
305         Starting a  distributed  node  without  also  specifying  -proto_dist
306         inet_tls  will  expose the node to attacks that may give the attacker
307         complete access to the node and in extension the cluster. When  using
308         un-secure distributed nodes, make sure that the network is configured
309         to keep potential attackers out.
310
311
312         -noinput:
313           Ensures that the Erlang runtime system never tries to read any  in‐
314           put. Implies -noshell.
315
316         -noshell:
317           Starts  an  Erlang runtime system with no shell. This flag makes it
318           possible to have the Erlang runtime system as a component in a  se‐
319           ries of Unix pipes.
320
321         -nostick:
322           Disables  the  sticky directory facility of the Erlang code server;
323           see code(3).
324
325         -oldshell:
326           Invokes the old Erlang shell from Erlang/OTP 3.3. The old shell can
327           still be used.
328
329         -pa Dir1 Dir2 ...:
330           Adds  the  specified directories to the beginning of the code path,
331           similar to code:add_pathsa/1. Note that the order of the given  di‐
332           rectories will be reversed in the resulting path.
333
334           As  an  alternative  to  -pa,  if  several  directories  are  to be
335           prepended to the code path and the directories have a common parent
336           directory,  that  parent  directory can be specified in environment
337           variable ERL_LIBS; see code(3).
338
339         -pz Dir1 Dir2 ...:
340           Adds the specified directories to the end of the code path, similar
341           to code:add_pathsz/1; see code(3).
342
343         -path Dir1 Dir2 ...:
344           Replaces the path specified in the boot script; see script(4).
345
346         -proto_dist Proto:
347
348
349           Specifies a protocol for Erlang distribution:
350
351           inet_tcp:
352             TCP over IPv4 (the default)
353
354           inet_tls:
355             Distribution  over TLS/SSL, See the  Using SSL for Erlang Distri‐
356             bution User's Guide for details on how to setup a secure distrib‐
357             uted node.
358
359           inet6_tcp:
360             TCP over IPv6
361
362           For example, to start up IPv6 distributed nodes:
363
364         % erl -name test@ipv6node.example.com -proto_dist inet6_tcp
365
366         -remsh Node:
367           Starts Erlang with a remote shell connected to Node.
368
369           If  no  -name  or  -sname  is  given the node will be started using
370           -sname undefined. If Node does not contain a hostname, one is auto‐
371           matically taken from -name or -sname
372
373     Note:
374         Before  OTP-23  the user needed to supply a valid -sname or -name for
375         -remsh to work. This is still the case if the target node is not run‐
376         ning OTP-23 or later.
377
378
379         -rsh Program:
380           Specifies  an alternative to ssh for starting a slave node on a re‐
381           mote host; see slave(3).
382
383         -run Mod [Func [Arg1, Arg2, ...]] (init flag):
384           Makes init call the specified function. Func defaults to start.  If
385           no  arguments  are provided, the function is assumed to be of arity
386           0. Otherwise it is assumed to  be  of  arity  1,  taking  the  list
387           [Arg1,Arg2,...]  as  argument. All arguments are passed as strings.
388           See init(3).
389
390         -s Mod [Func [Arg1, Arg2, ...]] (init flag):
391           Makes init call the specified function. Func defaults to start.  If
392           no  arguments  are provided, the function is assumed to be of arity
393           0. Otherwise it is assumed to  be  of  arity  1,  taking  the  list
394           [Arg1,Arg2,...] as argument. All arguments are passed as atoms. See
395           init(3).
396
397         -setcookie Cookie:
398           Sets  the  magic  cookie  of  the   node   to   Cookie;   see   er‐
399           lang:set_cookie/2.
400
401         -shutdown_time Time:
402           Specifies  how  long time (in milliseconds) the init process is al‐
403           lowed to spend shutting down the system. If Time milliseconds  have
404           elapsed,  all  processes still existing are killed. Defaults to in‐
405           finity.
406
407         -sname Name:
408           Makes the Erlang runtime system into a distributed node, similar to
409           -name, but the host name portion of the node name Name@Host will be
410           the short name, not fully qualified.
411
412           This is sometimes the only way to run distributed Erlang if the Do‐
413           main  Name  System (DNS) is not running. No communication can exist
414           between nodes running with flag -sname and those running with  flag
415           -name, as node names must be unique in distributed Erlang systems.
416
417     Warning:
418         Starting  a  distributed  node  without  also  specifying -proto_dist
419         inet_tls will expose the node to attacks that may give  the  attacker
420         complete  access to the node and in extension the cluster. When using
421         un-secure distributed nodes, make sure that the network is configured
422         to keep potential attackers out.
423
424
425         -start_epmd true | false:
426           Specifies  whether  Erlang should start epmd on startup. By default
427           this is true, but if you prefer to start epmd manually, set this to
428           false.
429
430           This  only applies if Erlang is started as a distributed node, i.e.
431           if -name or -sname is specified. Otherwise,  epmd  is  not  started
432           even if -start_epmd true is given.
433
434           Note that a distributed node will fail to start if epmd is not run‐
435           ning.
436
437         -version (emulator flag):
438           Makes the emulator print its version number. The same as erl +V.
439

EMULATOR FLAGS

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

ENVIRONMENT VARIABLES

1342         ERL_CRASH_DUMP:
1343           If  the  emulator  needs  to  write a crash dump, the value of this
1344           variable is the filename of the crash dump file. If the variable is
1345           not  set,  the name of the crash dump file is erl_crash.dump in the
1346           current directory.
1347
1348         ERL_CRASH_DUMP_NICE:
1349           Unix systems: If the emulator needs to write a crash dump, it  uses
1350           the  value  of this variable to set the nice value for the process,
1351           thus lowering its priority. Valid range is 1-39 (higher values  are
1352           replaced  with  39).  The  highest value, 39, gives the process the
1353           lowest priority.
1354
1355         ERL_CRASH_DUMP_SECONDS:
1356           Unix systems: This variable gives the number of  seconds  that  the
1357           emulator  is  allowed to spend writing a crash dump. When the given
1358           number of seconds have elapsed, the emulator is terminated.
1359
1360           ERL_CRASH_DUMP_SECONDS=0:
1361             If the variable is set to 0 seconds, the runtime system does  not
1362             even  attempt  to  write the crash dump file. It only terminates.
1363             This is the default  if  option  -heart  is  passed  to  erl  and
1364             ERL_CRASH_DUMP_SECONDS is not set.
1365
1366           ERL_CRASH_DUMP_SECONDS=S:
1367             If  the variable is set to a positive value S, wait for S seconds
1368             to complete the crash dump file and then terminates  the  runtime
1369             system with a SIGALRM signal.
1370
1371           ERL_CRASH_DUMP_SECONDS=-1:
1372             A  negative value causes the termination of the runtime system to
1373             wait indefinitely until the crash dump file  has  been  completly
1374             written.  This  is  the default if option -heart is not passed to
1375             erl and ERL_CRASH_DUMP_SECONDS is not set.
1376
1377           See also heart(3).
1378
1379         ERL_CRASH_DUMP_BYTES:
1380           This variable sets the maximum size of a crash dump file in  bytes.
1381           The  crash dump will be truncated if this limit is exceeded. If the
1382           variable is not set, no size limit is enforced by default.  If  the
1383           variable  is  set to 0, the runtime system does not even attempt to
1384           write a crash dump file.
1385
1386           Introduced in ERTS 8.1.2 (Erlang/OTP 19.2).
1387
1388         ERL_AFLAGS:
1389           The content of this variable is added to the beginning of the  com‐
1390           mand line for erl.
1391
1392           Flag  -extra is treated in a special way. Its scope ends at the end
1393           of the environment variable content. Arguments following an  -extra
1394           flag  are  moved  on the command line into section -extra, that is,
1395           the end of the command line following an -extra flag.
1396
1397         ERL_ZFLAGS and ERL_FLAGS:
1398           The content of these variables are added to the end of the  command
1399           line for erl.
1400
1401           Flag  -extra is treated in a special way. Its scope ends at the end
1402           of the environment variable content. Arguments following an  -extra
1403           flag  are  moved  on the command line into section -extra, that is,
1404           the end of the command line following an -extra flag.
1405
1406         ERL_LIBS:
1407           Contains a list of additional library  directories  that  the  code
1408           server  searches  for  applications  and adds to the code path; see
1409           code(3).
1410
1411         ERL_EPMD_ADDRESS:
1412           Can be set to a comma-separated list of IP addresses, in which case
1413           the  epmd  daemon  listens only on the specified address(es) and on
1414           the loopback address (which is implicitly added to the list  if  it
1415           has not been specified).
1416
1417         ERL_EPMD_PORT:
1418           Can  contain  the  port number to use when communicating with epmd.
1419           The default port works fine in most cases. A different port can  be
1420           specified to allow nodes of independent clusters to co-exist on the
1421           same host. All nodes in a cluster must use the same epmd port  num‐
1422           ber.
1423

SIGNALS

1425       On  Unix  systems,  the Erlang runtime will interpret two types of sig‐
1426       nals.
1427
1428         SIGUSR1:
1429           A SIGUSR1 signal forces a crash dump.
1430
1431         SIGTERM:
1432           A SIGTERM will produce a stop message to the init process. This  is
1433           equivalent to a init:stop/0 call.
1434
1435           Introduced in ERTS 8.3 (Erlang/OTP 19.3)
1436
1437       The signal SIGUSR2 is reserved for internal usage. No other signals are
1438       handled.
1439

CONFIGURATION

1441       The standard Erlang/OTP system can be reconfigured to  change  the  de‐
1442       fault behavior on startup.
1443
1444         The .erlang startup file:
1445           When  Erlang/OTP  is  started, the system searches for a file named
1446           .erlang in the user's home directory.
1447
1448           If an .erlang file is found, it is assumed to contain valid  Erlang
1449           expressions.  These expressions are evaluated as if they were input
1450           to the shell.
1451
1452           A typical .erlang file contains a set of search paths, for example:
1453
1454         io:format("executing user profile in HOME/.erlang\n",[]).
1455         code:add_path("/home/calvin/test/ebin").
1456         code:add_path("/home/hobbes/bigappl-1.2/ebin").
1457         io:format(".erlang rc finished\n",[]).
1458
1459         user_default and shell_default:
1460           Functions in the shell that are not prefixed by a module  name  are
1461           assumed to be functional objects (funs), built-in functions (BIFs),
1462           or belong to the module user_default or shell_default.
1463
1464           To include private shell commands, define them in a module user_de‐
1465           fault  and add the following argument as the first line in the .er‐
1466           lang file:
1467
1468         code:load_abs("..../user_default").
1469
1470         erl:
1471           If the contents of .erlang are changed and  a  private  version  of
1472           user_default  is defined, the Erlang/OTP environment can be custom‐
1473           ized. More powerful changes can be made by  supplying  command-line
1474           arguments  in  the  startup  script  erl. For more information, see
1475           init(3).
1476

SEE ALSO

1478       epmd(1), erl_prim_loader(3),  erts_alloc(3),  init(3),  application(3),
1479       auth(3), code(3), erl_boot_server(3), heart(3), net_kernel(3), make(3)
1480
1481
1482
1483Ericsson AB                      erts 11.2.2.2                          erl(1)
Impressum