Is this aimed at systems without intelligent init systems? I'm curious about the motivation. (What this provides seems to be available in systemd and upstart (and maybe others?) out of the box)
I think it's kind of aimed at containers, but it's also the obligatory Rust rewrite of init/runit. (And that is not necessarily a bad/useless thing, but there's of course years of development worth of functionality in other init-like software, so orderly has a long road ahead to catch up - if it wants to.)
Author here: I currently actually use it underneath runit to group processes that must live and die together. runit itself doesn't have good support for this sort of grouping.
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.
Yes obviously it is an init system, and so it has overlap with any other init system.
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.
I had a recent brush with Daemontools in an embedded setting. Anyone who's messed with qmail back in the day knows who DJB is and what this super minimal thing is. It seems to be good at managing a pile of inter-related services, keeping them running as long as the electrons keep coming, but I don't see the tree concept, or dependency management, in them. They do one thing really well and really tiny.
Yeah, runit is based off of daemontools, I consider orderly a good complement to daemontools/runit when you need some 'order'. In that setup daemontools would be the root of one or many trees.
