Fire and forget option for the exec mixin

[richbai90]

The Problem

There are many times when it is useful to be able to keep a process running in the background. Currently the options for doing so are:

1. Push the command to the background using the & terminator
2. Use a tool like nohup or screen
3. Create a service file during the build phase

Each of these has some significant draw backs.

Option 1 doesn't work well with the exec schema. Specifying & as a suffix argument doesn't work because the underlying exec functionality doesn't recognize it as a terminator and passes it as an argument instead.

Option 2 requires 3rd party tools be installed either by modifying the docker file or creating a custom mixin. Screen also requires an interactive tty session to work correctly which isn't a flag set by the porter runtime.

Option 3 works but requires knowledge about the linux distro and how to write a service configuration file correctly. It's also a lot of work for something that could be very simple.

The Solution

Currently the porter runtime always waits for a response before executing the next step. Just in the same way that the Suppressible option works today, a RunAsync option could be implemented indicating that porter doesn't expect a response from this command. I already have a small code change implemented on my local clone that does this.

Other considerations

Allowing Porter to manage a process running in the background, while possible, opens a whole can of worms. Instead the runtime could return the PID of the process as an output so that other mixins can interact with it if necessary. From Porter's perspective, it has effectively disowned the process and transferred management of it to the author.

Modifying this behavior at the runtime level has the effect of enabling this functionality for any mixin that wants to make use of it, not just the exec mixin. Most mixins hook into the exec functionality anyways.

[carolynvs]

I never run bundles like that so do you mind if I ask some questions to better understand what you are doing in the bundle?

• What is the long running process doing? Is it something like docker-compose hosting a service for a bit while you perform the rest of the installation?
• Is the process running in the bundle's container or are you creating it via a ssh session on the target environment?
• How do the other mixins interact with that long running process? Do they need the PID or do they just need the service up and reachable?

Side note: We have a feature on our roadmap called mixins as bundles that will break up bundles and how they execute so that there won't be a single container that exists for the duration of the bundle's execution. Think each mixin will run with a shared mounted volume for data but do not run in the same container. So what you are relying on now, won't work without modification after that change is implemented.

It would be great to better understand what you are doing so that we can plan for that in the feature!

[carolynvs]

Very cool! 💯 Is this a public mixin that you'd be interested in listing in the porter mixins search results so that others could use it?

Is your socat mixin starting the socat process and then leaving it running so that the mixin can exit early and allow the bundle to continue executing? I'm just checking if that's a viable workaround for you or if you need a change in Porter now to get unblocked.

We could add a flag to the base exec mixin that would have porter not wait for the mixin to complete, but it would need to plan for that mixins as bundles feature that is upcoming. Most likely porter would need to allow bundle execute to continue immediately after starting the mixin (perhaps with a signal from the mixin to indicate when it's okay to continue?), and then if the mixin is still running when the bundle completes, stop the mixin.

[richbai90]

Right now the socat mixin relies on the change I made to porter to prove out the concept, but in general yes all it needs to do is execute and leave it running while allowing porter to continue on to other install steps.

[carolynvs]

Can you provide a link to what you did in Porter?

[richbai90]

https://github.com/richbai90/porter/pull/2/files

This PR is against the directory feature because I didn't want to lose that code as I'm utilizing it in my deployment I'm working on. These same changes can be made easily on another branch directly from the v1 branch though.

[richbai90]

I'm giving a shot to make the mixin compatible with the way things are done now. If it works I'll gladly publish it