Background services and operations dashboards on CADR and Genera

System 46 has a Chaos background process, not a service console

System 46 creates a process named Chaos Background. Its queue receives forms in FIFO order after a list reversal, runs timed retransmission and probing work, and is part of the network substrate on which the QFILE client depends. The general process top level directs output from windowless processes to a background stream. This is infrastructure, not an application frame: the inspected source defines no pane layout, command menu, or dedicated Select key for it.

The contemporary operations manual describes the visible recovery path. An error or typeout from a process without an exposed window produces a notification. Terminal 0 S selects the window that wants attention; Terminal S returns to the previous window. This selection mechanism is generic and may choose any waiting background or deexposed process. It is not a “Chaos dashboard.”

System 46 also does not contain the later Lisp Machine file servers. Its QFILE code is a client of the FILE job on an ITS or TOPS-20 file computer. The server side in this snapshot is PDP-10 MIDAS source. The architectural and protocol details are documented separately in File systems and file service on CADR and Genera.

System 303 FILE server

The maintained FILE-SERVER system registers a Chaos FILE initializer. Each accepted connection gets a process named File Server and private bindings for its control stream, openings, data connections, transaction identifier, protocol version, user, and server tag. The server:

• rejects incompatible Symbolics connections and unsupported protocol versions;
• adds the live connection to the file-state who-line sheet;
• reads and dispatches commands until EOF, close, or network failure;
• removes the who-line entry, abort-closes remaining openings, and tears down data connections during unwind cleanup.

The source retains errors as records in LMFS-SERVER-LOSSAGES containing time, operation identifier, report text, and remote Chaos host. The direct source-level operator/diagnostic entry points at this article's grain are:

These are Lisp functions or variables, not a visible command table.

Live server details also feed the file-state who-line and a Peek server presentation. That is a monitoring surface, but still not a dedicated operations frame. See Peek for the general program and Error handler and debuggers for the debugger rather than treating either as part of the file server.

System 303 LMFILE server

The declared LFS system has an LMFILE-SERVER component whose active module is file2/server.lisp. The similarly named file2/xserver.lisp is an alternate preserved file and is not the module selected by the inspected system declaration.

ENABLE-FILE-SERVER adds a Chaos LMFILE server initializer. A connection creates an LMFILE server process, parses the user and first command from the RFC, records (user, host, time) in LMFILE-SERVER-CONNECTION-RECORD, opens that user's file area where supported, and adds a who-line server entry. Unwind cleanup closes the connection, removes the who-line entry, closes the file area, and may free cached areas. Disk-full and disk-unfull conditions send explicit lossage and recovery messages to the remote client.

The maintained file2/maint.text describes the complete network-service maintenance surface at that document's grain:

The mail-server enable/disable calls are included because the file-computer boot procedure invokes them beside the file server. They do not imply a ZMail-like mail operations dashboard.

The background window is an error-handler entry into a dead server, not a status screen. The maintenance text explicitly warns against simply aborting a process that might hold a node lock or be midway through a structural update. If the operator cannot establish a safe continuation, clearing and restarting the file system is the documented last resort. Terminal 0 S also cycles through unrelated windowless/deexposed processes in attention order, so even its target is not file-server-exclusive.

CADR visible-surface inventory

At the stated infrastructure grain, neither inspected CADR release defines a file-service command menu or multi-pane dashboard:

This absence is itself a lineage result: the Genera programs below are later operations interfaces, not renamed System 46 applications.

Background task queues

A Server Utilities background task stores a name, function, interval, and last-run time. A queue has its own polling period and task list. On process start, all tasks are made immediately due; after that, a task runs only when elapsed time is greater than its interval.

The shared Server Utilities Background process polls every two minutes. Two standard tasks are registered by the logging layer:

A requested task interval cannot make this queue wake more often than its two-minute polling period. This becomes an observable source/manual concern for the Mailer frame below.

Logging destinations and state

LOG-EVENT accepts exactly four event types: :normal, :problem, :disaster, and :debug. Debug entries are conditional on the log's debugging flag. Mixins independently send one event to:

• the in-memory/display history;
• an optional rotating file;
• configured remote hosts through notification;
• the local notification system for problem and disaster events;
• an interactive typeout destination when a command requests it.

If a monitor pane is locked—for example by a menu—the event is not written to the pane. The mixin counts such losses and reports the count when output resumes. By default, the shared background task keeps approximately the latest 500 lines of on-screen history. This does not truncate the associated log file.

File logs default to 450,000 characters per generation and use a default generation-retention count of 10. Rotation also reaps and expunges the log directory. The five-minute finisher handles ordinary flushing, a file server that closes the stream asynchronously, and filesystem/network errors. Warm-boot cleanup forcibly unlocks log objects, detaches old streams, and closes them in another process; before a cold save, open log files are closed.

One implementation limit is especially important to preservation work: LOG-EVENT silently does nothing until the window system's initialization flag is set. The source calls this a quick fix and identifies warm-booting a MacIvory with the print spooler already running as the known case. A missing early entry is therefore not proof that the event did not happen.

Identity and purpose

Three names refer to the same operational family:

• the loadable system's pretty name is Mailer;
• its bug-report system is Store-and-Forward Mailer;
• the Dynamic Windows program's pretty name is also Store-and-Forward Mailer, while the installed manual calls the visible frame Mailer Operations.

The Mailer receives messages, maintains local and remote delivery state, resolves hosts and mailboxes, retries deferred or failed work, and optionally hardcopies selected users' mail. The operations program is its status, log, and command surface; it is not a mail reader. User-facing message reading and composition belong to ZMail.

Processes, queues, and durable state

The source divides work among a foreground process, a background process, optional delivery processes, an optional slow-delivery process, and transient receipt work. The shipped defaults enable delivery processes, request one delivery process, and enable the slow-delivery process. If no slow network is present, the source declines to create that special process.

The foreground startup list runs, in order: log monitor, options, directory, log file, Dialnet registry where applicable, breathing room, UID, queues, mailboxes, hosts, and messages. A cold Start Mailer reconstructs that environment from persistent files; the source-only RESTART-MAILER function selects warm recovery. The operations menu does not expose a separate Restart command.

The Mailer uses a rejection-slip object to explain why incoming service is temporarily unavailable:

The three concrete queues are Incoming, Outgoing, and Slow. The display also computes Active and Retransmit pseudoqueues: Active counts messages currently held by foreground/delivery workers, while Retransmit counts queued host messages not already represented by those states.

Mailer storage has static, dynamic, log, and hardcopy directories. It reserves a 200,000-byte “breathing room” file. A coordinated no-more-room handler can delete that reserve, expunge the dynamic directory, and retry the failed operation; this is a failure-survival mechanism absent from the manual's high-level window description.

Mailer background schedule

The Mailer owns a private queue polled once per minute:

These six registrations are the complete set targeting *MAILER-TASK-QUEUE* in the inspected Mailer source tree.

Complete pane and selection inventory

Select O invokes the Mailer selector, registered with the label Mailer. The source defines six panes:

The manual describes five functional panes—Log, Processes, Queues, Commands, and Mailer Listener—because it does not count the title strip. That is consistent with the six source pane objects.

The private command table inherits no other table and disables keyboard accelerators. Thus the complete direct VLM command inventory is the following 15 commands:

A sixteenth source definition, Reload Subnet File with no arguments, is guarded by #-VLM. It is not part of the Open Genera/VLM menu and reloads the Dialnet registry on other machine types.

Relevant Mailer Command Processor area

The Mailer Command Processor table is a subset of Site Administration. At the article's direct-definition grain it contains one command:

Address presentations also translate to this command. Presentation translators are invocation paths, not additional commands.

Manual cross-check and source-only findings

The installed netio17 Help lists the same 15 VLM commands and the same five functional panes. It also explains the five queue labels. Three details require source evidence:

1. The manual says Clear Log History clears the Log pane. The implementation clears both Log and Listener history.
2. The program registers a shared “Log frame update” background task with a ten-second interval, but the shared queue wakes only every two minutes. The process and queue panes therefore cannot be refreshed by that task every ten seconds; the effective background wake cadence is no faster than two minutes.
3. Cold Start and warm Restart are distinct source paths, but only Start appears in the direct operations command table.

Identity, workers, and persisted requests

The PRINT system's pretty name is Print Spooler. Its serial modules load log, request, printer-manager, printer-queue server, and device/backend support. The visible program's pretty name is Printer Spooler Log.

Starting the spooler waits until the window system is initialized, initializes a new log, reads the local host's spooled-printer objects, creates or reuses one printer manager per supported printer, and enables those manager processes. Requests and per-printer stable queue/policy/characteristic state live under a printer-specific >Print-Spooler> directory. Halting sends shutdown to every manager and closes the log; it does not erase queued requests.

The :printer-queue service enable hook starts the spooler only when the local host has at least one spooled printer and advertises Hardcopy service. Startup and shutdown are spun into separate processes because an embedded host can enable services before window initialization.

Each printer manager has exactly six declared states:

The manager separately tracks device state, so a spooler can be logically idle or printing while the device reports an operational, intervention, or irrecoverable condition. A top-level error moves the manager to :crashed and logs a disaster.

Complete program surface

Select S is registered with label Print Spooler. The source defines three panes and no title pane:

The command table inherits only Global. Source lines for Colon Full Command, Standard Arguments, and Standard Scrolling are present but commented out. Keyboard accelerators are disabled.

There are exactly two direct program commands, both argumentless:

Complete direct Printer Maintenance area

Printer Maintenance is a subset of Site Administration. Its three direct commands are:

Printer and printer-request presentations translate to these commands. Ordinary Printer queue/request commands are a different user surface and belong with the printing pipeline rather than this operations-dashboard inventory.

Manual cross-check and source-only findings

The installed Printer Installation Guide agrees on Select S, the log/prompt division, startup semantics, persistence of queued requests while halted, and reprinting of a request interrupted by spooler shutdown. It disagrees in two visible details:

1. The guide calls the menu item Stop Print Spooler. The inspected source defines and labels it Halt Print Spooler.
2. The guide says the prompt accepts all commands normally found in a Lisp Listener. The inspected private command table inherits only Global, with the broader command tables commented out. Runtime is needed to determine the exact effective inherited command set in this world.

The printer manager also marks one logging attribution as knowingly inaccurate: the fixed process identifier used for Printer Queue Server access-path logging is unrelated to the actual sending process. A log's process tag should therefore not be treated as reliable process provenance for that path.

Finally, the common Server Utilities pre-window loss rule applies despite the spooler's explicit waits. The shared logging source specifically names a warm boot with an already-running print spooler as its known early-loss case.

Identity and service architecture

The loadable system is DOMAIN-NAME-SERVER with patch atom IPDS; its only serial module is the domain-server implementation. The visible program is Domain Server Log.

The same request handler is exposed through two network servers:

The handler logs requests and responses, answers ordinary queries with optional recursion, handles authority transfer, refuses inverse queries, and marks unknown opcodes not implemented. Errors generate an automatic bug report and a log entry; an error in one query is translated into server failure for that response. Returned authoritative TTLs are capped at six hours by the inspected server.

Launch Domain Server first lands the old instance. Unless an internal override is supplied, the local host must advertise Domain service. The launch file supports four active record types:

Launch initializes/reinitializes the resolver, enables the handler flag, and starts Domain Server Background. Secondary transfers are scheduled every 60 minutes; a failed transfer is retried after 15 minutes.

Complete program surface

Select @ is registered with label Domain Server Log. Its private command table inherits Colon Full Command, Standard Arguments, Standard Scrolling, and Global; keyboard accelerators are disabled.

The four source panes are:

The four direct commands are:

Manual cross-check and source-only findings

The installed Networks and Site Operations Help documents the launch file, domain-data files, namespace service attribute, and primary/secondary roles. No matching Help section for the four-pane Domain Server Log program or its four commands was found in the inspected installed documents. The visible inventory above is therefore source-derived and remains a runtime TODO.

Two source details materially qualify the operator model:

1. LAND-DOMAIN-SERVER contains a call to disable network services, but that call is commented out. Landing kills background transfer work and clears the enabled flag; it does not itself unregister the byte-stream or UDP server definitions. A request reaching the still-registered handler while disabled receives a refused response.
2. The log object includes the file-log mixin, but the program constructs it with a null directory and this module contains no call to open a log file. The inspected implementation establishes an on-screen monitor; it does not by itself establish persistent Domain Server log generations.

A large earlier namespace-maintenance section in the same source file is inside a block comment and labels that maintenance unavailable. It is lineage evidence, not an active command surface.

Purpose and process relationship

Genera's File Server program observes NFILE/QFILE-family service activity, errors, and scheduled shutdown state. It uses the same shared server utilities as the network handlers. It is not a file browser, directory editor, or storage implementation; those layers are covered in File systems and file service.

One log object can be associated with each host being served. Server errors are retained with time, operation key, condition type/report, user, host, and protocol, then displayed in the error pane. The status pane currently redisplays only whether shutdown is scheduled and, if so, its time and message.

At shutdown time the implementation logs and broadcasts warnings, disables services, closes active file servers, waits for bounded cleanup, and leaves the status state clear. The schedule is therefore an operationally broad service action, not merely a frame-local timer.

Complete program surface

The source's direct Select & registration is commented out following a recorded UI review decision. The supported entry is Select Activity with argument File Server.

There are six source pane objects:

The manual's “five smaller panes” is consistent if the title strip is excluded. The source command table inherits Colon Full Command, Standard Arguments, Standard Scrolling, and Global.

The complete direct source command inventory is three:

Manual/source discrepancy

The installed File Server Activity Help lists five menu commands: the three above plus Set User Password and Remove User Password. A complete search of the inspected licensed source tree found no direct definitions of those two password commands. This does not prove the manual is stale: they may live in an omitted LMFS/access-control component or be generated elsewhere in a complete native world. It does prove that this Open Genera source distribution does not support a high-confidence claim that the five-item menu will appear. A configured runtime must resolve the discrepancy.

Public CADR inputs

The System 46 files are from Git commit 8e978d7d1704096a63edd4386a3b8326a2e584af:

The LM-3 files are from Fossil check-in 4df393c68d7f083ce42d5c377039d26043cc18a9031ace28258dc97f4137eb91:

Licensed Genera source inputs

The licensed source tree is anchored by opengenera2.tar.bz2, 206,213,430 bytes, SHA-256 89fb3e76b91d612834f565834dea950b603acf8f9dbacacdd0b1c3c284a2d36e. Paths below are portable within its og2 tree; no proprietary source text is reproduced here.

Installed Help inputs

Decoded text remained under the ignored Genera Help build tree. These source SAB objects identify the licensed inputs used for manual cross-checking: