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