Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin

Updated for v6.5.



RUSS servers that are made available on the system are managed using the ruservice tool.

System server configuration files are organized directly under /etc/russ/conf, including subdirectories.

The first line of configuration files is used to mark it as a RUSS configuration file:

Code Block
#russ [<directive>] [...]

and provide some additional information/directives that may be used, e.g., by ruservice.

ruservice is support operations: start, stop, restart, list, and status.

Each running server has a pid file at /var/run/russ/pid and a service file (which is a socket or special configuration file) at /var/run/russ/services (which path is also identified as RUSS_SERVICES_DIR).

When ruservice is called to start a server, it examines the first line of the configuration file in /etc/russ/conf. If it contains "service=socket" as:

Code Block
#russ service=socket

a server is started and a socket file is set up. If the configuration file contains "service=conffile" as:

Code Block
#russ service=conffile

a slightly modified/augmented copy of the configuration file is copied to the RUSS_SERVICES_DIR.

A server that needs to perform operations as root on behalf of the connecting user must always use a server actively listening on a socket file. A socket file server is also useful when the fastest turnaround time (connect, perform service, close) is required.

The conffile approach is suitable for servers that will run as the connecting user. In effect, when the dial function in the RUSS library is called and finds a configuration file instead of a socket file, a server will be started dynamically and the connection be established. Because the server is actually started by the connecting user, this is suitable only for servers that must run as the connecting user. Since a new server must be started each time, there is a small performance penalty. The benefit is that less system servers need to actually be running as processes.

ruservice uses ruspawn to start socket servers. ruspawn automatically cleans up the socket file when the server exits/is killed.


No Format
usage: ruservice <name> {start|stop|restart|status|list}
       ruservice list|status
       ruservice -h|--help|help

Manage system configured RUSS servers as configured in:

The given <name> may be the name of the configuration (without
.conf), a directory, or "." for all.


Single Server

Start server:

No Format
ruservice ssh start

Stop server:

No Format
ruservice ssh stop

Restart (RUSS) ssh server:

No Format
ruservice ssh restart


  • applies to configuration file at /etc/russ/conf/ssh.conf

Collection of Servers

Restart collection of servers under fspc:

No Format
ruservice fspc restart


  • applies to configuration files under /etc/russ/conf/fspc (e.g., /etc/russ/conf/fspc/*.conf)

Restart a single instance of a collection of servers:

No Format
ruservice fspc/local restart

All Servers

Restart all servers:

No Format
ruservice . restart

Get status of all servers:

No Format
ruservice . status