The first section is
app, which control general options:
[app] autosave = true immersion = false
autosave key controls wether the changes on the runtime made via API to the configuration will be saved or not. When enabled, every change triggers first a backup of the current TOML file (in the
/config/backup directory, with the current UTC timestamp as suffix), and then save the new values on the existing files. Note that only certains commands trigger autosaving.
immersion key indicates wether immersion mode is enabled or not. When enabled, this mode sets the fan speed to a fixed zero, and ignores the minimum number of fans check.
The logging configuration is stored in
[app.logging] level = "info" file_level = "debug"
level key controls the logging level on
stdout. If you're not running the miner in you ssh session and looking at the live logs while your miner runs, you might as well leave it as
off if you want.
file_level is the logging level for file output. Each time
luxminer is ran, a brand new
/logs/<DATE>/luxminer.log file is created, and the previous file is kept in the same folder, with a timestamp suffix. Log file rolling happens every run, or when the file reaches around 50MB. Past log files are automatically discarded when the system is close to running out of space. Note that on NAND installs, the
/logs directory might be redirected to the ramdisk (
/mnt/ramdisk/logs) to avoid writing too much on NAND memory.
Both keys can accept either a single "level" value (
trace), or a complex logging filter in the form of
module=level, to use different levels for different pieces of the system.
Logging and performance
Choosing the right level of logging depends on a multitude of scenarios like available disk space and being able to track down eventual failures. The correct logging level, will depend of your needs.
As a general rule, more verbose level incurs in more performance penalty, but allows for much more detail when troubleshooting. When requesting support help, try to do the minimun steps to reproduce the problem with
API access can be configured on the
[app.api.tcp] enabled = true port = 4028 [app.api.http] enabled = true port = 8080
The "core" API is a TCP, CGMiner-like API, running on port
4028 by default. Additionally, an HTTP RPC layer on port
8080 is provided to make integration with different tools and languages easier. Any of them can be disabled by changing the
It is recommended to leave the API ports on the default setting since they are used (or assumed) as default for most tools and scripts, so consider changing or disabling those ports only if you have a good reason to do so. For usage information and examples, check the API section of the documentation.
If you disable the HTTP layer, the built-in LUXminer UI won't be able to communicate with the miner.
It is also possible to configure the pool connection switching with
[app.pool_options] smart_switch = true smart_switch_secs = 60 timeout_secs = 5 max_errors = 5 backoff_on_error = true
smart_switch, when enabled (default) will switch back to the main pool automatically when it becomes available again. The check is done every
smart_switch_secs seconds. The maximum number of connctions before going to the next pool, and the timeout for each connection attemps are determined by
timeout_secs, respectively. The
backoff_on_error field adds an incremental backoff on subsequent connection errors, which helps when the network struggles to connect to the pools.
The auto update configuration can be set with on the
[update] source = "https://storage.googleapis.com/luxor-firmware/stable" timeout = 60 on_startup = "off" on_timeout = "off" on_user = "full"
source points to the URL that is the source of updates, and points by default to the stable channel. The
on_timeout triggers defined when the automatic update will trigger (in minutes), and what action will happen on that timeout. Since the action is
off by default, nothing will happen and the miner won't be automatically updated. Likewise,
on_startup is also
off; if it is changed to
full, update will be atempted every time the miner starts.
on_user trigger is
full by default. This is trigger is activated via UI, when the "Check for updates" button is clicked by the user.