4 ms·
A few ideas come to mind: 1) Use systemd; I've taken the time to learn it and the tooling it exposes for codifying process dependencies, how weak or strong the
by Ixiaus 10y ago
A few ideas come to mind:
1) Use systemd; I've taken the time to learn it and the tooling it exposes for codifying process dependencies, how weak or strong they should be, and restart behaviors is thoroughly designed
2) Use Erlang/OTP - I went this route for an IoT product I worked on that used Erlang as the primary high-level "firmware", I codified the process tree and dependencies and custom supervisor restart behaviors for unix processes into Erlang/OTP's supervision tree; using Erlang process ports
The second approach has worked extremely well for me in the past but I would only recommend it if you're going to use a lot of Erlang to process output from the programs it spawns for you, which was the case for how I was using it at the time, the robust supervision of the processes it managed in a supervision tree was incidental to the primary use but extremely robust.
- tonyarkles 10y agoAny chance the 2nd one was Nerves-based?
- deleted 10y ago[deleted]
- Ixiaus 10y agoNo it was not, it was a home-rolled solution. Nerves is pretty neat but at the time I wrote our solution it wasn't as mature as it is these days. I rolled our own buildroot + erlang release + "firmware" deployment system (including the cloud infrastructure and software). Very fun project.
- tonyarkles 10y agoVery cool! I think the platform has a pile of potential for small devices, I just haven't had a project yet where I feel like I could justify the learning curve. Getting BEAM running on a beaglebone via Nerves was pretty neat, but led to a bit of a "ok cool, now what?" situation.
- andrewchambers 10y agoWriting a unix process supervisor system in erlang itself as a thin wrapper over OTP might be a fun project. Cool idea!