Master configuration file is the one that usually at
/etc/lithos/master.yaml and defines small subset of global configuration
parameters. Minimal configuration is an empty file but it must exist
anyway. Here is the reference of the parameters along with the default values:
The directory for per-application configuration files which contain limits of what application might use. If path is relative it’s relative to the directory where configuration file is. Default is
The directory for per-application configuration files which contain name of image directory, instance number, etc., to run. If path is relative it’s relative to the directory where configuration file is. Default is
The directory where
pidfile of master process is stored and also the base directory for
mount-dir. Path must be absolute. It’s expected to be stored on
The directory where to keep container’s state dirs. If path is relative it’s relative to
/run/lithos/state). Path should be on
An empty directory to use for mounting. If path is relative it’s relative to
The directory where
/devfilesystem for container exists. If it’s not
/dev(which is not recommended), you should create the directory with
The name of the root cgroup for all lithos processes. Specify
null(or any other form of YAMLy null) to turn cgroups off completely.
List of cgroup controllers to initialize for each container. Note: the empty list is treated as default. Default is
[name, cpu, cpuacct, memory, blkio]. If you have some controllers joined together like
cgroup-name: nullto turn cgroup tracking off (not empty list here). And use
cgroup-controllers: [name]to only use cgroups for naming processes but not for resource control.
turning off cgroups means that resource limits does not work completely. lithos will not try to enforce them by polling or some other means
/var/log/lithos) The directory where master and each of the application logs are created (unless are overrided by sandbox config).
/var/log/lithos/config) The directory where configurations of the processes are stored. These are used by
lithos_cleanto find out when it’s safe to clean directories. You may also reconstruct processes configuration at any point in time using this directory.
Changed in version 0.10.2: Parameter can be
In this case no configuration logging is done. This is mainly useful if you track configurations and versions by some other means.
This is enabled by default for backwards-compatibility reasons. We consider resetting this value to
nullby default in
lithos 1.0as this parameter is not as useful as were expected.
/var/log/lithos/stderr) The directory where stderr of the processes will be forwarded. One file per sandbox is created.
These files are created by lithos and file descriptor is passed to the application as both the stdout and stderr. Lithos does not parse, copy or otherwise proxy the data. The operating system does all the work. This also means lithos can’t rotate or do any other magical things with the log.
This should be used only to tackle the critical errors. Application should send log to a syslog or write some rotating log files on it’s own, because there is no good tools to groups lines of the stderr into solid log messages that include tracebacks and other fancy stuff.
Good utilities to manage the files:
rsyslogwith file input plugin
This can be overridden in process by
The path is reopened on process restart. If
restart-process-onlyis true then it’s only reopened when configuration changes. This is good to know if you remove or rename the file by hand.
warn) Level of logging. Can be overriden on the command line.
(no default) Enables logging to syslog (with specified facility) instead of file.
lithos) Application name for master process in syslog. The child processes are prefixed by this value. For example
djangois a sandbox name).