search

Opentrons / buildroot

The Opentrons fork of buildroot for building the OT2 system. Our default branch is opentrons-develop.
http://buildroot.org
Other
10 stars 7 forks source link

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

Open theosanderson opened 3 years ago

theosanderson commented 3 years ago

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:

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 commented 3 years ago

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

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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.