[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.

[nybble41]

> I've been doing fine on Debian dropping files in /etc/systemd, with a possible hook to `systemctl enable`.

Don't forget `systemctl daemon-reload` to update the in-memory state when the unit files change. The `edit` command takes care of that for you. It also provides a template for the override files (when not using `--full`) which shows the current settings.

You are free to just drop files in /etc/systemd, of course. This is a fully-supported workflow. The `edit` command is only there for the convenience of the system administrator.

> A rudimentary ad-hoc object system with overrides etc for every program is like the exact opposite of what I want when doing sysadmin.

Are we talking about systemd, or NixOS? Their approaches to configuration really aren't all that different in this regard but you still seem to prefer one over the other. Or is the problem perhaps that you have two different programs trying to manage the configuration?

Personally, from the POV of distributions other than NixOS, I think the systemd approach is far superior to alternatives without overrides, where the only choice is to clone & modify the vendor-provided scripts. With overrides you can fine-tune the parts that matter for your environment without taking over the maintenance of the entire script (or unit file). For example, it's more likely to keep working after an upgrade.

[mindslight]

I was talking about systemd. It's each program having its own bespoke template/include/.d/override system that is the problem. Whereas NixOS is intended to be used for every program.

Personally I'd rather clone and modify a full config file rather than only overriding portions. Once I own it, I want to keep owning it - it's more straightforward to track down a problem due to my own assumptions being invalidated, than due to a distribution's assumptions being invalidated. And it's much nicer to read one file for the settings, than having to jump between a few different ones and know the overriding rules (referring to configuration in general here, not just systemd which provides the tools to work with them).

Good point about the daemon-reload. I actually don't have many custom systemd unit files, and they generally don't change. But to be fully correct and not require manual intervention or a full reboot I do need to include that step (although I'm moving away from Debian towards NixOS so shrug).