[mindslight]

NixOS is based on systemd. But it also seems like NixOS would be a great foundation to use something besides systemd. It would take some work of course, but it feels like you'd be mostly working with the OS rather than fighting it.

However having used it, NixOS seems like it mitigates the worst aspects of systemd. It gets rid of that that /etc/systemd /lib/systemd symlink "cleverness" for overriding/enabling units. Being functional makes it so that when systemd mysteriously breaks - for example if there is a loop in dependencies - it's easy to track down the change that caused it. And rather than splaying the config out in a bunch of random "unit" files, it's all contained in the nix config. About the worst thing I can say is that defining your own service is a bit more obtuse that it needs to be, with the arbitrary terms of the systemd unit format carrying over into the Nix config.

[md8z]

The symlinking is one of the things systemd actually gets right on traditional distros. The files in /usr/lib are immutable data files shipped by the packages that you're not supposed to edit. The symlinks to them in /etc are configuration that you can change.

[mindslight]

I get the rationale. it just makes for one more layer of indirection that you have to overcome when trying to figure out what the configuration actually looks like.

[md8z]

Well I think you are supposed to just use systemctl to see what the configuration looks like.

[5e92cb50239222b]

Why would you do this manually? You also have to remember to check multiple configuration paths (e.g. override units), all of which can have an additional `.d` include directory. This is the price you pay for the flexibility systemd provides (and I argue it's much better than random System V-style shell scripts that can include anything at all, maybe even some remote scripts piped from curl to sh if developers was mad enough).

Just use `systemctl cat`, it prints the whole effective configuration.

[mindslight]

Does `systemctl cat` also work for creating/editing units? If I've got to navigate files and directories configure the thing, then I am going to default to reading the configuration the same way. Having to find out these random commands to view simple things about its own internal model is one of the the worst parts of systemd.

I'm no fan of SysV init either, and I appreciate the advancements that systemd does bring to the table. But it is hard to shake the feeling of it having done the system software equivalent of sucking in a bunch of bloated javascript frameworks. Sure they made life easier for the developer, but everyone else has to live with the mess.

For enabling/sequencing, I'd say the preferable way would be to have a top level config file that pulls in the specified units explicitly rather than stitching together units based on their internal contents (akin to persistent structure rather than mutable cells). Juxtaposition is the most syntactically powerful operator and prevents loops intrinsically. Whereas by splaying dependencies in unit files, if you make one errant backreference the system is likely to not boot at all. I'm sure there's another clever command to check for that, but shrug.

[nybble41]

> Does `systemctl cat` also work for creating/editing units?

No, for that you would use `systemctl edit UNIT...` to create or edit a drop-in file, e.g. to add local overrides for an existing service, or `systemctl edit --full UNIT...` to open a copy of the existing unit file for editing which will replace the packaged version. Add `--force` to create a new unit file for a service which doesn't already exist.

[mindslight]

I'm not surprised there is functionality like this, but I do question the value in learning it. After you've given up on the filesystem, you've got to figure out how to eg automate it. Some things you're forced to (virsh, crontab, etc), but that's not a selling point.

I've been doing fine on Debian dropping files in /etc/systemd, with a possible hook to `systemctl enable`. A rudimentary ad-hoc object system with overrides etc for every program is like the exact opposite of what I want when doing sysadmin. I think NixOS's approach does a good job of coping with systemd, in that it bundles all that complexity up in a way so it doesn't propagate, despite still having to look up what the Wants/Needs/Likes/Prayers/Requires/Binds designations mean every time I touch the config.

[rnhmjoj]

It is indeed possible, in fact a Nix-based project to generate and manage init/OS-agnostic services was shown last year at NixCon: https://github.com/svanderburg/nix-processmgmt