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