On Wed, 2013-11-20 at 10:16 +0000, Colin Guthrie wrote: > How do we fix this?
There are a lot of cases - "screen" is just one of them. I think to make forward progress on this we'll have to enumerate the cases, evaluate the problems with each, then for each problem, evaluate a fix - and make sure that fix doesn't regress one of the other cases. Fun! =) One very important thing that's in the mix here is the user@.service future. It helps us move forcefully away from the old model of independent sessions, a direction we've been going incrementally via additions of things like XDG_RUNTIME_DIR (and then higher level things on top like a per-user bus instead of per-session). Cron for example could be spawned from user@service. > But in the case of screen I'm specifically asking for a new, stand alone > session. I'd agree; but the fix would be fairly invasive for screen. I think it'd have to become setuid root, so it could request a new session. > Perhaps this is all OK, and the "closing" state here is not a problem. > But such apps and use cases really are not compatible at all with the > kill-session-processes= option of pam_systemd and it would be nice to do > things properly. I believe that option is not the default precisely because of screen. But anyways...we have to take some level of incrementalism here. Martin's patch is a very small and correct fix for a real-world problem. My patch is a bit more invasive, but I think it's going closer to the root of the problem. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel