Provided by: erlsvc_1.02-2_amd64 
NAME
erlsvc - CLI to control My service
SYNOPSIS
erlsvc [-C config] [-u user] [-g group] [-n node] [-h host] [-c cookie] [-r release] [-d
releases_dir] [-E erlang_root_dir] [-L erlang_libs_dir] [-M mods_dir] [-P pipe_dir]] [-O
log_dir]] [-V components] command [<command arguments>]
erlsvc help [command]
DESCRIPTION
erlsvc is the command line interface to manage the Erlang nodes making My service. This
includes bootstrapping a new node, starting and stopping it or handling release upgrade.
Technically speaking, it starts a "controller" locally (an Erlang node). This node may
spawn a process on a running target node to execute the command. This way, it's possible
to manage a node on a remote host.
You can get a summary of the command line options and a list of available commands by
issueing the command "erlsvc help". To get a help message for a specific command, use
"erlsvc help command".
OPTIONS
-C config or --config config
This specifies the path to a configuration file. See "CONFIGURATION" for more
informations about the format of this file and the options available.
Command line options always override values from the configuration file.
By default, erlsvc looks for the following files:
1. $HOME/.config/erlsvc/config-node@host.yaml
2. $HOME/.config/erlsvc/config-node.yaml
3. $HOME/.config/erlsvc/config.yaml
4. /etc/wayne/erlsvc-node@host.yaml
5. /etc/wayne/erlsvc-node.yaml
6. /etc/wayne/erlsvc.yaml
7. /etc/default/erlsvc
-u user or --user user
This specifies the user under which the service must run. The target node will first
start with the caller's user ID (eg. root) and will drop to user before starting the
service.
By default, the user is not changed.
-g group or --group group
This specified the group under which the service must run. See the -u option above
for an explanation.
By default, the gorup is not changed.
-n node or --node node
This specifies the name of the target node to start or manage.
The default is "myservice".
-h host or --host host
This specifies the hostname of the target node to manage. The hostname must be in a
"short" form: only up-to the first dot, not a full qualified domain name.
The default is the local hostname.
-c cookie or --cookie cookie
This specifies the Erlang cookie to be used for inter-node communication. This
cookie is also used as the starting target node's cookie.
By default, use whatever default cookie erl(1) would use.
-r release or --release release
This specifies the Erlang release to boot when starting the service.
The default is the permanent release.
-d releases_dir or --releases-dir releases_dir
This specifies the Erlang releases directory.
The default is the system Erlang releases directory, ie. the "releases" directory
under the Erlang root directory.
-E erlang_root_dir or --erlang erlang_root_dir
This specifies the Erlang root directory. This is useful when erl(1) is not in the
PATH or the one in the PATH is not to be used.
By default, erl(1) in the PATH is used.
-L erlang_libs_dir or --erllibs-path erlang_libs_dir
This specifies additionnal directories where Erlang application may be found. This
option may be specified multiple times to set several paths.
By default, none.
-M mods_dir or --mods-dir mods_dir
This specifies the directory where erlsvc's Erlang modules are.
The default is the erlsvc's distribution-level shared data directory as returned by
"dist_dir('erlsvc')" from File::ShareDir.
-R pipe_dir or --pipe-dir pipe_dir
This specifies the directory where run_erl(1) puts the named pipe required by
to_erl(1).
The default is /var/run/wayne.
-O log_dir or --log-dir log_dir
This specifies the directory where run_erl(1) puts its log files, such as run_erl.log
or erlang.log.*.
The default is /var/log/wayne.
-V component or --verbose component
This sets the verbosity per component or for all at once. This option may be
specified multiple times to enable/disable several components. To specify all
components, use "ALL". A component may be prefixed by '!' to disable verbosity only
for it.
Available components are:
• "APP"
• "ERLENV"
• "ERLNODE"
• "ERLSCRIPT"
• "MNESIA"
• "PROC"
• "REL"
• "SERV"
For instance, to enable verbosity for anything touching the service, use "-V SERV".
To enable everything but the service's message, use "-V ALL -V !SERV" (note that it
may be necessary to escape the '!' character to workaround shell interpretation).
COMMANDS
Available commands
Here is a list of available commands. Some commands don't have any action; they rather
provide sub-commands.
bosh4yaws
This command provides sub-commands to configure the bosh4yaws application.
ejabberd
This command provides sub-commands to configure the ejabberd application.
ejabberd_client
This command provides sub-commands to configure the ejabberd_client application.
ephp4yaws
This command provides sub-commands to configure the ephp4yaws application.
help This command display a generic help about erlsvc or a more detailed help about a
specified command.
mnesia
This command provides sub-commands to handle the Mnesia database.
php This command provides sub-commands to handle the PHP interpreter.
release
This command provides sub-commands to handle the Erlang releases. Especially, it's
used during live upgrade.
restart
This command restarts the service.
start
This command starts the service.
status
This command tells if the service is running.
stop This command stops the service.
target
This command provides sub-commands to manipulate a target system.
token_bucket
This command provides sub-commands to configure the token_bucket application.
yaws This command provides sub-commands to configure the yaws application.
Detailed help about a command
To obtain a more detailed help about a command, use the "help" command:
erlsvc help command
CONFIGURATION
Configuration format
A configuration file can be specified using the -C option. The file format conforms to
YAML, or more exactly a subset of the YAML specification, as documented in YAML::Tiny.
This may still be overrident by any command line option.
By default, erlsvc looks for the following files:
1. $HOME/.config/erlsvc/config-node@host.yaml
2. $HOME/.config/erlsvc/config-node.yaml
3. $HOME/.config/erlsvc/config.yaml
4. /etc/wayne/erlsvc-node@host.yaml
5. /etc/wayne/erlsvc-node.yaml
6. /etc/wayne/erlsvc.yaml
7. /etc/default/erlsvc
The expected structure of the YAML document is a hash where the keys are the long option
names (with "-" replaced by "_") and the value are obviously the values for these options.
If an option may be given multiple times to specify multiple values, the configuration
entry will have only one key pointing to a list of values.
Non-option variables
Beside variables mapping the command line options, erlsvc supports the following
additional variables :
erlapp_args
This specifies all the Erlang applications environment variable that must be passed
on the erl(1) command line. The structure pointed by the key must be a hash where
the keys are the application names and the values are a hash again, where the keys
are the environment variable name and the values, the variable's values.
extra_flags
This specifies extra command line flags to pass to erl(1). The structure pointed by
the key must a list of strings.
Examples
Here is a configuration file setting the user and group for the target node and enabling
all debug messages. It also shows how to specify Mnesia's data directory and how to
disable SMP in the Erlang emulator.
# Set the service identity to wayne:wayne.
user: wayne
group: wayne
# Be verbose.
verbose:
- ALL
# Set Mnesia's directory. Note how the quotes and double-quotes are
# used so that Erlang interprets the string correctly.
erlapp_args:
mnesia:
dir: '"/var/db/mnesia"'
extra_flags:
- "-smp"
- "disable"