Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.

Updated for v6.5.



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

ruservice is used to start, stop, restart, and get the status of system RUSS servers. System configurations are stored in /etc/russ/conf. Running server have a pid file at /var/run/russ/pid and socket files at /var/run/russ/services (also identified as RUSS_SERVICES_DIR).

With the introduction of RUSS v6, management of system servers has changed.

All system server configuration files must be are organized directly under /etc/russ/conf; no subdirectories. Configuration files associated with a particular server implementation/package must be named as <name>.conf or <name>.<subname>.conf. The latter form is useful when multiple instance of the same server are needed but for different uses. This naming scheme allows packages to easily identify and target configurations that depend on the server software.As before, a system server is exposed via a socket file under the RUSS_SERVICES_DIR. But a system server may also be exposed as a configuration file in the same RUSS_SERVICE_DIR location. A server with a file of either kind (socket or configuration) under RUSS_SERVICES_DIR is said to be "running", including subdirectories.

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


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

So, when 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

the standard approach is used: start a server with is started and a socket file . This is required for servers that must run as a user different than the user connecting to the server; a 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.

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. This approach 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, it will dynamically start a server which will then be connected towill 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 file servers instead of rustart. The benefit of ruspawn is automatic cleanup of ruspawn automatically cleans up the socket file when the server exits/is killed.