On Thu, 11.07.13 23:20, Oleksii Shevchuk ([email protected]) wrote: > > > Yeah, you need to set some env vars currently. The idea however is that > > the X/dbus libraries learn to look into XDG_RUNTIME_DIR on their own. > > I tried to make it work without success -- result is unusable. So, one > of the issues - pam_systemd doesn't forward environment to child > process. Without that things like pam_gnome_keyring (probably) can work > only with awfull workarounds.
pam_gnome_keyring needs to be in the pam stack for "systemd-shared" of course. (BTW, I figure we should rename the PAM service before this gets widely adopted. "systemd-shared" is not helpful...) > > Nobody needs to wait for systemd --user exits. It will just exist in the > > background as long as the user is logged in and will go away as soon as > > he logs out entirely. It is refernce counted by the login sessions. > > Second one is absence of "following" mode or so. So here is the problem: > login manager forks Xsession initialization and terminates the greeter > (and session) when it exits. If daemon running in background, some > waiting mechainsm should be invented. And again, new environment should > be propagated to shared instance (and if session stops, should be > deinitialized). So, to migrate, either some new daemon should be written > to do all that stuff, or dm managers should be reworked. Which environment would that be? For sockets and suchlike relying on $XDG_RUNTIME_PATH should be sufficient. > Do we really need such complexity? > > Maybe old behavior can be offered as the option for those of us, who > really uses user session, at least till the moment, when mainstream will > be ready for migration? Well, you can still run systemd --user from inside the session if you chown the cgroupfs subtree first. > // Btw, there are some minor issues with proper > deinitialization|stopping -- PID 1 rests in timeouts while shutdown.. Can you elaborate? Where exactly does it hang? Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
