On Tue, Apr 11, 2017 at 03:35:54PM +0200, Svenja Otten wrote: > Am Wed, 5 Apr 2017 08:51:09 -0500 > schrieb "Serge E. Hallyn" <se...@hallyn.com>: > > > My guess would be that your new login is in a different cgroup from the > > old. The path 'user.slice/user-1000.slice' is relative to your current > > path. What does > > > > cgm getpidcgroupabs memory $$ > > > > show before and after logging back in? > > ok, I tried it out. > > Before logging out: > ------------------------------------------ > root@debian-test:~# cgm gettasks memory user.slice/user-1000.slice > 13099 > 13101 > 13102 > 13104 > 13105 > > root@debian-test:~# cgm getpidcgroupabs memory $$ > / > ------------------------------------------ > > After logging back in: > ------------------------------------------ > root@debian-test:~# cgm gettasks memory user.slice/user-1000.slice > call to cgmanager_get_tasks_sync failed: invalid request > > root@debian-test:~# cgm getpidcgroupabs memory $$ > /user.slice/user-0.slice > ------------------------------------------ > > But how how does it work after logging back in?
This is odd. Are you logging in the same way both times? how exactly are you logging in? (ssh, console, lightdm or the like?) As which user? Certainly user-0.slice seems wrong. You do seem to have multiple things installed at the same time which can upset each other. In the first email you showed 'cgget', which comes from libcgroup, and showed /etc/systemd/system/user-1000.slice.d/MemoryLimit.conf which comes from systemd. Note that if you are using systemd you should definately not be using cgmanager. Both will be trying to set up cgroups and will walk over each other. And libcgroup AFAIK is unmaintained for several years now. It existed before either systemd or cgmanager, so if it is set up to setup cgroups it will definately cause trouble.
