support for systemd --user

[mrguitar]

Reading Major's blog post on quadlet use with FCOS makes me think we have room for improvement to add some sugar for systemd --user. This is a killer way to run unprivileged container workloads and it would be nice to support specific users and the more global, administrative /etc/systemd/user/ section.

Has this come up before, and if not do you think this is worth adding? Sure, it's mostly possible today using files: but I think the native systemd: section would make it a much better user experience.

I think for per user support something like this could work for the spec (this is just chicken scratch)
systemd-user

• user (string) user name (must be defined in the user section)
• linger (boolean)
• units (repeat the regular systemd section)

maybe if the individual user is left out, the global location could be used.

Thoughts?

[Nemric]

I did some work on that some month/years ago but after some tries and a new job I didn't continue to work on this subject but PR is still there !
You can see my work here coreos/ignition#1303 and the topic here coreos/ignition#1296
The main reason it has not been merged, I think, is because Systemd doesn't/didn't take care about presets when they are defined by early initialisation steps like ignition ... services are not started at all as far as I can remember

I'd like to "answer" to that link https://major.io/p/quadlets-replace-docker-compose/ you shared, to say that quadlet is not a replacement for compose but for "podman generate systemd"
That way, quadlet is a systemd generator that provide systemd units "on the fly" and then, is always up to date with podman/quadlet changes made from systemd and podman collaboration without having to generate or write Systemd service units any more

The dependencies (e.g. : [Install] WantedBy=caddy.service multi-user.target default.target) are the same as systemd's dependencies, finally, only [Container] section is different from a service unit.