feat: Provide a way to run multiple persistent user-supplied processes at startup

[theosanderson]

TLDR: Convert /data/boot.d so that every script is run in parallel in the background, rather than sequentially.

Background:

I think that https://github.com/theosanderson/OTWebControlprovides a decent example of a pattern for deploying a tool that sits on top of a (normal) OT2 but allows one to do some specific task that the OT2 can't do by default (in this case receiving user input during protocol execution). In this case deployment consists of a few basic commands that:

• clone a git repo
• copy a file to /data/boot.d that starts a server on startup

While developing this I actually wanted to have two servers which were modularly quite distinct (a basic SimpleHTTPServer server for downloading data from the robot, and a separate server hosting a terminal). Initially I did this by creating two files in /data/boot.d but I realised that one would not start until the other was complete and so this could never have the two servers running concurrently. In my case I was able to solve this by creating a Python script that launches the two servers in different threads.

But if one imagines the creation of an OT2 ecosystem, someone might want to install my tool, above, and also a completely different tool from someone else that also hosts a server. As far as I can see there is no easy way for those to be launched at startup and run concurrently (I think I tried a script with /bin/server1 &; /bin/server2 &; and couldn't make it work .

So the feature is to convert /data/boot.d so that every script is run in parallel in the background. (Or to provide an alternative folder with that functionality).

[sfoster1]

Gotta think about how best to implement this. boot scripts are kind of a crappy way of implementing it and the better way is probably systemd user scripts but I uh don't know how user friendly that is.

@theosanderson if you put systemd configuration in /var/home/.config/systemd/user/, which would consist of

• A systemd service unit
• A directory /var/home/.config/systemd/user/opentrons.target.wants that includes a symlink to your service

Then in theory that should run when the robot boots, and you'll be able to configure it as a full systemd service with all the power that implies (that certainly extends to having a service that runs in the background). The service could look something like this:

[Unit]
Description=Simple server for downloading files from the robot
After=basic.target

[Service]
Type=exec
ExecStart=/some/invocation

[Install]
WantedBy=opentrons.target

where you replace /some/invocation with the command to start your server, using absolute paths only.

[theosanderson]

Ah nice!

Yeah I was definitely aware that this pattern was pretty hacky - but didn't realise there was an alternative from a user-writable location. I'll give that a go and let you know how I get on. Thanks a lot for the support.

[sfoster1]

Ah nice!

Yeah I was definitely aware that this pattern was pretty hacky - but didn't realise there was an alternative from a user-writable location. I'll give that a go and let you know how I get on. Thanks a lot for the support.

If you wouldn't mind, let's keep this ticket open for now - your first point is entirely correct, something needs to change to make this easier. Whether that's documentation that explicitly calls out how to write systemd units, or whether it's a functionality change to the boot script runner, I definitely do want to make this experience better.

[theosanderson]

Perfect! I'm wasn't totally sure when I was going to get the chance to test this (definitely sometime) so didn't want to add noise for you - but great that you want it on your radar.