Skip to content
This repository has been archived by the owner on Aug 8, 2018. It is now read-only.

Configuring and Logging

jnnk edited this page Jul 24, 2015 · 3 revisions

Configuring and Logging

Configuring pyethapp

To show the configuration pyethapp uses, run pyethapp with the config argument. Since the output includes each available config parameter (with default values, if not otherwise specified), this is also useful to list which configurable values are available:

$ pyethapp config
<Todo: output of pyethapp config>

There are two ways of altering the configuration:

  • by editing the configuration file
  • by passing command line arguments

Configuration File

The configuration file is written in YAML. It's named config.yaml and is looked for in an OS dependent directory: On Linux it should be ~/.config/pyethapp/config.yaml, on Mac OS X ~/Library/Application Support/pyethapp/config.yaml or ~/.pyethapp/config.yaml.

With the command line option --Config or -C (uppercase) this location can be overridden:

$ pyethapp -C ~/path/to/my_config.yaml run

Command Line Options

Each configuration parameter can also be set with the command line option -c (lowercase) using the following syntax: -c <some.config.value=4> where . notation is used to support nested configurables. Example:

$ pyethapp -c jsonrpc.listen_port=9876 run
$ pyethapp -c deactivated_services=["pow",\ "peermanager"] run  # \ to escape spaces

Note that the config options must be given ahead of the run subcommand. This is because -c (as well as -C and many other parameters) affects pyethapp in general (which updates the internal configuration object), but not any particular subcommand.

The -c option can be used multiple times. If the same value is specified more than once, the last one wins. If a parameter has also been set in the configuration file, the command line value takes precedence.

Logging

Logging in pyethapp is implemented in a very flexible way. Each log message is equipped with a source (which part of the program logged the message?) and a level (how important is it?):

Message Source Level
INFO:app registering service service='discovery' app info
DEBUG:eth.chain updating head candidate eth.chain debug

With the command line option --logging (-l) you can finely control which messages are kept and which are discarded. It expects a string of the form <source>:<min level>,<source>:<min level>,.... Sources are ordered hierarchical, such that one can specify base log levels and override them for subsidiary sources. Examples:

Log string Description
:WARNING only show warnings and errors (no source is specified, i.e. this is the global base log level)
:WARNING,p2p:DEBUG same as above, but include debug and info messages from p2p
:WARNING,p2p:DEBUG,p2p.discovery:INFO same as above, but omit debug messages from p2p.discovery

The following levels are used, in order of decreasing importance:

  1. fatal
  2. error
  3. warning
  4. info
  5. debug
  6. trace