On Wed, 26.05.10 14:01, Tomasz Torcz (tomek@xxxxxxxxxxxxxx) wrote: > On Wed, May 26, 2010 at 01:26:48PM +0200, Lennart Poettering wrote: > > > The problem we've found is that cgroups are too aggressive. They don't have a > > > notion of sessions and count too much as being part of your service, so you end > > > up with your screen session being counted as part of gdm. > > > > > > The per-user cgroups are controlled via a PAM module. That way there's > > finally a nice way how we can reliably clean up behind a user when he logs out: > > we just kill his complete cgroup and he's gone. > > You are avoiding the question: what about screen sessions? Whole > point of screen is to stay after logout, and by killing cgroup you > nullify it. Well, that depends on configuration. Many admins will probably like it if they have an easy control that allows them to enforce that a user doesn't continue running processes after he is logged out. For example, in an university network it is probably a good idea to enforce something like that on workstation machines. And in other cases (i.e. central login servier) you might want to allow screen and suchlike, i.e. processes continuing to run after the user logged out. But then, when you delete a user you still want a nice way to kill all his processes. And in both cases you still might want to enforce resources limitations on the various users. Hence grouping user processes in proper cgroups is really useful, even if you ultimately don't enable the "kil user group on last logout" checkbox. So, the cgroups stuff allows you to do a lot of stuff we couldn't do before. But that doesn't mean all of it is useful in all cases. In systemd you can choose individually for each unit whether you want to allow it to continue run processes on shut down, whether you want the main process killed, the process group to be killed or the cgroup to be killed. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
