-
Notifications
You must be signed in to change notification settings - Fork 70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
support for systemd --user #493
Comments
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 ! 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" 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. |
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
maybe if the individual user is left out, the global location could be used.
Thoughts?
The text was updated successfully, but these errors were encountered: