``state`` section ================= a state has a unique name. other that processes, states can be defined without a fixed node-assignment. a state without an explicit node assignment will inherit the node from a depending process. there are two types of states: * a set of 3 shell-commands: CHECK, UP and DOWN the shell exit-code (return value) of the CHECK command is interpreted to decide whether a state is UP or DOWN. * a TCP tunnel state a TCP/IP tunnel established by the ln_daemons. only if tcp_tunnel_exit_target and tcp_tunnel_exit_node is specified. check ----- shell command to execute to decide whether a state is currently UP or DOWN. the shell exit-code (return value) of the CHECK command is interpreted to decide whether a state is UP or DOWN. a 0 exit-code is commonly interpreted as "success" and the state is assumed to be UP. every non-zero exit-code will cause the state to be assumed DOWN. up -- shell command to execute to bring a state UP. If a state is requested ``UP`` and the manager does not currently trust its last known state, it may first trigger a ``CHECK`` command instead of directly executing ``UP``. down ---- shell command to execute to bring a state DOWN. As with ``UP``, the manager may first run ``CHECK`` if the current state is not known or is considered outdated. min_check_interval ------------------ number of seconds to assume that last state-result is still valid. (default: 30 since version 0.13.11) The manager will not re-run ``CHECK`` more often than this unless a forced re-check is needed, for example because there were previous errors or because no result has been recorded yet. tcp_tunnel_exit_node -------------------- only for TCP tunnel states. Name of the node or host on which the tunnel target exists. tcp_tunnel_exit_target ---------------------- only for TCP tunnel states. Target address for the far end of the tunnel in ``HOST:PORT`` form. tcp_tunnel_entry_port --------------------- only for TCP tunnel states. Optional fixed local entry port for the tunnel. If omitted, ln_manager will use the same ``PORT`` from ``tcp_tunnel_exit_target``. flags ----- list of one or more of these flags: ``os_state`` request that ln_daemon treats this as an operating-system state when executing the state commands. The detailed semantics are implemented on the daemon side. ``autostart`` whenever a daemon connection for one of the state's assigned nodes becomes available, ln_manager automatically requests this state to go ``UP``. ``need_check_after_up`` after a successful ``UP`` or ``DOWN`` request, do not trust the immediate state notification as final. Instead, reset the cached state to unknown and require a fresh ``CHECK`` before the state is considered reliably known again. node ---- node where this state is assigned to. Unlike processes, a state can omit an explicit node. In that case ln_manager derives the node assignment from objects that depend on this state. depends_on ---------- list of dependencies that need to be fulfilled before the UP or DOWN command can be executed. This works like :ref:`config/process/depends_on`, but applies to state operations instead of process startup. Dependencies are considered when requesting ``UP`` or ``DOWN``. They are not automatically enforced for ``CHECK``. depends_on_restart ------------------ This works like :ref:`config/process/depends_on_restart`, but applies to states. If such a dependency goes away, ln_manager keeps the resulting error condition until the affected state has been re-established. provides -------- This works like ``provides`` in :doc:`config_process`. It allows a state to advertise that it can provide a named service or topic on demand. If multiple configured processes or states provide the same name, the one with the highest priority wins. output_buffer_size ------------------ This setting is inherited from the shared output configuration code, but unlike processes it is currently not forwarded as a state-specific request parameter to ln_daemon. In the current Python manager code it therefore has no documented practical effect for states. max_queued_output_bytes ----------------------- Maximum number of output bytes ln_manager queues for this state's displayed output before it starts dropping already buffered text, unless such skipping is disabled globally for that object type. max_output_lines ---------------- Maximum number of output lines kept in the ln_manager output widget for this state.