On Mon, 23.05.16 18:06, Mike Gulick (mike.gul...@mathworks.com) wrote: > > On 05/23/2016 06:07 AM, Lennart Poettering wrote: > >On Fri, 20.05.16 20:10, Mike Gulick (mike.gul...@mathworks.com) wrote: > > > >>Hi systemd-devel, > >> > >>I'm on Debian Jessie running the default systemd-215. I have a > >>daemon (running as root, controlled by systemd), whose job it is to > >>launch on-demand VNC servers for other users. Currently, this > >>daemon uses a shell command like the following to launch the vnc > >>server for a given $USER: > >> > >> sudo -i -u $USER /bin/sh -l -c 'cd \$HOME && /path/to/vncserver $ARGS > >> > >>The issue I'm having is that the user VNC sessions being created all > >>share the same systemd login session as my daemon. I can see this > >>by running systemd-cgls. > >My recommendation would be to define this as template service in > >systemd, and use PAM= to make sure the invoked binary gets a PAM > >session (and thus a logind session) assigned. > > I don't see PAM= documented anywhere, at least not in systemd.service(5). > Is this a new feature?
Sorry, I meant PAMName=. Execution parameters (and PAMName= is one) are documented on systemd.exec(5). > >>The users of these VNC sessions would like to be able to use > >>"systemd-run --user --scope -p MemoryLimit=X COMMAND" to launch a > >>command with cgroup-based resource limiting. However without a user > >>session, this results in "Failed to create bus connection: > >>Connection refused". > >Note that MemoryLimit= is not supported for user services, as cgroup > >controller delegation is generally not safe in the traditional cgroup > >hierarchy. > > > > That would explain why I wasn't able to get MemoryLimit to actually take > effect. I suppose one option is to pre-define a bunch of slices with the > required resource limits, and use --slice= with systemd-run. Hopefully > users will have the appropriate permissions to run processes attached to a > system-level slice. No they won't. They get their own hierarchy, below the host's hierarchy, and there's no concept to run anything outside of that. > As a side note, will cgroups-v2 allow this to work in the future? Yes. Delegation of controllers is safe on cgroups-v2. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
