(Note
that this means systemd --user will only work when run from
user@.service, as access to the cgroup tree is *not* granted for normal
sessions directly.)
So, how sessions should work now? Before that I started systemd --user
as main session process, and when it exited, session exited too.
Ok. I trying to use current git. Nothing works for me. I.e. systemd --user
starts, but I couldn't connect to it, because it doesn't connect to
d-bus (because dbus socket doesn't exists and systemd doesn't start dbus.socket
probably). systemd starts X services, but they couldn't establish X
On Wed, 10.07.13 20:07, Kok, Auke-jan H (auke-jan.h@intel.com) wrote:
+r = cg_path_get_owner_uid(path, uid);
+if (r 0 r != -ENOENT)
+return r;
+
+if (uid != (uid_t) -1)
+chown(fs, uid, (gid_t) -1);
+
systemd in git will now
On Thu, 11.07.13 07:41, Oleksii Shevchuk (alx...@gmail.com) wrote:
(Note
that this means systemd --user will only work when run from
user@.service, as access to the cgroup tree is *not* granted for normal
sessions directly.)
So, how sessions should work now? Before that I started
On Thu, 11.07.13 09:40, Oleksii Shevchuk (alx...@gmail.com) wrote:
Ok. I trying to use current git. Nothing works for me. I.e. systemd --user
starts, but I couldn't connect to it, because it doesn't connect to
d-bus (because dbus socket doesn't exists and systemd doesn't start
dbus.socket
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
On Thu, 11.07.13 23:20, Oleksii Shevchuk (alx...@gmail.com) 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
On Thu, 11.07.13 23:56, Oleksii Shevchuk (alx...@gmail.com) wrote:
pam_gnome_keyring needs to be in the pam stack for systemd-shared of
course.
pam_gnome_keyring needs authinfo to unlock login keychain. Will that be
passed to new systemd instance?
Well, hmm, I am not sure how
On Sat, 06.07.13 01:16, Marc-Antoine Perennou (marc-anto...@perennou.com) wrote:
When creating the cgroup hierarchy for a user slice,
chown this slice to the user uid.
Signed-off-by: Marc-Antoine Perennou marc-anto...@perennou.com
---
src/shared/cgroup-label.c | 8
1 file
On Wed, Jul 10, 2013 at 5:48 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Sat, 06.07.13 01:16, Marc-Antoine Perennou (marc-anto...@perennou.com)
wrote:
When creating the cgroup hierarchy for a user slice,
chown this slice to the user uid.
Signed-off-by: Marc-Antoine Perennou
When creating the cgroup hierarchy for a user slice,
chown this slice to the user uid.
Signed-off-by: Marc-Antoine Perennou marc-anto...@perennou.com
---
src/shared/cgroup-label.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/shared/cgroup-label.c b/src/shared/cgroup-label.c
11 matches
Mail list logo
