Skip to content

pman overview

Jennings Zhang edited this page Jan 19, 2021 · 21 revisions

Abstract

pman manages processes, i.e. programs or applications that are run by an underlying system. For the most part, these processes are command line applications (i.e. have no GUI) and usually do not interact really with a user at all. The purpose of pman is to act as a control system for other software agents. These agents can send pman instructions via http and pman will service these instructions. For example, an external agent can ask pman to start a process, and then after some time the same (or other) agent can ask pman for information about that process. In the simplest case, pman is given some string text that is the command line of the program to run on an underlying system shell.

Roadmap

Originally, pman was designed to track simple processes executed on the local system. In addition, pman keeps a record of the current and historical state of processes that it has executed and is thus able to respond to queries about the processes. Some of the queries that pman can address are

  • state: Is job still running?
  • result: What is the stdout (or stderr) from job ?
  • control: Kill job

pman also maintains a persistent human-readable/friendly database-in-the-filesystem of jobs and states of jobs.

Current versions of pman however can use container-based backends (swarm and openshift) to execute processes. In those cases, the internal database of tracking jobs becomes superfluous. Future versions of pman might depreciate the local/internal DB tracking.

Installation / setup

See the main page here.

Startup

See the startup docs here.

Flags

  • --ip <W.X.Y.Z>

(string): IP of service. If not specified, will self-discover host IP. To limit communication only to and from localhost, set this to localhost.

  • --port <WXYZ>

(string): The port on which to listen. Defaults to 5010.

  • --protocol <protocol>

(string): The protocol to use. Defaults to tcp.

  • --rawmode <level>

(string): The router raw mode. Defaults to '1'.

  • --listeners <number>

(string): The number of listener threads. Defaults to '1'.

  • --http

(bool): If true, send replies in HTTP layer.

  • --debugToFile

(bool): If true, stream debugging info to file.

  • `--debugFile

(string): In conjunction with --debugToFile, stream debugging info to specified file.

  • --listenerSleep <W.XYZ>

(string): A delay in each listener loop to prevent busy-wait. Defaults to 0.1.

Running

To run a process, see here.

Searching for a process

To search for a process, see here.

DataBase

pman maintains a human-friendly/readable database of jobs and history, typically in the /tmp/pman directory of the machine on which it is run.

REST-like!

REST purists will note that communicating with pman is not pure REST, but rather REST-like. For example, querying pman is almost always done with POST requests as opposed to using GET verbs. The reason for this is partially historical and partially expedience. Information between the server and client is communicated in a JSON message payload and not really the http URL.

Since translating the current packet/payload scheme into URL type format should be straightforward, future versions of pman are projected to be more fully REST compliant.

Having said that, pman does service GET requests, and the URL defines a location in the database space. In this model, there is a one-to-one correspondence between the URL data location and the data base as represented in the filesystem.

--30--