Hacker News Reader

Comment by zozbot234 | Hacker News Reader

...so, how does a systemd unit definition differ from a Makefile (other than using a different syntax, obviously)? What features would you need to add to UNIX make (and PID 1, for that matter) in order to be able to separate out this whole dependency management business from the other stuff PID 1 has to deal with already?

View on HN

For one thing make is imperative and doesn't actually know what it's doing. Systemd is declarative. You'd need to replace all the options service files give you.

Make doesn't do dependencies between unrelated projects. A makefile can't say "I want to run if X runs, but I should run before them".

Make doesn't have supervision, you'd need some kind of declaratively configured poller.

Systemd is also parallel, there's probably some complexity there that make might or might not handle well.

I think the most important problems would only be obvious once you started using a replacement system though. Systemd almost totally replaces the need for any imperative code whatsoever for process autostart, configuration, and supervision, and that might be hard to do in a more modular setup.

You don't need extra stuff besides the service file. Everything is extremely consistent and done the same way for every service.

Everything statement that comment makes about make is incorrect, except the bit about polling.

Polling is better-addressed by having each service implement its own error handling. Restart loops are the wrong policy for most services. In the rare cases where they are actually the correct behavior, they’re trivial for the service author to implement.

Those that don’t understand make are doomed to reimplement it poorly.

How are restart loops the wrong policy? If it should be running, and it's not, how else would I fix it except by restarting it?

They're not exactly trivial. There's restart delay, number of times to restart, passing stdout through so the journal can get it, and there's failure reporting.

How is PID 1 supposed to know if my service failed when the restart daemon is still up and running, but my actual app keeps crashing? How can it tell the difference between my app and a supervisor, or a fully failed app or just one failed subprocess that my app can handle? Now you need some scheme for that.

If PID1 doesn't know what's failed, how would I get a list of all failed systems programmatically?

Systemd could provide a standard supervisor component, but then it couldn't ever do anything but restart failed apps, or you're back to people complaining about monoliths.

You'd have to have your service file explicitly call it with some command line args making your syntax uglier.

And more importantly, it might be harder for the systemd dev team because now they have a communication protocol between this restart daemon and everything else.

Or they could leave restart daemons up to the user... and everyone would probably choose 3 different ones, that might or might not keep up with compatibility. That would break the "One and only one obvious way" principle.

When you start splitting stuff up in tiny bits, you get more overhead, all the extra nice features seem to evaporate.

To pick just a small piece of the pie:

Dependencies in make are equivalent to systemd's Requires= and After= combined. Systemd is far more general in this regard, both in that Requires= and After= are separate concepts, but also in that there is Wants=, BindsTo=, etc. and their inverses (RequiredBy=, Before=, etc.). Sometimes when I'm writing Makefiles I wish Make were capable of expressing some of these concepts.

My devuan linux desktop says something like this on each boot:

INIT: version 2.88 booting

Using makefile-style concurrent boot in runlevel S.

I've tried Devuan once then it some roadblock because Docker wouldn't run easily on it, but that was a long time ago.

I may try it again one of these days now that the latest Devuan stable is based on Debian Bullseye.

The "why" is simple: to restore some balance in the force.

I do prefer my Linux world to be one where I still have a choice as to which init system and PID 1 my system is running.

you could at least give openrc a go.

Devuan has its own problems with its image and communication:

https://lwn.net/Articles/786593/

It's not even the immaturity of the joke that bothered me back then, but that the response to the criticism was to imply that it is "corporate bullshit" and/or "giving up on having fun".

Reply on news.ycombinator.com