On Tue, 2013-11-26 at 09:53 +0000, Colin Guthrie wrote: > Colin W's later patch did implement these semantics for the root user's > XDG_RUNTIME_DIR. It kept it around and didn't tidy it up. Doesn't this > solve the problem for the root user nicely (which is the primary problem)?
Yes, I run "pkexec" to root every day, and would like if code that ran as root could just assume it was there. I may look at rebasing my patch on top of master again as a followup. > But regardless, why doesn't this code create the dirs if they don't > exist anyway? Sure, this doesn't deal with lifetime problem (i.e. > knowing when to delete the dirs again) Because the lifetime problem is important; daemons and the like use it to implement "run only once" semantics. At least if it's unset your daemon can say "Sorry" and abort. If we cleaned it up while the daemon was running, you could get two, and that could lead to data loss. > Could logind not learn to track these "nested-mini-sessions"? I think so, but: > Perhaps it is a problem tracking when one of these nested sessions > actually logs out? Or perhaps the a problem would be doing something > like su[mini-session]+screen+detatch+logout[mini-session]? The > mini-session would be closed and the runtime dir cleaned up even tho' > processes in screen were still needing it. Exactly. If we were going to claim to provide XDG_RUNTIME_DIR in these types of scenarios, we need to avoid it being cleaned up too early. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
