servdash

---

title: Service Dashboard description: servdash_gui and servdash_cli, the dashboards that launch, show and control the services of a shard, with a console per NeL service, the launch control protocol of the admin executor, and a Model Context Protocol server for agents. published: true date: 2026-10-30T08:30:00.000Z tags: editor: markdown dateCreated: 2026-10-30T08:30:00.000Z

A shard is a set of services that have to start in order, show their logs somewhere, take commands, and stop cleanly. The service dashboard does that from one ini file per shard. It comes as two tools that read the same files, behave the same and can be used on the same shard:

• servdash_gui, a Qt window for a development box, for Windows, Linux and macOS.
• servdash_cli, a terminal tool for Windows and Linux, split like tmux in a daemon that keeps the shard running and a client that attaches to it; also the dashboard of the production servers.

Both replace the Win32 servdash of the older quick start packages, and in production the screen scripts of the patchman package. Their sources are code/tool/servdash_gui and code/tool/servdash_cli, each with a README that goes into more detail than this page.

The window

The layout is the one of the original: a column of processes on the left, each with a state light (grey new, yellow starting, green ready, red stopping) and a start or stop button, with Launch All and Shutdown All above them, and the pane of the selected process on the right. The pane of a NeL service is its console: the status labels the service shows in its toolbar (NetLop, UsrLop, ...), the buttons it defines (Services, Quit), its log in colour, and a command line.

The command line completes the commands of the service: the rest of the first matching name shows in grey after the cursor with the arguments the command takes, the help on the right. Tab takes the suggestion, a handler instance such as moduleManager completes to moduleManager. and its commands follow; Shift+Tab moves to the next match. The table comes from the service itself, live, so a module loaded later completes too.

Long NeL log headers are compacted by default (F2 toggles: the type stays, the function is cut to its ends), lines can wrap (F3) and show their arrival time (F4). The window follows the system theme, dark or light.

Closing the window stops every process and waits for them, as the original did; a second close kills what is left.

The terminal

servdash_cli start_mainland.ini      start the daemon if needed, then attach
servdash_cli -d start_mainland.ini   start the daemon without attaching
servdash_cli -a start_mainland.ini   attach only
servdash_cli --shutdown start_mainland.ini   stop all services and exit the daemon
servdash_cli --list                  the running dashboards of this user
servdash_cli --shutdown-all          stop every running dashboard, with its services
servdash_cli 2                       attach to the second one in the list
servdash_cli Mainland                attach by title (or id, id prefix, ini path)
servdash_cli --mcp [<ini>...]        the MCP server for an agent, see below

The daemon owns the processes and keeps running when the terminal goes away: F10 detaches, closing the terminal detaches, and the same command attaches again, from any directory once the dashboard is in --list. Several terminals can attach to one dashboard at once. The layout and the console features are those of the window: the same completion, compact headers, wrapping and timestamps.

Keys: F5 start or stop the selected process, F6 kill, F7 start all, F8 stop all, F2 compact headers, F3 wrap, F4 timestamps, F10 detach, F12 twice to stop everything and quit, Alt+Up/Down or Ctrl+Up/Down select a process, Alt+1..9 press a console button, PgUp/PgDn scroll, Enter send the line, Tab and Shift+Tab complete. The mouse works too: click a process, its glyph, or a button.

One shard, either tool

A shard is open in one dashboard at a time: a lock file next to the ini, <stem>.servdash.lock, names the dashboard that holds it, and a second one is refused while that process lives. A lock left by a crashed dashboard is taken over.

Both tools register the dashboards they run in a per-user directory (%LOCALAPPDATA%\servdash\sessions on Windows, $XDG_RUNTIME_DIR/servdash.sessions or /tmp/servdash.sessions.<uid> on Linux), and a window serves the same client protocol as a daemon. So servdash_cli --list names the windows too, servdash_cli <title> attaches a terminal to a window, with the same panes and keys, servdash_cli --shutdown <title> closes it, and the MCP server of either tool reaches every dashboard whichever tool opened it. The other way round does not exist: a window cannot attach to a daemon, since a window owns its processes.

In the quick start package

The shard scripts of the Quick Start for Windows (shard_unifier.bat, shard_mainland.bat, shard_ring.bat, and web_on.bat for the web services) open servdash_gui. With "Headless": true in .nel\config.json they run servdash_cli in the console instead, for a development box reached over SSH: F10 detaches and the same script attaches again. The Win32 servdash of external\utils stays as the fallback when neither tool is built.

servdash_gui is built with the tools (code_build_all.bat, whenever Qt is found). servdash_cli is a Rust crate, built by build_docker\tools_xplat_build.bat in the ryzombuild_xplat_tools Docker image for Windows and for a generic Linux, and the Linux binary goes into admin_install.tgz with the shard patch, so it reaches the servers with the patchman package.

The ini file

The format and keys of the Win32 servdash, which ignores the keys it does not know, so one file serves every dashboard. ; starts a comment, [section] starts a process, Key=Value is split at the first =, and the unnamed section before the first header holds the dashboard Title.

Key	Meaning
Title	Fixed button text; without it the button follows the process title. In the unnamed first section: the dashboard title.
WorkingDirectory	Working directory of the process; a LaunchCmd starting with . is taken from it. Any other command is looked up on the PATH.
LaunchCmd, LaunchArgs	The program and its arguments. On Windows the argument string is passed as it stands; on Linux it is split like a shell does.
ShutdownCmd, ShutdownArgs	A program run to stop the process. Without any stop method the process is killed.
ShutdownInput	A line written to the process stdin to stop it.
RestartDelay	Seconds after which a process that exited on its own starts again, for a process without LaunchCtrl such as a patchman. Stop and Kill keep it down. An exit within the first minute of a run doubles the delay each time, up to five minutes; a longer run resets it.
ReadyPattern	Regex for the ready state: on the title a NeL service reports, or on the output lines of a plain process.
Priority	Start order group, lowest first; processes without it start one at a time, each waiting for the previous one to be captured.
AutoStart	0 keeps the process out of the start sequence.
LaunchCtrl	ctrl,state,LAUNCH,RUNNING,STOP,STOPPED: the launch control protocol below.
Control	1 for a NeL service with the console channel.

The patch terminal of the build pipeline generates the shard files (start_mainland.ini and the others in pipeline\shard_dev), so there is normally nothing to write by hand. The dashboard runs with the directory of the ini file as working directory. The processes are tied to the dashboard: a job object on Windows and the parent death signal on Linux take them down if the dashboard itself dies, so a restarted dashboard never declares a service stopped while it still runs.

NeL services and the console channel

A section with Control=1 is a NeL service. The dashboard listens on a local endpoint for it and appends --ctrl=<endpoint> to its arguments. The service then runs a CSocketDisplayer instead of its own window and streams its log, labels, buttons, title and command table to the dashboard, which executes the commands typed or clicked there, exactly as its Win32 window did. --ctrl overrides the WindowStyle of the service configuration, so a service started by hand still opens its own window. Whatever the service writes to stdout or stderr besides, an assert or a crash report, shows in the same pane in grey, with the dashboard's own notes about the process.

A control section is stopped with quit over the channel. A service binary that never connects (one built before --ctrl) counts as captured after 30 seconds, so the start order of the shard goes on without it. A section without Control is shown through its pipes, and its ReadyPattern is matched against the output lines.

Launch control files

The admin executor service (AES) controls a service it registered through files in the service directory: it writes <alias>.launch_ctrl with LAUNCH or STOP, writes <alias>.deferred_launch_ctrl with LAUNCH to restart a service it told to quit, polls <alias>.state for RUNNING or STOPPED, and reads <alias>.start_count for its crash chain detection. The shard controls of the web admin work through this. The dashboards do what service_launcher.sh does under screen: start and stop on the orders, write the state and the counter, consume a LAUNCH order when the process exits so a crash does not relaunch in a loop, and promote a deferred order after the exit. The start and stop buttons write the order file, so the AES stays in step with what you click. A service that exits quickly several times in a row is restarted by the AES with a growing delay, from two seconds up to five minutes, so a chain crash does not hammer the box.

Production servers

The patchman package (admin_install.tgz, see Install Patchman) carries servdash_cli in bin/, and its scripts have a servdash mode next to the screen one, chosen by the presence of the file /home/nevrax/use_servdash. In that mode:

• bin/admin start writes /home/nevrax/admin.ini from patchman_list and special_patchman_list, the patchman of the host and its special roles, each with a RestartDelay instead of a shell loop, and starts a detached dashboard on it; bin/admin join attaches, bin/admin stop shuts it down.
• Each domain gets <domain>/<domain>.ini from the patch applier, next to its <domain>.screen.rc: the aes section from patchman/servdash.ini.default, then a section per service with the launch control files the AES drives. bin/domain_<domain> start|stop|join|share|state use it.
• servdash_cli --list names every dashboard of the nevrax user, and servdash_cli <title> attaches to one from anywhere.

Without the marker file everything runs under screen as before.

MCP server for agents

servdash_cli --mcp [<ini>...] and servdash_gui --mcp [<ini>...] serve the Model Context Protocol on stdin and stdout, for an agent such as Claude Code that watches, drives and debugs the shards and the patchman services of the machine. The server is a client of the dashboards like the terminal is: it attaches to every running dashboard of the user as it appears, whichever tool opened it, mirrors their processes, logs and command tables, and forwards the orders. The dashboards keep running when the agent leaves. The ini files given are started when they do not run yet (a daemon for servdash_cli, a window for servdash_gui), so a project can name its shard and have it come up with the agent.

In the quick start root, .mcp.json registers _servdash_mcp.bat with Claude Code, which runs the tool the shard scripts use. Elsewhere:

{ "mcpServers": { "servdash": { "command": "servdash_cli", "args": ["--mcp", "start_mainland.ini"] } } }

On a production server, claude mcp add servdash -- /home/nevrax/bin/servdash_cli --mcp gives an agent every dashboard of the nevrax user: the patchman services of admin.ini and the domains, so a deployment can be followed and fixed from the same session. Every tool takes a dashboard parameter (title, id, ini path) that can be left out while one dashboard runs.

Tool	What it does
list_dashboards, start_dashboard, shutdown_dashboard	The dashboards running; start one from an ini file; stop everything and exit one.
list_processes, get_process	State, pid, uptime, launch control value, pending restart, log line range; the service's status labels and buttons.
start_process, stop_process, kill_process, restart_process, start_all, stop_all, wait_for_state	The buttons, each with an optional wait for the resulting state.
list_commands	The command table of a service: commands, variables, handler instances and member commands with argument syntax and help, filtered by prefix or word.
run_command	A NeL command with its arguments as a list, run over the console channel without parsing (a value with spaces, quotes or semicolons arrives intact); returns what the command logged, cut out between the request and its completion marker.
send_input	A line on the stdin of a plain process, with the output that follows.
get_log	Lines of a process, or of all processes merged by time: by index range, time range or last N, then optionally following for a while up to a line cap; filtered by log type or regex.
clear_log	Drops the held lines.

Every log line carries an index, per process from 1 and never reused, and its arrival time in milliseconds, so a window of a log ("the 50 lines before the crash", "everything between these two indices", "the next 10 seconds") is named exactly and can be fetched again. get_log shows idx time type message by default, with the NeL prefix (thread, file, line, function) left out to keep the answer short; prefix: compact adds file, line and function, prefix: full keeps the line as logged. Plain output shows as type out, the dashboard's own notes (started, exited, restarting) as dash. The dashboards hold the last 10000 lines per process.

Building

In the Ryzom Core tree, servdash_gui builds with WITH_QT5 or WITH_QT6 (Qt 5.15 or later with the Core, Gui, Widgets and Network modules; Qt 6.12 or later draws best at fractional display scales). On its own:

cmake -S tool/servdash_gui -B build_gui -DCMAKE_PREFIX_PATH=<Qt install prefix>
cmake --build build_gui

servdash_cli needs Rust 1.75 or later: cargo build --release in tool/servdash_cli gives a single binary with no runtime files; a musl target gives a fully static one for the servers, and cargo-xwin cross-builds the Windows binary from Linux without Visual Studio. The Ryzom Core: Tools workflow on GitHub builds both on every change.