Tinkering
Come for the Foo, stay for the Bar


Evaluating a process manager

Posted on

Table of Contents:

At Flox1 we recently released a feature that we call "service management", which is essentially an analog to Docker Compose that runs processes instead of containers. In short, you define some services in your manifest and they get started as part of activating your environment with flox activate --start-services. When there are no more activations of this environment (i.e. you've closed all your shells that had activated the environment) the services are automatically cleaned up.

A simplified environment that starts a Postgres server looks like this:

version = 1

[install]
postgres.pkg-path = "postgres"

[services.postgres]
command = "postgres -D my_data_dir"

[options]
systems = ["aarch64-darwin", "x86_64-darwin", "aarch64-linux", "x86_64-linux"]

Pretty straightforward, right? What's not straightforward is wrangling a process manager to bend it to your will without losing your mind a little bit. What's the issue? Race conditions. Race conditions everywhere. Some of them in how you call the process manager, others inside the process manager itself.

Different process managers will be better or worse at certain tasks, and some will be missing features that you've decided that you really need. They may also just do different things because there's not a single correct answer.

As always, choosing one will come down to your particular needs and priorities. However, the unknown unknowns can make choosing pretty difficult. Having spent the last couple of months immersed in this, I've put together a list of topics to consider to help you get your due diligence done.

Shutdown

Starting services

Stopping processes

Restarting processes

Backgrounding

Client/server (assumes backgrounding)

Logs

Updates

Statuses

1

At Flox we're kind of shaking the Etch-A-Sketch on developer environments. Cross-platform, reproducible developer environments without containers so you get the best of both worlds: your tools and dependencies are the same from engineer to engineer, machine to machine, and you get to keep all the tools you love, configured the way you want. But, that's not the point of this post.


P.S. - You can follow me on Mastodon at @zmitchell for Rust, Nix, and lukewarm takes.

P.P.S. - If you notice that something could be more accessible, please reach out and I'll do my best to fix it!