Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
erl(1)				 User Commands				erl(1)

NAME
       erl - The Erlang	emulator.

DESCRIPTION
       The erl program starts an Erlang	runtime	system.	The exact details (for
       example,	whether	erl is a script	or a program and which other  programs
       it calls) are system-dependent.

       Windows users probably want to use the werl program instead, which runs
       in its own window with scrollbars and  supports	command-line  editing.
       The  erl	 program on Windows provides no	line editing in	its shell, and
       on Windows 95 there is no way to	scroll back to text that has  scrolled
       off  the	screen.	The erl	program	must be	used, however, in pipelines or
       if you want to redirect standard	input or output.

   Note:
       As from ERTS 5.9	(Erlang/OTP R15B) the runtime system does  by  default
       not  bind  schedulers  to logical processors. For more information, see
       system flag +sbt.

EXPORTS
       erl <arguments>

	      Starts an	Erlang runtime system.

	      The arguments can	be divided into	 emulator  flags,  flags,  and
	      plain arguments:

		* Any  argument	starting with character	+ is interpreted as an
		  emulator flag.

		  As indicated by the name, emulator flags control the	behav-
		  ior of the emulator.

		* Any  argument	 starting  with	character - (hyphen) is	inter-
		  preted as a flag, which is to	be passed to the  Erlang  part
		  of  the runtime system, more specifically to the init	system
		  process, see init(3).

		  The init process itself interprets some of these flags,  the
		  init	flags.	It  also  stores any remaining flags, the user
		  flags. The latter can	be retrieved by	calling	init:get_argu-
		  ment/1.

		  A  small  number  of "-" flags exist,	which now actually are
		  emulator flags, see the description below.

		* Plain	arguments are not interpreted in  any  way.  They  are
		  also	stored	by  the	 init  process and can be retrieved by
		  calling init:get_plain_arguments/0. Plain arguments can  oc-
		  cur  before  the  first  flag, or after a -- flag. Also, the
		  -extra flag causes everything	that follows to	 become	 plain
		  arguments.

	      Examples:

	      %	erl +W w -sname	arnie +R 9 -s my_init -extra +bertie
	      (arnie@host)1> init:get_argument(sname).
	      {ok,[["arnie"]]}
	      (arnie@host)2> init:get_plain_arguments().
	      ["+bertie"]

	      Here  +W	w  and	+R 9 are emulator flags. -s my_init is an init
	      flag, interpreted	by init. -sname	arnie is a user	 flag,	stored
	      by init. It is read by Kernel and	causes the Erlang runtime sys-
	      tem to become  distributed.  Finally,  everything	 after	-extra
	      (that is,	+bertie) is considered as plain	arguments.

	      %	erl -myflag 1
	      1> init:get_argument(myflag).
	      {ok,[["1"]]}
	      2> init:get_plain_arguments().
	      []

	      Here the user flag -myflag 1 is passed to	and stored by the init
	      process. It is a user-defined  flag,  presumably	used  by  some
	      user-defined application.

FLAGS
       In the following	list, init flags are marked "(init flag)". Unless oth-
       erwise specified, all other flags are user flags, for which the	values
       can  be	retrieved by calling init:get_argument/1. Notice that the list
       of user flags is	not exhaustive,	there can be more application-specific
       flags that instead are described	in the corresponding application docu-
       mentation.

	 -- (init flag):
	   Everything following	-- up to the next flag	(-flag	or  +flag)  is
	   considered	plain	arguments   and	  can	be   retrieved	 using
	   init:get_plain_arguments/0.

	 -Application Par Val:
	   Sets	the application	configuration parameter	Par to the  value  Val
	   for the application Application; see	app(4) and application(3).

	 -args_file FileName:
	   Command-line	 arguments  are	read from the file FileName. The argu-
	   ments read from the file replace flag '-args_file FileName' on  the
	   resulting command line.

	   The	file  FileName is to be	a plain	text file and can contain com-
	   ments and command-line arguments. A comment begins with a # charac-
	   ter	and  continues until the next end of line character. Backslash
	   (\\)	is used	as quoting character. All command-line	arguments  ac-
	   cepted  by erl are allowed, also flag -args_file FileName. Be care-
	   ful not to cause circular  dependencies  between  files  containing
	   flag	-args_file, though.

	   The	flag  -extra  is treated in special way. Its scope ends	at the
	   end of the file. Arguments following	an -extra flag	are  moved  on
	   the	command	 line into the -extra section, that is,	the end	of the
	   command line	following after	an -extra flag.

	 -async_shell_start:
	   The initial Erlang shell does not read user input until the	system
	   boot	 procedure has been completed (Erlang/OTP 5.4 and later). This
	   flag	disables the start synchronization feature and lets the	 shell
	   start in parallel with the rest of the system.

	 -boot File:
	   Specifies  the  name	 of the	boot file, File.boot, which is used to
	   start the system; see init(3). Unless  File	contains  an  absolute
	   path,  the  system  searches	 for  File.boot	 in  the  current  and
	   $ROOT/bin directories.

	   Defaults to $ROOT/bin/start.boot.

	 -boot_var Var Dir:
	   If the boot script contains a path variable Var other  than	$ROOT,
	   this	 variable  is  expanded	to Dir.	Used when applications are in-
	   stalled   in	  another   directory	than   $ROOT/lib;   see	  sys-
	   tools:make_script/1,2 in SASL.

	 -code_path_cache:
	   Enables the code path cache of the code server; see code(3).

	 -compile Mod1 Mod2 ...:
	   Compiles  the  specified modules and	then terminates	(with non-zero
	   exit	code if	the compilation	of some	file did not succeed). Implies
	   -noinput.

	   Not recommended; use	erlc instead.

	 -config Config:
	   Specifies the name of a configuration file, Config.config, which is
	   used	to configure applications; see app(4) and application(3).

	 -connect_all false:
	   If this flag	is present, global does	not maintain a fully connected
	   network of distributed Erlang nodes,	and then global	name registra-
	   tion	cannot be used;	see global(3).

	 -cookie Cookie:
	   Obsolete flag without any effect and	common misspelling  for	 -set-
	   cookie. Use -setcookie instead.

	 -detached:
	   Starts  the Erlang runtime system detached from the system console.
	   Useful for  running	daemons	 and  backgrounds  processes.  Implies
	   -noinput.

	 -emu_args:
	   Useful for debugging. Prints	the arguments sent to the emulator.

	 -emu_type Type:
	   Start  an  emulator	of a different type. For example, to start the
	   lock-counter	emualator, use -emu_type lcnt. (The emulator must  al-
	   ready  be  built. Use the configure option --enable-lock-counter to
	   build the lock-counter emulator.)

	 -env Variable Value:
	   Sets	the host OS environment	variable Variable to the  value	 Value
	   for the Erlang runtime system. Example:

	 % erl -env DISPLAY gin:0

	   In  this example, an	Erlang runtime system is started with environ-
	   ment	variable DISPLAY set to	gin:0.

	 -epmd_module Module (init flag):
	   Configures the module responsible to	communicate to epmd.  Defaults
	   to erl_epmd.

	 -eval Expr (init flag):
	   Makes init evaluate the expression Expr; see	init(3).

	 -extra	(init flag):
	   Everything  following  -extra is considered plain arguments and can
	   be retrieved	using init:get_plain_arguments/0.

	 -heart:
	   Starts heartbeat monitoring	of  the	 Erlang	 runtime  system;  see
	   heart(3).

	 -hidden:
	   Starts  the Erlang runtime system as	a hidden node, if it is	run as
	   a distributed node. Hidden nodes always  establish  hidden  connec-
	   tions to all	other nodes except for nodes in	the same global	group.
	   Hidden connections are not published	on any of the connected	nodes,
	   that	 is,  none  of the connected nodes are part of the result from
	   nodes/0  on	the  other  node.  See	also  hidden  global   groups;
	   global_group(3).

	 -hosts	Hosts:
	   Specifies  the  IP  addresses  for  the  hosts on which Erlang boot
	   servers are running,	see erl_boot_server(3).	This flag is mandatory
	   if flag -loader inet	is present.

	   The IP addresses must be specified in the standard form (four deci-
	   mal numbers separated by  periods,  for  example,  "150.236.20.74".
	   Hosts names are not acceptable, but a broadcast address (preferably
	   limited to the local	network) is.

	 -id Id:
	   Specifies the identity of the Erlang	runtime	system.	If it  is  run
	   as  a  distributed  node, Id	must be	identical to the name supplied
	   together with flag -sname or	-name.

	 -init_debug:
	   Makes init write some debug information while interpreting the boot
	   script.

	 -instr	(emulator flag):
	   Selects  an instrumented Erlang runtime system (virtual machine) to
	   run,	instead	of the ordinary	one. When running an instrumented run-
	   time	 system, some resource usage data can be obtained and analyzed
	   using the instrument	module.	Functionally, it behaves exactly  like
	   an ordinary Erlang runtime system.

	 -loader Loader:
	   Specifies the method	used by	erl_prim_loader	to load	Erlang modules
	   into	the system; see	erl_prim_loader(3).  Two  Loader  methods  are
	   supported:

	   * efile,  which  means  use	the local file system, this is the de-
	     fault.

	   * inet, which means use a boot server on another machine. The flags
	     -id, -hosts and -setcookie	must also be specified.

	   If  Loader is something else, the user-supplied Loader port program
	   is started.

	 -make:
	   Makes the Erlang runtime system invoke make:all()  in  the  current
	   working  directory  and then	terminate; see make(3).	Implies	-noin-
	   put.

	 -man Module:
	   Displays the	manual page for	the Erlang module  Module.  Only  sup-
	   ported on Unix.

	 -mode interactive | embedded:
	   Modules  are	auto loaded when they are first	referenced if the run-
	   time	system runs in interactive mode, which is the default. In  em-
	   bedded  mode	modules	are not	auto loaded. The latter	is recommended
	   when	the boot script	preloads all modules, as  conventionally  hap-
	   pens	in OTP releases. See code(3).

	 -name Name:
	   Makes  the Erlang runtime system into a distributed node. This flag
	   invokes all network servers necessary for a node to become distrib-
	   uted;  see  net_kernel(3). It is also ensured that epmd runs	on the
	   current  host  before  Erlang  is  started;	see  epmd(1).and   the
	   -start_epmd option.

	   The	node name will be Name@Host, where Host	is the fully qualified
	   host	name of	the current host. For short names, use flag -sname in-
	   stead.

     Warning:
	 Starting  a  distributed  node	 without  also	specifying -proto_dist
	 inet_tls will expose the node to attacks that may give	 the  attacker
	 complete  access to the node and in extension the cluster. When using
	 un-secure distributed nodes, make sure	that the network is configured
	 to keep potential attackers out.

	 -noinput:
	   Ensures  that the Erlang runtime system never tries to read any in-
	   put.	Implies	-noshell.

	 -noshell:
	   Starts an Erlang runtime system with	no shell. This flag  makes  it
	   possible  to	have the Erlang	runtime	system as a component in a se-
	   ries	of Unix	pipes.

	 -nostick:
	   Disables the	sticky directory facility of the Erlang	 code  server;
	   see code(3).

	 -oldshell:
	   Invokes the old Erlang shell	from Erlang/OTP	3.3. The old shell can
	   still be used.

	 -pa Dir1 Dir2 ...:
	   Adds	the specified directories to the beginning of the  code	 path,
	   similar  to code:add_pathsa/1. Note that the	order of the given di-
	   rectories will be reversed in the resulting path.

	   As an  alternative  to  -pa,	 if  several  directories  are	to  be
	   prepended to	the code path and the directories have a common	parent
	   directory, that parent directory can	be  specified  in  environment
	   variable ERL_LIBS; see code(3).

	 -pz Dir1 Dir2 ...:
	   Adds	the specified directories to the end of	the code path, similar
	   to code:add_pathsz/1; see code(3).

	 -path Dir1 Dir2 ...:
	   Replaces the	path specified in the boot script; see script(4).

	 -proto_dist Proto:

	   Specifies a protocol	for Erlang distribution:

	   inet_tcp:
	     TCP over IPv4 (the	default)

	   inet_tls:
	     Distribution over TLS/SSL,	See the	 Using SSL for Erlang  Distri-
	     bution User's Guide for details on	how to setup a secure distrib-
	     uted node.

	   inet6_tcp:
	     TCP over IPv6

	   For example,	to start up IPv6 distributed nodes:

	 % erl -name test@ipv6node.example.com -proto_dist inet6_tcp

	 -remsh	Node:
	   Starts Erlang with a	remote shell connected to Node.

	 -rsh Program:
	   Specifies an	alternative to rsh for starting	a slave	node on	a  re-
	   mote	host; see slave(3).

	 -run Mod [Func	[Arg1, Arg2, ...]] (init flag):
	   Makes  init call the	specified function. Func defaults to start. If
	   no arguments	are provided, the function is assumed to be  of	 arity
	   0.  Otherwise  it  is  assumed  to  be  of arity 1, taking the list
	   [Arg1,Arg2,...] as argument.	All arguments are passed  as  strings.
	   See init(3).

	 -s Mod	[Func [Arg1, Arg2, ...]] (init flag):
	   Makes  init call the	specified function. Func defaults to start. If
	   no arguments	are provided, the function is assumed to be  of	 arity
	   0.  Otherwise  it  is  assumed  to  be  of arity 1, taking the list
	   [Arg1,Arg2,...] as argument.	All arguments are passed as atoms. See
	   init(3).

	 -setcookie Cookie:
	   Sets	  the	magic	cookie	 of   the  node	 to  Cookie;  see  er-
	   lang:set_cookie/2.

	 -shutdown_time	Time:
	   Specifies how long time (in milliseconds) the init process  is  al-
	   lowed  to spend shutting down the system. If	Time milliseconds have
	   elapsed, all	processes still	existing are killed. Defaults  to  in-
	   finity.

	 -sname	Name:
	   Makes the Erlang runtime system into	a distributed node, similar to
	   -name, but the host name portion of the node	name Name@Host will be
	   the short name, not fully qualified.

	   This	is sometimes the only way to run distributed Erlang if the Do-
	   main	Name System (DNS) is not running. No communication  can	 exist
	   between  nodes running with flag -sname and those running with flag
	   -name, as node names	must be	unique in distributed Erlang systems.

     Warning:
	 Starting a  distributed  node	without	 also  specifying  -proto_dist
	 inet_tls  will	 expose	the node to attacks that may give the attacker
	 complete access to the	node and in extension the cluster. When	 using
	 un-secure distributed nodes, make sure	that the network is configured
	 to keep potential attackers out.

	 -start_epmd true | false:
	   Specifies whether Erlang should start epmd on startup.  By  default
	   this	is true, but if	you prefer to start epmd manually, set this to
	   false.

	   This	only applies if	Erlang is started as a distributed node,  i.e.
	   if  -name  or  -sname  is specified.	Otherwise, epmd	is not started
	   even	if -start_epmd true is given.

	   Note	that a distributed node	will fail to start if epmd is not run-
	   ning.

	 -version (emulator flag):
	   Makes the emulator print its	version	number.	The same as erl	+V.

EMULATOR FLAGS
       erl  invokes  the code for the Erlang emulator (virtual machine), which
       supports	the following flags:

	 +a size:
	   Suggested stack size, in kilowords, for threads in the async	thread
	   pool. Valid range is	16-8192	kilowords. The default suggested stack
	   size	is 16 kilowords, that is, 64 kilobyte on 32-bit	architectures.
	   This	small default size has been chosen because the number of async
	   threads can be large. The default size is enough for	drivers	deliv-
	   ered	 with  Erlang/OTP, but might not be large enough for other dy-
	   namically linked-in drivers that use	the driver_async() functional-
	   ity.	 Notice	that the value passed is only a	suggestion, and	it can
	   even	be ignored on some platforms.

	 +A size:
	   Sets	the number of threads in async thread  pool.  Valid  range  is
	   0-1024. Defaults to 1.

	 +B [c | d | i]:
	   Option c makes Ctrl-C interrupt the current shell instead of	invok-
	   ing the emulator break handler. Option d  (same  as	specifying  +B
	   without an extra option) disables the break handler.	Option i makes
	   the emulator	ignore any break signal.

	   If option c is used with oldshell on	Unix, Ctrl-C will restart  the
	   shell process rather	than interrupt it.

	   Notice  that	on Windows, this flag is only applicable for werl, not
	   erl (oldshell). Notice also that  Ctrl-Break	 is  used  instead  of
	   Ctrl-C on Windows.

	 +c true | false:
	   Enables or disables time correction:

	   true:
	     Enables  time  correction.	This is	the default if time correction
	     is	supported on the specific platform.

	   false:
	     Disables time correction.

	   For backward	compatibility, the boolean value can be	omitted.  This
	   is interpreted as +c	false.

	 +C no_time_warp | single_time_warp | multi_time_warp:
	   Sets	time warp mode:

	   no_time_warp:
	      No time warp mode	(the default)

	   single_time_warp:
	      Single time warp mode

	   multi_time_warp:
	      Multi-time warp mode

	 +d:
	   If  the emulator detects an internal	error (or runs out of memory),
	   it, by default, generates both a crash dump and a  core  dump.  The
	   core	 dump  is,  however, not very useful as	the content of process
	   heaps is destroyed by the crash dump	generation.

	   Option +d instructs the emulator to produce only a core dump	and no
	   crash dump if an internal error is detected.

	   Calling erlang:halt/1 with a	string argument	still produces a crash
	   dump. On Unix systems, sending an emulator process a	SIGUSR1	signal
	   also	forces a crash dump.

	 +e Number:
	   Sets	 the maximum number of ETS tables. This	limit is partially ob-
	   solete.

	 +ec:
	   Forces option compressed on all ETS tables. Only intended for  test
	   and evaluation.

	 +fnl:
	   The virtual machine works with filenames as if they are encoded us-
	   ing the ISO Latin-1 encoding, disallowing Unicode  characters  with
	   code	points > 255.

	   For	more  information about	Unicode	filenames, see section Unicode
	   Filenames in	the STDLIB User's Guide. Notice	that this  value  also
	   applies  to	command-line parameters	and environment	variables (see
	   section  Unicode in Environment and Parameters in the STDLIB	User's
	   Guide).

	 +fnu[{w|i|e}]:
	   The virtual machine works with filenames as if they are encoded us-
	   ing UTF-8 (or some other system-specific Unicode encoding). This is
	   the	default	 on  operating	systems	that enforce Unicode encoding,
	   that	is, Windows and	MacOS X.

	   The +fnu switch can be followed by  w,  i,  or  e  to  control  how
	   wrongly encoded filenames are to be reported:

	   * w	means  that  a	warning	is sent	to the error_logger whenever a
	     wrongly encoded filename is "skipped" in directory	listings. This
	     is	the default.

	   * i	means  that  those  wrongly encoded filenames are silently ig-
	     nored.

	   * e means that the API function returns an error whenever a wrongly
	     encoded filename (or directory name) is encountered.

	   Notice  that	 file:read_link/1  always returns an error if the link
	   points to an	invalid	filename.

	   For more information	about Unicode filenames, see  section  Unicode
	   Filenames  in  the STDLIB User's Guide. Notice that this value also
	   applies to command-line parameters and environment  variables  (see
	   section  Unicode in Environment and Parameters in the STDLIB	User's
	   Guide).

	 +fna[{w|i|e}]:
	   Selection between +fnl and +fnu is done based on the	current	locale
	   settings  in	 the OS. This means that if you	have set your terminal
	   for UTF-8 encoding, the filesystem is expected to use the same  en-
	   coding for filenames. This is default on all	operating systems, ex-
	   cept	MacOS X	and Windows.

	   The +fna switch can be followed by w, i, or e. This has  effect  if
	   the	locale settings	cause the behavior of +fnu to be selected; see
	   the description of +fnu above. If the locale	settings cause the be-
	   havior of +fnl to be	selected, then w, i, or	e have no effect.

	   For	more  information about	Unicode	filenames, see section Unicode
	   Filenames in	the STDLIB User's Guide. Notice	that this  value  also
	   applies  to	command-line parameters	and environment	variables (see
	   section  Unicode in Environment and Parameters in the STDLIB	User's
	   Guide).

	 +hms Size:
	   Sets	the default heap size of processes to the size Size.

	 +hmbs Size:
	   Sets	 the default binary virtual heap size of processes to the size
	   Size.

	 +hmax Size:
	   Sets	the default maximum heap size of processes to the  size	 Size.
	   Defaults  to	 0, which means	that no	maximum	heap size is used. For
	   more	information, see process_flag(max_heap_size, MaxHeapSize).

	 +hmaxel true|false:
	   Sets	whether	to send	an error logger	message	or not	for  processes
	   reaching the	maximum	heap size. Defaults to true. For more informa-
	   tion, see process_flag(max_heap_size, MaxHeapSize).

	 +hmaxk	true|false:
	   Sets	whether	to kill	processes reaching the maximum	heap  size  or
	   not.	   Default    to    true.    For    more    information,   see
	   process_flag(max_heap_size, MaxHeapSize).

	 +hpds Size:
	   Sets	the initial process dictionary size of processes to  the  size
	   Size.

	 +hmqd off_heap|on_heap:
	   Sets	 the  default  value  for process flag message_queue_data. De-
	   faults to on_heap. If +hmqd is not passed, on_heap will be the  de-
	   fault.  For	more information, see process_flag(message_queue_data,
	   MQD).

	 +IOp PollSets:
	   Sets	the number of IO pollsets to use when polling  for  I/O.  This
	   option is only used on platforms that support concurrent updates of
	   a pollset, otherwise	the same number	of pollsets  are  used	as  IO
	   poll	threads. The default is	1.

	 +IOt PollThreads:
	   Sets	the number of IO poll threads to use when polling for I/O. The
	   maximum number of poll threads allowed is 1024. The default is 1.

	   A good way to check if more IO poll threads are needed  is  to  use
	   microstate  accounting  and see what	the load of the	IO poll	thread
	   is. If it is	high it	could be a good	idea to	add more threads.

	 +IOPp PollSetsPercentage:
	   Similar to +IOp but uses  percentages  to  set  the	number	of  IO
	   pollsets to create, based on	the number of poll threads configured.
	   If both +IOPp and +IOp are used, +IOPp is ignored.

	 +IOPt PollThreadsPercentage:
	   Similar to +IOt but uses percentages	to set the number of  IO  poll
	   threads to create, based on the number of schedulers	configured. If
	   both	+IOPt and +IOt are used, +IOPt is ignored.

	 +l:
	   Enables autoload  tracing,  displaying  information	while  loading
	   code.

	 +L:
	   Prevents  loading  information about	source filenames and line num-
	   bers. This saves some memory, but exceptions	do not contain	infor-
	   mation about	the filenames and line numbers.

	 +MFlag	Value:
	   Memory allocator-specific flags. For	more information, see erts_al-
	   loc(3).

	 +pc Range:
	   Sets	the range of characters	that the system	considers printable in
	   heuristic  detection	 of strings. This typically affects the	shell,
	   debugger, and io:format functions (when ~tp is used in  the	format
	   string).

	   Two values are supported for	Range:

	   latin1:
	     The default. Only characters in the ISO Latin-1 range can be con-
	     sidered printable.	This means that	a character with a code	 point
	     >	255  is	 never	considered printable and that lists containing
	     such characters are displayed as lists of	integers  rather  than
	     text strings by tools.

	   unicode:
	     All  printable Unicode characters are considered when determining
	     if	a list of integers is to be displayed in string	 syntax.  This
	     can  give	unexpected results if, for example, your font does not
	     cover all Unicode characters.

	   See also io:printable_range/0 in STDLIB.

	 +P Number:
	   Sets	the maximum number of simultaneously  existing	processes  for
	   this	 system	if a Number is passed as value.	Valid range for	Number
	   is [1024-134217727]

	   NOTE: The actual maximum chosen may be much larger than the	Number
	   passed. Currently the runtime system	often, but not always, chooses
	   a value that	is a power of 2. This might, however,  be  changed  in
	   the	future.	 The actual value chosen can be	checked	by calling er-
	   lang:system_info(process_limit).

	   The default value is	262144

	 +Q Number:
	   Sets	the maximum number of simultaneously existing ports  for  this
	   system  if  a  Number is passed as value. Valid range for Number is
	   [1024-134217727]

	   NOTE: The actual maximum chosen may be much larger than the	actual
	   Number  passed. Currently the runtime system	often, but not always,
	   chooses a value that	is a power  of	2.  This  might,  however,  be
	   changed  in	the  future. The actual	value chosen can be checked by
	   calling erlang:system_info(port_limit).

	   The default value used is normally 65536. However, if  the  runtime
	   system is able to determine maximum amount of file descriptors that
	   it is allowed to open and this value	is larger than 65536, the cho-
	   sen	value will increased to	a value	larger or equal	to the maximum
	   amount of file descriptors that can be opened.

	   On Windows the default value	is set to 8196 because the  normal  OS
	   limitations are set higher than most	machines can handle.

	 +R ReleaseNumber:
	   Sets	the compatibility mode.

	   The	distribution  mechanism	is not backward	compatible by default.
	   This	flag sets the emulator in compatibility	mode with  an  earlier
	   Erlang/OTP release ReleaseNumber. The release number	must be	in the
	   range _current release_-2.._current release_. This limits the  emu-
	   lator,  making  it possible for it to communicate with Erlang nodes
	   (as well as C- and Java nodes) running that earlier release.

     Note:
	 Ensure	that all nodes (Erlang-, C-, and Java nodes) of	a  distributed
	 Erlang	 system	is of the same Erlang/OTP release, or from two differ-
	 ent Erlang/OTP	releases X and Y, where	all Y nodes have compatibility
	 mode X.

	 +r:
	   Forces ETS memory block to be moved on realloc.

	 +rg ReaderGroupsLimit:
	   Limits  the	number of reader groups	used by	read/write locks opti-
	   mized for read operations in	the Erlang runtime system. By  default
	   the reader groups limit is 64.

	   When	 the  number of	schedulers is less than	or equal to the	reader
	   groups limit, each scheduler	has its	own  reader  group.  When  the
	   number of schedulers	is larger than the reader groups limit,	sched-
	   ulers share reader groups. Shared reader groups degrade  read  lock
	   and	read unlock performance	while many reader groups degrade write
	   lock	performance. So, the limit is a	tradeoff  between  performance
	   for	read  operations  and  performance  for	write operations. Each
	   reader group	consumes 64 byte in each read/write lock.

	   Notice that a runtime system	using shared  reader  groups  benefits
	   from	binding	schedulers to logical processors, as the reader	groups
	   are distributed better between schedulers.

	 +S Schedulers:SchedulerOnline:
	   Sets	the number  of	scheduler  threads  to	create	and  scheduler
	   threads  to set online. The maximum for both	values is 1024.	If the
	   Erlang runtime system is able to determine the  number  of  logical
	   processors  configured and logical processors available, Schedulers
	   defaults to logical processors configured, and SchedulersOnline de-
	   faults  to logical processors available; otherwise the default val-
	   ues are 1. Schedulers can be	omitted	if :SchedulerOnline is not and
	   conversely.	The number of schedulers online	can be changed at run-
	   time	 through  erlang:system_flag(schedulers_online,	 SchedulersOn-
	   line).

	   If  Schedulers  or SchedulersOnline is specified as a negative num-
	   ber,	the value is subtracted	from the  default  number  of  logical
	   processors  configured  or  logical	processors  available, respec-
	   tively.

	   Specifying value 0 for Schedulers or	 SchedulersOnline  resets  the
	   number  of  scheduler  threads or scheduler threads online, respec-
	   tively, to its default value.

	 +SP SchedulersPercentage:SchedulersOnlinePercentage:
	   Similar to +S but uses percentages to set the number	 of  scheduler
	   threads  to	create,	 based	on  logical processors configured, and
	   scheduler threads to	set online, based on logical processors	avail-
	   able. Specified values must be > 0. For example, +SP	50:25 sets the
	   number of scheduler threads to 50% of the logical  processors  con-
	   figured,  and  the number of	scheduler threads online to 25%	of the
	   logical processors available. SchedulersPercentage can  be  omitted
	   if :SchedulersOnlinePercentage is not and conversely. The number of
	   schedulers online can be changed  at	 runtime  through  erlang:sys-
	   tem_flag(schedulers_online, SchedulersOnline).

	   This	 option	 interacts  with +S settings. For example, on a	system
	   with	8 logical cores	configured and 8 logical cores available,  the
	   combination	of  the	options	+S 4:4 +SP 50:25 (in either order) re-
	   sults in 2 scheduler	threads	(50% of	4) and 1 scheduler thread  on-
	   line	(25% of	4).

	 +SDcpu	DirtyCPUSchedulers:DirtyCPUSchedulersOnline:
	   Sets	 the number of dirty CPU scheduler threads to create and dirty
	   CPU scheduler threads to set	online.	The maximum for	both values is
	   1024,  and each value is further limited by the settings for	normal
	   schedulers:

	   * The number	of dirty CPU scheduler threads created	cannot	exceed
	     the number	of normal scheduler threads created.

	   * The  number  of  dirty CPU	scheduler threads online cannot	exceed
	     the number	of normal scheduler threads online.

	   For details,	see the	+S and +SP. By default,	the  number  of	 dirty
	   CPU scheduler threads created equals	the number of normal scheduler
	   threads created, and	the number of dirty CPU	scheduler threads  on-
	   line	 equals	the number of normal scheduler threads online. DirtyC-
	   PUSchedulers	can be omitted if :DirtyCPUSchedulersOnline is not and
	   conversely.	The  number  of	 dirty	CPU  schedulers	 online	can be
	   changed  at	runtime	 through   erlang:system_flag(dirty_cpu_sched-
	   ulers_online, DirtyCPUSchedulersOnline).

	   The amount of dirty CPU schedulers is limited by the	amount of nor-
	   mal schedulers in order to limit the	effect on processes  executing
	   on  ordinary	 schedulers. If	the amount of dirty CPU	schedulers was
	   allowed to be unlimited, dirty CPU  bound  jobs  would  potentially
	   starve normal jobs.

	 +SDPcpu DirtyCPUSchedulersPercentage:DirtyCPUSchedulersOnlinePercent-
	 age:
	   Similar to +SDcpu but uses percentages to set the number  of	 dirty
	   CPU	scheduler threads to create and	the number of dirty CPU	sched-
	   uler	threads	to set online. Specified values	must be	> 0. For exam-
	   ple,	 +SDPcpu  50:25	sets the number	of dirty CPU scheduler threads
	   to 50% of the logical processors configured and the number of dirty
	   CPU	scheduler  threads  online  to	25%  of	the logical processors
	   available. DirtyCPUSchedulersPercentage can be omitted if  :DirtyC-
	   PUSchedulersOnlinePercentage	 is  not and conversely. The number of
	   dirty CPU schedulers	online can be changed at runtime  through  er-
	   lang:system_flag(dirty_cpu_schedulers_online, DirtyCPUSchedulersOn-
	   line).

	   This	option interacts with +SDcpu settings. For example, on a  sys-
	   tem	with 8 logical cores configured	and 8 logical cores available,
	   the combination of the options +SDcpu 4:4 +SDPcpu 50:25 (in	either
	   order)  results  in	2 dirty	CPU scheduler threads (50% of 4) and 1
	   dirty CPU scheduler thread online (25% of 4).

	 +SDio DirtyIOSchedulers:
	   Sets	the number of dirty I/O	scheduler  threads  to	create.	 Valid
	   range  is  0-1024.  By  default,  the number	of dirty I/O scheduler
	   threads created is 10, same as the default number of	threads	in the
	   async thread	pool.

	   The	amount	of dirty IO schedulers is not limited by the amount of
	   normal schedulers like the amount of	 dirty	CPU  schedulers.  This
	   since  only	I/O  bound  work  is  expected to execute on dirty I/O
	   schedulers. If the user should schedule CPU bound jobs on dirty I/O
	   schedulers,	these jobs might starve	ordinary jobs executing	on or-
	   dinary schedulers.

	 +sFlag	Value:
	   Scheduling specific flags.

	   +sbt	BindType:
	     Sets scheduler bind type.

	     Schedulers	can also be bound using	flag +stbt. The	 only  differ-
	     ence between these	two flags is how the following errors are han-
	     dled:

	     * Binding of schedulers is	not supported on  the  specific	 plat-
	       form.

	     * No  available CPU topology. That	is, the	runtime	system was not
	       able to detect the CPU topology automatically, and no  user-de-
	       fined CPU topology was set.

	     If	 any of	these errors occur when	+sbt has been passed, the run-
	     time system prints	an error message, and refuses to start.	If any
	     of	 these	errors	occur  when +stbt has been passed, the runtime
	     system silently ignores the error,	and  start  up	using  unbound
	     schedulers.

	     Valid BindTypes:

	     u:
	       unbound	- Schedulers are not bound to logical processors, that
	       is, the operating system	decides	where  the  scheduler  threads
	       execute,	and when to migrate them. This is the default.

	     ns:
	       no_spread  -  Schedulers	 with  close scheduler identifiers are
	       bound as	close as possible in hardware.

	     ts:
	       thread_spread - Thread refers to	hardware threads (such as  In-
	       tel's  hyper-threads).  Schedulers  with	 low scheduler identi-
	       fiers, are bound	to the first hardware  thread  of  each	 core,
	       then  schedulers	with higher scheduler identifiers are bound to
	       the second hardware thread of each core,and so on.

	     ps:
	       processor_spread	- Schedulers are  spread  like	thread_spread,
	       but also	over physical processor	chips.

	     s:
	       spread -	Schedulers are spread as much as possible.

	     nnts:
	       no_node_thread_spread  -	 Like  thread_spread,  but if multiple
	       Non-Uniform Memory Access (NUMA)	nodes  exist,  schedulers  are
	       spread  over one	NUMA node at a time, that is, all logical pro-
	       cessors of one NUMA node	are bound to schedulers	in sequence.

	     nnps:
	       no_node_processor_spread	- Like processor_spread, but if	multi-
	       ple  NUMA nodes exist, schedulers are spread over one NUMA node
	       at a time, that is, all logical processors of one NUMA node are
	       bound to	schedulers in sequence.

	     tnnps:
	       thread_no_node_processor_spread	   -	A    combination    of
	       thread_spread,  and  no_node_processor_spread.  Schedulers  are
	       spread  over hardware threads across NUMA nodes,	but schedulers
	       are only	spread over processors internally in one NUMA node  at
	       a time.

	     db:
	       default_bind  -	Binds  schedulers the default way. Defaults to
	       thread_no_node_processor_spread (which can change  in  the  fu-
	       ture).

	     Binding  of schedulers is only supported on newer Linux, Solaris,
	     FreeBSD, and Windows systems.

	     If	no CPU topology	is available when flag +sbt is	processed  and
	     BindType  is  any	other type than	u, the runtime system fails to
	     start. CPU	topology can be	defined	using flag +sct.  Notice  that
	     flag  +sct	 can have to be	passed before flag +sbt	on the command
	     line (if no CPU topology has been automatically detected).

	     The runtime system	does by	default	not bind schedulers to logical
	     processors.

       Note:
	   If  the  Erlang runtime system is the only operating	system process
	   that	binds threads to logical processors, this improves the perfor-
	   mance  of  the  runtime  system. However, if	other operating	system
	   processes (for example another Erlang  runtime  system)  also  bind
	   threads  to	logical	processors, there can be a performance penalty
	   instead. This performance penalty can sometimes be severe.  If  so,
	   you are advised not to bind the schedulers.

	     How schedulers are	bound matters. For example, in situations when
	     there are fewer running processes	than  schedulers  online,  the
	     runtime  system tries to migrate processes	to schedulers with low
	     scheduler identifiers. The	more the schedulers  are  spread  over
	     the  hardware,  the  more	resources are available	to the runtime
	     system in such situations.

       Note:
	   If a	scheduler fails	to bind, this is often silently	ignored, as it
	   is  not  always  possible to	verify valid logical processor identi-
	   fiers. If an	error is reported, it is reported to the error_logger.
	   If  you want	to verify that the schedulers have bound as requested,
	   call	erlang:system_info(scheduler_bindings).

	   +sbwt none|very_short|short|medium|long|very_long:
	     Sets scheduler busy  wait	threshold.  Defaults  to  medium.  The
	     threshold	determines  how	 long schedulers are to	busy wait when
	     running out of work before	going to sleep.

       Note:
	   This	flag can be removed or changed at any time without  prior  no-
	   tice.

	   +sbwtdcpu none|very_short|short|medium|long|very_long:
	     As	+sbwt but affects dirty	CPU schedulers.	Defaults to short.

       Note:
	   This	 flag  can be removed or changed at any	time without prior no-
	   tice.

	   +sbwtdio none|very_short|short|medium|long|very_long:
	     As	+sbwt but affects dirty	IO schedulers. Defaults	to short.

       Note:
	   This	flag can be removed or changed at any time without  prior  no-
	   tice.

	   +scl	true|false:
	     Enables  or  disables  scheduler  compaction  of load. By default
	     scheduler compaction of load is enabled. When enabled, load  bal-
	     ancing  strives  for  a  load  distribution, which	causes as many
	     scheduler threads as possible to be fully loaded  (that  is,  not
	     run out of	work). This is accomplished by migrating load (for ex-
	     ample, runnable processes)	into a smaller set of schedulers  when
	     schedulers	 frequently  run  out of work. When disabled, the fre-
	     quency with which schedulers run out of work is  not  taken  into
	     account by	the load balancing logic.

	     +scl  false  is similar to	+sub true, but +sub true also balances
	     scheduler utilization between schedulers.

	   +sct	CpuTopology:

	     * _Id_ = integer(); when 0	=_ _Id_	=_ 65535

	     * _IdRange_ = _Id_-_Id_

	     * _IdOrIdRange_ = _Id_ | _IdRange_

	     * _IdList_	= _IdOrIdRange_,_IdOrIdRange_ |	_IdOrIdRange_

	     * _LogicalIds_ = L_IdList_

	     * _ThreadIds_ = T_IdList_ | t_IdList_

	     * _CoreIds_ = C_IdList_ | c_IdList_

	     * _ProcessorIds_ =	P_IdList_ | p_IdList_

	     * _NodeIds_ = N_IdList_ | n_IdList_

	     * _IdDefs_	      =	      _LogicalIds__ThreadIds__CoreIds__Proces-
	       sorIds__NodeIds_		|	  _LogicalIds__ThreadIds__Cor-
	       eIds__NodeIds__ProcessorIds_

	     * CpuTopology = _IdDefs_:_IdDefs_ | _IdDefs_

	     Sets a user-defined CPU topology. The user-defined	 CPU  topology
	     overrides any automatically detected CPU topology.	The CPU	topol-
	     ogy is used when binding schedulers to logical processors.

	     Uppercase letters signify real identifiers	and lowercase  letters
	     signify  fake identifiers only used for description of the	topol-
	     ogy. Identifiers passed as	real identifiers can be	 used  by  the
	     runtime  system  when trying to access specific hardware; if they
	     are incorrect the behavior	is undefined. Faked logical CPU	 iden-
	     tifiers  are  not	accepted, as there is no point in defining the
	     CPU topology without real logical CPU identifiers.	Thread,	 core,
	     processor,	 and  node identifiers can be omitted. If omitted, the
	     thread ID defaults	to t0, the core	ID defaults to c0, the proces-
	     sor  ID defaults to p0, and the node ID is	left undefined.	Either
	     each logical processor must belong	to only	one NUMA node,	or  no
	     logical processors	must belong to any NUMA	nodes.

	     Both increasing and decreasing _IdRange_s are allowed.

	     NUMA node identifiers are system wide. That is, each NUMA node on
	     the system	must have a unique identifier.	Processor  identifiers
	     are also system wide. Core	identifiers are	processor wide.	Thread
	     identifiers are core wide.

	     The order of the identifier types implies the  hierarchy  of  the
	     CPU topology. The valid orders are	as follows:

	     * _LogicalIds__ThreadIds__CoreIds__ProcessorIds__NodeIds_,	  that
	       is, thread is part of a core that is part of a processor, which
	       is part of a NUMA node.

	     * _LogicalIds__ThreadIds__CoreIds__NodeIds__ProcessorIds_,	  that
	       is, thread is part of a core that is part of a NUMA node, which
	       is part of a processor.

	     A	CPU  topology can consist of both processor external, and pro-
	     cessor internal NUMA nodes	as long	as each	logical	processor  be-
	     longs  to	only  one NUMA node. If	_ProcessorIds_ is omitted, its
	     default position is before	_NodeIds_. That	 is,  the  default  is
	     processor external	NUMA nodes.

	     If	a list of identifiers is used in an _IdDefs_:

	     * _LogicalIds_ must be a list of identifiers.

	     * At  least  one  other identifier	type besides _LogicalIds_ must
	       also have a list	of identifiers.

	     * All lists of identifiers	must produce the same number of	 iden-
	       tifiers.

	     A	simple	example. A single quad core processor can be described
	     as	follows:

	   % erl +sct L0-3c0-3
	   1> erlang:system_info(cpu_topology).
	   [{processor,[{core,{logical,0}},
			{core,{logical,1}},
			{core,{logical,2}},
			{core,{logical,3}}]}]

	     A more complicated	example	with two quad  core  processors,  each
	     processor	in  its	own NUMA node. The ordering of logical proces-
	     sors is a bit weird. This to give a better	example	of  identifier
	     lists:

	   % erl +sct L0-1,3-2c0-3p0N0:L7,4,6-5c0-3p1N1
	   1> erlang:system_info(cpu_topology).
	   [{node,[{processor,[{core,{logical,0}},
			       {core,{logical,1}},
			       {core,{logical,3}},
			       {core,{logical,2}}]}]},
	    {node,[{processor,[{core,{logical,7}},
			       {core,{logical,4}},
			       {core,{logical,6}},
			       {core,{logical,5}}]}]}]

	     As	 long  as real identifiers are correct,	it is OK to pass a CPU
	     topology that is not a correct description	of the	CPU  topology.
	     When  used	 with  care this can be	very useful. This to trick the
	     emulator to bind its schedulers as	you want. For example, if  you
	     want  to run multiple Erlang runtime systems on the same machine,
	     you want to reduce	the number of schedulers used  and  manipulate
	     the  CPU topology so that they bind to different logical CPUs. An
	     example, with two Erlang runtime systems on a quad	core machine:

	   % erl +sct L0-3c0-3 +sbt db +S3:2 -detached -noinput	-noshell -sname	one
	   % erl +sct L3-0c0-3 +sbt db +S3:2 -detached -noinput	-noshell -sname	two

	     In	this example, each runtime system have two schedulers each on-
	     line,  and	 all schedulers	online will run	on different cores. If
	     we	change to one scheduler	online	on  one	 runtime  system,  and
	     three  schedulers online on the other, all	schedulers online will
	     still run on different cores.

	     Notice that a faked CPU topology that does	not  reflect  how  the
	     real  CPU	topology  looks	like is	likely to decrease the perfor-
	     mance of the runtime system.

	     For more information, see erlang:system_info(cpu_topology).

	   +sfwi Interval:
	     Sets scheduler-forced wakeup interval. All	run queues are scanned
	     each  Interval  milliseconds. While there are sleeping schedulers
	     in	the system, one	scheduler is  woken  for  each	non-empty  run
	     queue  found. Interval default to 0, meaning this feature is dis-
	     abled.

       Note:
	   This	feature	has been introduced  as	 a  temporary  workaround  for
	   long-executing  native code,	and native code	that does not bump re-
	   ductions properly in	OTP. When these	bugs have be fixed, this  flag
	   will	be removed.

	   +spp	Bool:
	     Sets default scheduler hint for port parallelism. If set to true,
	     the virtual machine schedules port	tasks when it improves	paral-
	     lelism  in	the system. If set to false, the virtual machine tries
	     to	perform	port tasks immediately,	improving latency at  the  ex-
	     pense  of	parallelism. Default to	false. The default used	can be
	     inspected in runtime by calling erlang:system_info(port_parallel-
	     ism).  The	 default can be	overridden on port creation by passing
	     option parallelism	to erlang:open_port/2.

	   +sss	size:
	     Suggested stack size, in kilowords, for scheduler threads.	 Valid
	     range  is	20-8192	kilowords. The default suggested stack size is
	     128 kilowords.

	   +sssdcpu size:
	     Suggested stack size,  in	kilowords,  for	 dirty	CPU  scheduler
	     threads.  Valid range is 20-8192 kilowords. The default suggested
	     stack size	is 40 kilowords.

	   +sssdio size:
	     Suggested stack  size,  in	 kilowords,  for  dirty	 IO  scheduler
	     threads.  Valid range is 20-8192 kilowords. The default suggested
	     stack size	is 40 kilowords.

	   +stbt BindType:
	     Tries to set the scheduler	bind type. The same as flag  +sbt  ex-
	     cept how some errors are handled. For more	information, see +sbt.

	   +sub	true|false:
	     Enables  or disables  scheduler utilization balancing of load. By
	     default scheduler utilization balancing is	disabled  and  instead
	     scheduler compaction of load is enabled, which strives for	a load
	     distribution that causes as many scheduler	threads	as possible to
	     be	 fully	loaded	(that is, not run out of work).	When scheduler
	     utilization balancing is enabled, the  system  instead  tries  to
	     balance scheduler utilization between schedulers. That is,	strive
	     for equal scheduler utilization on	all schedulers.

	     +sub true is only supported on systems where the  runtime	system
	     detects  and  uses	 a  monotonically  increasing  high-resolution
	     clock. On other systems, the runtime system fails to start.

	     +sub true implies +scl false. The difference  between  +sub  true
	     and  +scl	false  is  that	+scl false does	not try	to balance the
	     scheduler utilization.

	   +swct very_eager|eager|medium|lazy|very_lazy:
	     Sets scheduler wake cleanup threshold. Defaults to	 medium.  Con-
	     trols how eager schedulers	are to be requesting wakeup because of
	     certain cleanup operations. When a	lazy  setting  is  used,  more
	     outstanding  cleanup operations can be left undone	while a	sched-
	     uler is idling. When an eager setting  is	used,  schedulers  are
	     more frequently woken, potentially	increasing CPU-utilization.

       Note:
	   This	 flag  can be removed or changed at any	time without prior no-
	   tice.

	   +sws	default|legacy:
	     Sets scheduler wakeup strategy. Default strategy changed in  ERTS
	     5.10  (Erlang/OTP	R16A).	This strategy was known	as proposal in
	     Erlang/OTP	R15. The legacy	strategy was used as default from  R13
	     up	to and including R15.

       Note:
	   This	 flag  can be removed or changed at any	time without prior no-
	   tice.

	   +swt	very_low|low|medium|high|very_high:
	     Sets scheduler wakeup threshold. Defaults to medium. The  thresh-
	     old determines when to wake up sleeping schedulers	when more work
	     than can be handled by currently awake schedulers exists.	A  low
	     threshold	causes	earlier	 wakeups,  and a high threshold	causes
	     later wakeups. Early wakeups distribute work over multiple	sched-
	     ulers  faster,  but  work	does more easily bounce	between	sched-
	     ulers.

       Note:
	   This	flag can be removed or changed at any time without  prior  no-
	   tice.

	   +swtdcpu very_low|low|medium|high|very_high:
	     As	+swt but affects dirty CPU schedulers. Defaults	to medium.

       Note:
	   This	 flag  can be removed or changed at any	time without prior no-
	   tice.

	   +swtdio very_low|low|medium|high|very_high:
	     As	+swt but affects dirty IO schedulers. Defaults to medium.

       Note:
	   This	flag can be removed or changed at any time without  prior  no-
	   tice.

	 +t size:
	   Sets	 the  maximum  number of atoms the virtual machine can handle.
	   Defaults to 1,048,576.

	 +T Level:
	   Enables modified timing and sets the	modified timing	 level.	 Valid
	   range  is  0-9. The timing of the runtime system is changed.	A high
	   level usually means a greater change	than a low level. Changing the
	   timing can be very useful for finding timing-related	bugs.

	   Modified timing affects the following:

	   Process spawning:
	     A	process	calling	spawn, spawn_link, spawn_monitor, or spawn_opt
	     is	scheduled out immediately  after  completing  the  call.  When
	     higher  modified  timing  levels are used,	the caller also	sleeps
	     for a while after it is scheduled out.

	   Context reductions:
	     The number	of reductions a	process	is allowed to use before it is
	     scheduled out is increased	or reduced.

	   Input reductions:
	     The  number  of  reductions  performed before checking I/O	is in-
	     creased or	reduced.

     Note:
	 Performance suffers when modified timing is  enabled.	This  flag  is
	 only intended for testing and debugging.

	 return_to and return_from trace messages are lost when	tracing	on the
	 spawn BIFs.

	 This flag can be removed or changed at	any time without prior notice.

	 +v:
	   Verbose.

	 +V:
	   Makes the emulator print its	version	number.

	 +W w |	i | e:
	   Sets	the mapping of warning	messages  for  error_logger.  Messages
	   sent	 to  the error logger using one	of the warning routines	can be
	   mapped to errors (+W	e), warnings (+W w),  or  information  reports
	   (+W	i). Defaults to	warnings. The current mapping can be retrieved
	   using error_logger:warning_map/0. For  more	information,  see  er-
	   ror_logger:warning_map/0 in Kernel.

	 +zFlag	Value:
	   Miscellaneous flags:

	   +zdbbl size:
	     Sets  the distribution buffer busy	limit (dist_buf_busy_limit) in
	     kilobytes.	Valid range is 1-2097151. Defaults to 1024.

	     A larger buffer limit allows processes to	buffer	more  outgoing
	     messages  over  the  distribution.	When the buffer	limit has been
	     reached, sending processes	will be	 suspended  until  the	buffer
	     size  has shrunk. The buffer limit	is per distribution channel. A
	     higher limit gives	lower latency and higher throughput at the ex-
	     pense of higher memory use.

	   +zdntgc time:
	     Sets   the	 delayed  node	table  garbage	collection  time  (de-
	     layed_node_table_gc) in seconds. Valid values are either infinity
	     or	an integer in the range	0-100000000. Defaults to 60.

	     Node  table entries that are not referred linger in the table for
	     at	least the amount of time that this parameter  determines.  The
	     lingering	prevents  repeated deletions and insertions in the ta-
	     bles from occurring.

	   +ztma true |	false:
	     Enables or	disables support for tuple module apply	in the	emula-
	     tor.  This	 is a transitional flag	for running code that uses pa-
	     rameterized modules and was compiled under	OTP 20 or earlier. For
	     future compatibility, the modules will need to be recompiled with
	     the +tuple_calls compiler option. Defaults	to false.

ENVIRONMENT VARIABLES
	 ERL_CRASH_DUMP:
	   If the emulator needs to write a crash  dump,  the  value  of  this
	   variable is the filename of the crash dump file. If the variable is
	   not set, the	name of	the crash dump file is erl_crash.dump  in  the
	   current directory.

	 ERL_CRASH_DUMP_NICE:
	   Unix	 systems: If the emulator needs	to write a crash dump, it uses
	   the value of	this variable to set the nice value for	 the  process,
	   thus	 lowering its priority.	Valid range is 1-39 (higher values are
	   replaced with 39). The highest value, 39,  gives  the  process  the
	   lowest priority.

	 ERL_CRASH_DUMP_SECONDS:
	   Unix	 systems:  This	 variable gives	the number of seconds that the
	   emulator is allowed to spend	writing	a crash	dump. When  the	 given
	   number of seconds have elapsed, the emulator	is terminated.

	   ERL_CRASH_DUMP_SECONDS=0:
	     If	 the variable is set to	0 seconds, the runtime system does not
	     even attempt to write the crash dump file.	 It  only  terminates.
	     This  is  the  default  if	 option	 -heart	 is  passed to erl and
	     ERL_CRASH_DUMP_SECONDS is not set.

	   ERL_CRASH_DUMP_SECONDS=S:
	     If	the variable is	set to a positive value	S, wait	for S  seconds
	     to	 complete  the crash dump file and then	terminates the runtime
	     system with a SIGALRM signal.

	   ERL_CRASH_DUMP_SECONDS=-1:
	     A negative	value causes the termination of	the runtime system  to
	     wait  indefinitely	 until	the crash dump file has	been completly
	     written. This is the default if option -heart is  not  passed  to
	     erl and ERL_CRASH_DUMP_SECONDS is not set.

	   See also heart(3).

	 ERL_CRASH_DUMP_BYTES:
	   This	 variable sets the maximum size	of a crash dump	file in	bytes.
	   The crash dump will be truncated if this limit is exceeded. If  the
	   variable  is	 not set, no size limit	is enforced by default.	If the
	   variable is set to 0, the runtime system does not even  attempt  to
	   write a crash dump file.

	   Introduced in ERTS 8.1.2 (Erlang/OTP	19.2).

	 ERL_AFLAGS:
	   The	content	of this	variable is added to the beginning of the com-
	   mand	line for erl.

	   Flag	-extra is treated in a special way. Its	scope ends at the  end
	   of  the environment variable	content. Arguments following an	-extra
	   flag	are moved on the command line into section  -extra,  that  is,
	   the end of the command line following an -extra flag.

	 ERL_ZFLAGS and	ERL_FLAGS:
	   The	content	of these variables are added to	the end	of the command
	   line	for erl.

	   Flag	-extra is treated in a special way. Its	scope ends at the  end
	   of  the environment variable	content. Arguments following an	-extra
	   flag	are moved on the command line into section  -extra,  that  is,
	   the end of the command line following an -extra flag.

	 ERL_LIBS:
	   Contains  a	list  of  additional library directories that the code
	   server searches for applications and	adds to	 the  code  path;  see
	   code(3).

	 ERL_EPMD_ADDRESS:
	   Can be set to a comma-separated list	of IP addresses, in which case
	   the epmd daemon listens only	on the specified  address(es)  and  on
	   the	loopback  address (which is implicitly added to	the list if it
	   has not been	specified).

	 ERL_EPMD_PORT:
	   Can contain the port	number to use when  communicating  with	 epmd.
	   The	default	port works fine	in most	cases. A different port	can be
	   specified to	allow nodes of independent clusters to co-exist	on the
	   same	 host. All nodes in a cluster must use the same	epmd port num-
	   ber.

SIGNALS
       On Unix systems,	the Erlang runtime will	interpret two  types  of  sig-
       nals.

	 SIGUSR1:
	   A SIGUSR1 signal forces a crash dump.

	 SIGTERM:
	   A  SIGTERM will produce a stop message to the init process. This is
	   equivalent to a init:stop/0 call.

	   Introduced in ERTS 8.3 (Erlang/OTP 19.3)

       The signal SIGUSR2 is reserved for internal usage. No other signals are
       handled.

CONFIGURATION
       The  standard  Erlang/OTP  system can be	reconfigured to	change the de-
       fault behavior on startup.

	 The .erlang startup file:
	   When	Erlang/OTP is started, the system searches for	a  file	 named
	   .erlang in the user's home directory.

	   If  an .erlang file is found, it is assumed to contain valid	Erlang
	   expressions.	These expressions are evaluated	as if they were	 input
	   to the shell.

	   A typical .erlang file contains a set of search paths, for example:

	 io:format("executing user profile in HOME/.erlang\n",[]).
	 code:add_path("/home/calvin/test/ebin").
	 code:add_path("/home/hobbes/bigappl-1.2/ebin").
	 io:format(".erlang rc finished\n",[]).

	 user_default and shell_default:
	   Functions  in  the shell that are not prefixed by a module name are
	   assumed to be functional objects (funs), built-in functions (BIFs),
	   or belong to	the module user_default	or shell_default.

	   To include private shell commands, define them in a module user_de-
	   fault and add the following argument	as the first line in the  .er-
	   lang	file:

	 code:load_abs("..../user_default").

	 erl:
	   If  the  contents  of  .erlang are changed and a private version of
	   user_default	is defined, the	Erlang/OTP environment can be  custom-
	   ized.  More	powerful changes can be	made by	supplying command-line
	   arguments in	the startup script  erl.  For  more  information,  see
	   init(3).

SEE ALSO
       epmd(1),	 erl_prim_loader(3),  erts_alloc(3),  init(3), application(3),
       auth(3),	code(3), erl_boot_server(3), heart(3), net_kernel(3), make(3)

Ericsson AB			   erts	10.3				erl(1)

NAME | DESCRIPTION | EXPORTS | FLAGS | EMULATOR FLAGS | ENVIRONMENT VARIABLES | SIGNALS | CONFIGURATION | SEE ALSO

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=erl&sektion=1&manpath=FreeBSD+12.1-RELEASE+and+Ports>

home | help