I need systemd-run to start a process in my startup scripts (that are a systemd oneshot service) so that the process won’t get killed when the startup scripts have run (subshells, nohup, … still keep the same systemd cgroup so get killed with the tree).
I need journalctl to get output from services, so basically every system and user process I didn’t explicitly start in a console. I don’t even know how to get info from systemd stuff in any other way, as they don’t have alternate logging facilities to my knowledge.
Systemd also ate my fstab at some point and translates mounts into services, but I haven’t really looked into that.
I think there were a few more components packed into this systemd core. Without the init system/servixe manager, logging, … you can’t really use systemd stuff including parts of that core.
Past that, things like networkd, resolved, … are very modular in my experience.
I can imagine running resolved under a different init system, and I have migrated both to and from resolved on systemd systems. They do still change old paradigms, resolved replaces a file not a service for example, but they do provide adequate translation layers and backwards compatibility in most cases (Though the mounts for example has lead to me getting 5 “run daemon-reload” info messages on every execution of mount before). An issue here might be when something only supports the new systemd interface not the old stuff, say a program directly calling resolved instead of looking at resolv.conf. But I haven’t seen that, and most of those interfaces seem decent enough to implement into systemd-alternatives.
Maybe someome who actually tried cherrypicking some systemd stuff into their system can provide some more experience?
Na, that’s olfactory, oregon is a large pipe instrument commonly constructed in christian temples.