Deployment#
Similar to Docker, PyroLab uses a single daemon process running in the background to manage all the processes. This daemon is started automatically when the first process is created.
Pyro5 is again utilized to run and communicate with PyroLab’s daemon.
The PyroLab Daemon should be configured to run as a given user. This is because PyroLab creates data and configuration file directories under the user’s home directory, instead of using obscure system directories that are OS-specific. Whether configured as a Windows Task or a Linux cron job, PyroLab will attempt to create these directories and files as the user that is running.
PyroLab can be configured to automatically launch at startup. The process is different based on operating system.
Operating Systems#
Windows#
Write a batch file (or use the one located in pyrolab/bin/pyrolab.bat) that launches PyroLab. Depending on whether you’re using a base python or conda for your environment, you may need to activate environments accordingly.
Note that in the example file provided, the “–force” option is used. We assume this script will only be run on startup, therefore even if the application did not clean up properly, we can be guaranteed that it isn’t already running and overwriting the lockfile is safe. Be aware that this is what’s happening if you decide to debug your batch file; you may be creating a bunch of orphaned processes!
Once the batch file is written, you have two options. You can configure Windows to run the file as a task on a schedule (in our case, on startup), which should in theory work even if no one logs in to the computer, but it is simply restarted. This is nice in a lab, if you’re not actually using the computer hosting various PyroLab services; you can just start the computer by pressing the power button and not worry about logging in on each computer that hosts a service you need. For example, many of our computers run “headless,” without a monitor attached, and it would be a hassle to remote into every machine after startup just to login. The second option is to place the .bat file in the Startup folder. These only get launched on login, however. Instructions for both methods are included below.
Using the Task Scheduler#
Open the Windows Task Scheduler.
Create a new basic task.
Name it something recognizable, like “pyrolabd”. Optionally, add a description.
Set the trigger time to “When the computer starts”.
Set the action to “Start a program”.
Find the batch file location, place that in “Program/script”.
Select “Open the Properties dialog…” before clicking Finish, or open the Properties dialog manually by selecting it from the list of scheduled tasks.
Under “General”, ensure that it’s running under some User’s account.
Additionally, select, “Run whether user is logged on or not” (note: do NOT select “Do not store password.”).
Select “Run with highest privileges”.
Under “Conditions”, deselect all (for example, we always want the task to start, regardless of battery state or the computer being idle).
Under “Settings”, select “Allow task to be run on demand”, “Run task as soon as possible after a scheduled start is missed”, and “If the running task does not end when requested, force it to stop”.
Using the Startup folder#
Press the Windows+R key to open the run dialog.
Type “shell:startup” and press Enter.
Right click in the folder and select “New”.
Click “Shortcut”.
Type the location of the batch file, or browse to it.
Click “Next”.
Type a name for the shortcut (such as “pyrolabd”), and click “Finish”.
Linux and macOS#
We recommend using crontab on MacOS as well. You’ll want to write an executable
script that activates whatever necessary environments you have, if PyroLab
isn’t installed in the global Python interpreter (which, for the record is
usually a bad idea). Here’s an example autolaunch.sh:
source env/bin/activate
pyrolab up
Then you’ll register it with cron to run it, for example, on startup. To launch cron:
sudo crontab -e
Then enter a line similar to the one below:
@reboot /path/to/autolaunch.sh
Starting the Daemon#
PyroLab has a constantly-running daemon process in the background that monitors Pyro services and awaits user commands via the command line interface (CLI). The CLI is really just a glorified client; the PyroLab daemon is listening on some localhost port, and the CLI simply sends commands to the daemon. The CLI is not the instance of PyroLab that is actually managing what would be considered the “PyroLab program.”
Launching from the command line#
To start the daemon, simply run the following command:
pyrolab up
If PyroLab has been configured with a user-defined file, the daemon will
automatically load that configuration. (This does not imply that all the
listed services will be started; for that to happen, they must be listed in
the autolaunch section of the configuration file.)
Force launching the daemon#
PyroLab does its very best to ensure that only one instance of the background daemon is running. It creates a lockfile when it’s started, and no other instances can be created if that lockfile exists. Anytime the daemon is shut down, the lockfile is deleted.
The reason there should only be one instance of PyroLab should be obvious; if there are subsequent instances started, all prior instances will in effect be “orphaned;” PyroLab will have no knowledge of their existence, and they’ll continue on, hogging resources (and potentially blocking access to hardware devices or other single-access resources), unable to be shutdown by PyroLab. PyroLab therefore only allows one instance to be started.
There may be, however, rare instances where an error occurs, so egregious that Python terminates immediately, without getting a chance to run the “cleanup” code. In such cases, PyroLab may think that an instance is running when it really isn’t. Formerly, you had to coerce the CLI to restart with a “force” option; however, in the spirit of, “if it’s not responding, launch a new one,” that option is now the default behavior. By default, an existing lockfile is simply overwritten, causing the daemon to “forget” about any previously running instances. If you’re suspicious that there are extra Python processes running in the background, you should check your OS’s process manager (Task Manager on Windows, Activity Monitor on Mac OS, etc.) to determine whether there are any orphaned processes that you need to kill manually.
You might consider making sure that your process has actually died before forcing a new one to launch. On Windows, you can simply reference the Task Manager. On *nix based systems, you can follow the instructions below.
Where did my instances go?#
PyroLab runs a daemon in the background that monitor and spawns all daemon servers as their own process. If you’re concerned the master daemon was orphaned, you should be able to find all background pyrolab daemons by running (on *nix):
ps aux | grep pyrolabd