Quoting Cal Leeming [Simplicity Media Ltd] ([email protected]): > Also I tried to unset XDG_RUNTIME_DIR but it resulted in a new error (which > I believe is related to "sudo su" not placing into the correct cgroup) > > deploy$ lxc-start -n u1 > lxc_container: call to cgmanager_create_sync failed: invalid request > lxc_container: Failed to create hugetlb:u1 > lxc_container: Error creating cgroup hugetlb:u1 > lxc_container: failed creating cgroups
Right, you didn't have the rights to create your cgroup. As I expected based on your earlier email where you listed /proc/self/cgroup. > lxc_container: failed to spawn 'u1' > lxc_container: The container failed to start. > lxc_container: Additional information can be obtained by setting the > --logfile and --log-priority options. > > deploy$ declare -x XDG_RUNTIME_DIR="/run/user/999" > deploy$ lxc-start -n u1 > lxc-start: Permission denied - failed to create directory > '/run/user/999/lock/' > lxc-start: Error opening /tmp/1000/lxc//home/deploy/.local/share/lxc/u1 > lxc-start: Failed to create lxc_container > > Having to loop back using SSH feels really hacky, but I don't know enough > about LXC internals to submit a patch or suggest a cleaner workaround. You need a proper environment. Something with privilege needs to create your cgroup for you. You can do it yourself in advance with privilege by doing sudo cgm create all deploy sudo cgm chown all deploy $(id -u deploy) $(id -g deploy) and then do cgm movepid all deploy $$ after your sudo su. (And then you can set XDG_RUNTIME_DIR correctly by hand if you like) But if you want pam to do that with privilege after you authenticate, then you have to login somehow. > Should this be treated as a bug, or feature, or neither? I'm seeing it as neither at the moment. -serge _______________________________________________ lxc-users mailing list [email protected] http://lists.linuxcontainers.org/listinfo/lxc-users
