How to deal with systemd services?

[Kyuuhachi]

Sure, I can create the links with CreateLnk /etc/systemd/... /usr/lib/systemd/..., but this is unappealing for a number of reasons:

• It's verbose. Many services have multiple links and thus multiple lines, not to mention that the lines themselves are quite long.
• It's imperative. It tells the process (create links), not the goal (enable services).
• It's inexact. Enabling a service with systemctl creates exactly the right set of links, doing it explicitly is easy to get wrong.
• It's messy. It's often hard to tell which lines belong to which service.

The four above points can be lessened by enabling them with systemctl and then finding the link set via aconfmgr save (or just copying from the log output), but that method is also unappealing. There is also another, less important point:

• It's non-live. Copying the files is equal to systemctl enable, but not systemctl enable --now.

If I do aconfmgr apply, I would like as much as possible of the config to be applied immediately, not on next reboot. I don't think aconfmgr does this for any other tasks however, so it's probably out of scope. Printing a notice to remind to start/stop services might be nice however.

Regardless of the last point, it would be very nice to be able to simply specify which services are to be enabled and have that handled. I unfortunately don't know enough about systemd to know if there is any way to know which links should be added; does anyone else have any knowledge on this point?

[CyberShadow]

One approach would be to wrap the logic in a function, and refactor CreateLink etc. lines to calls to that function. (However, there is currently no mechanism to make aconfmgr save to emit calls to such functions.)

It's inexact. Enabling a service with systemctl creates exactly the right set of links, doing it explicitly is easy to get wrong.

A pedantic note here - if a systemd unit is enabled, and then later its [Install] section changes (meaning, the set of links that systemd enable would create changes), then the system configuration will not be updated to the new set of links. The user would need to disable/enable it explicitly. So, if aconfmgr was to save only that the unit was enabled, then re-applying the generated aconfmgr configuration may not produce the same system configuration. As such, the exact set of links actually represents the current system configuration more accurately than the intent of the unit being enabled.

It's non-live. Copying the files is equal to systemctl enable, but not systemctl enable --now.

A pedantic note here - if a service on the current system is for whatever reason enabled but not running (and maybe also the other way around), in order to preserve aconfmgr's idempotence invariants, the two states (enabled/running) would need to either be representable separately, or aconfmgr apply would need to normalize towards a consistent state (i.e. making the running/stopped state match the enabled/disabled state, whether always or on change).

[Kyuuhachi]

One approach would be to wrap the logic in a function, and refactor CreateLink etc. lines to calls to that function.

Yeah, that's what I'm doing right now. Not very elegant, but better than the raw CreateLink calls.

SystemdLink() { CreateLink "/etc/systemd/system/$1" "/usr/lib/systemd/system/${1:-$(basename $1))"; }
SystemdLinkUser() { CreateLink "/etc/systemd/user/$1" "/usr/lib/systemd/user/${1:-$(basename $1))"; }

Good points about "enabled" not being an exact state description. With that in mind, slightly sugared raw symlinks is probably the best one can get.