Orderly: Process (re)start, shutdown, and supervision
github.com
github.com
I also use it for grouping stuff together while developing multiple servers that depend on eachother, it is nice to be able to ctrl-c all of them and restart them together in the right order.
At first glance, it looks to have the desirable agnosticism of all other init systems besides systemd, but unlike sysv init or any others as far as I know (without going off to check them all righ now), it doesn't only provide pid 1.
One point seems to be to treat any tree like any other tree, so you use it to launch the bare metal like any other pid 1, but also use the same thing to launch a container or vm, or a mere service or application.
I don't know about systemd, but sysv init cannot run as anything but pid 1. It can launch any kind of child you want, but all trees below that must be managed by their own managers, like how httpd manages it's own collection of worker httpds, and each httpd has to manage it's cgi children.
With this, one of the things the pid 1 orderly could launch could be another orderly whose only job is to manage a set of httpds, and maybe each of those httpds could launch an orderly itself to manange a cgi environment. Heck a cgi script could launch an orderly itself for it's own internal reasons.
Almost every service is a manager of children. So this seems to be an attempt to abstract out and genericize the job of managing children, and being managed by a parent, and communicating status and intent in both directions. In the end, each branch in the tree can be anything from a simple process to the init of another entire system. The entire system part isn't the interesting one to me. That is just vms and containers which we already have. It's all the stuff in between that's interesting to me. All the trees that aren't init.
My guess is that this is good for microservices too.
In my work we have some developers who went and wrote software that requires several processes be started up and managed like you would normally do in an rc init script or systemd unit. They expect the host to provide this like other services, like say mysqld. But each individual customer needs their own set of these service processes to provide a db connection just for their data, as though each user had their own vm or container. IE, in order for user Y to log in and use the app, a set of user Y processes had to have already been started at boot. (don't ask me it wasn't me...) This would be one way that such an architecture could actually be provided. The host could have a sane service definition that doesn't know anything about individual users, it just says "start service foo". The foo service launches it's own orderly which has the (ever changing) list of users, and IT does "start customer X" "stop customer Y", start/stop all customers, etc.