I have found myself referring these fairly regularly while working on Beah.
Would it be a good idea to put this in the beah developer guide?
I can't promise that it will be any better than it is as below.
During a test run, several Beah components interact over TCP/IP
within
the system itself.
Beah local servers
==================
When you login to a test system (say, when "reservesys" is running), you will
see that
the following Beah specific servers listening:
beah-srv 9353 root 10u IPv4 28367 0t0 TCP *:12432 (LISTEN)
beah-srv 9353 root 11u IPv6 28368 0t0 TCP localhost:12432
(LISTEN)
beah-srv 9353 root 13u IPv4 28370 0t0 TCP *:12434 (LISTEN)
beah-srv 9353 root 14u IPv6 30919 0t0 TCP localhost:12434
(LISTEN)
beah-rhts 10898 root 7u IPv4 31905 0t0 TCP localhost:7085
(LISTEN)
beah-rhts 10898 root 11u IPv6 31906 0t0 TCP localhost:7085
(LISTEN)
Note that this is the IPv6 capable harness that we plan to release soon and
hence each
of the servers are listening on both IPv4 and IPv6 interfaces.
The 'beah-srv' process corresponds to the function "start_server" in
beah/wires/internals/twserver.py
and it basically starts the TaskListener and BackendListener, whose presence
you can usually see in
the console logs:
2014-01-29 00:55:48,719 beah start_server: INFO Controller: BackendListener
listening on 127.0.0.1:12432
2014-01-29 00:55:48,720 beah start_server: INFO Controller: BackendListener
listening on ::1:12432
2014-01-29 00:55:48,720 beah start_server: INFO Controller: BackendListener
listening on /var/beah/backend12432.socket
2014-01-29 00:55:48,722 beah start_server: INFO Controller: TaskListener
listening on 127.0.0.1:12434
2014-01-29 00:55:48,723 beah start_server: INFO Controller: TaskListener
listening on ::1:12434
2014-01-29 00:55:48,723 beah start_server: INFO Controller: TaskListener
listening on /var/beah/task12434.socket
These servers exist throughout a recipe run on the test system. The
corresponding "client" programs live
in beah/wires/internals/twbackend.py and beah/wires/internals/twtask.py.
The beah-rhts-task (beah/tasks/rhts_xmlrpc.py:main()) starts a server *per
task*, it is the
result server and exits on a task completion.
Beah daemons
============
The following beah daemons are started at system boot:
beah-fwd-backend
================
This handles the communication during multi host jobs.
Source: beah/beaker/backends/forwarder.py
beah-beaker-backend
===================
Talks to the lab controller's beaker-proxy process over XML-RPC.
Source: beah/beaker/backends/beakerlc.py
beah-srv
========
Main daemon process we saw above.
Source: beah/bin/srv.py
As you can see from the following status, the beah-rhts-task is spawned by
beah-srv:
# systemctl status beah-srv
beah-srv.service - The Beaker Harness server.
Loaded: loaded (/usr/lib/systemd/system/beah-srv.service; enabled)
Active: active (running) since Wed 2014-01-29 00:55:47 EST; 20min ago
Main PID: 9353 (beah-srv)
CGroup: /system.slice/beah-srv.service
├─ 9353 /usr/bin/python /usr/bin/beah-srv
└─10898 /usr/bin/python /usr/bin/beah-rhts-task