<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi,<br>
<br>
I was able to work around the issue. There appear to be two reasons
why the polkit authentication agent can't find a user session.
First, no session can be created if /dev/tty0 doesn't exist as per
this code in systemd-204/src/login/logind.c manager_connect_console:<br>
<br>
if (access("/dev/tty0", F_OK) < 0) {<br>
m->console_active_fd = -1;<br>
return 0;<br>
}<br>
<br>
m->console_active_fd must be >= 0 for seat_can_multi_session
to return true. So I simply linked /dev/tty0 to lxc/console in my
container. Not sure this is the right thing to do but sessions are
now created...<br>
<br>
The second reason is related to this cgroup path duplication
business (as in /lxc/topaze/lxc/topaze/user...). To identify a
user's session, polkit calls sd_pid_get_session which eventually
ends up in cg_path_get_session with "/lxc/topaze/user/..." as the
cgroup path. First thing cg_path_get_session does is check if the
cgroup path starts with "/user" so it returns an error right there.
I gave up trying to understand where this path duplication comes
from. This small patch works around the polkit not finding a session
issue:<br>
<br>
--- systemd-204-5ubuntu20.16.orig/src/shared/cgroup-util.c<br>
+++ systemd-204-5ubuntu20.16/src/shared/cgroup-util.c<br>
@@ -1621,16 +1621,19 @@ _pure_ static const char *skip_label(con<br>
}<br>
<br>
int cg_path_get_user_unit(const char *path, char **unit) {<br>
- const char *e;<br>
+ const char *e, *user = NULL;<br>
+<br>
+ cg_get_user_path(&user);<br>
<br>
assert(path);<br>
assert(unit);<br>
+ assert(user);<br>
<br>
/* We always have to parse the path from the beginning as
unit<br>
* cgroups might have arbitrary child cgroups and we
shouldn't get<br>
* confused by those */<br>
<br>
- e = path_startswith(path, "/user/");<br>
+ e = path_startswith(path, user);<br>
if (!e)<br>
return -ENOENT;<br>
<br>
@@ -1705,12 +1708,15 @@ int cg_pid_get_machine_name(pid_t pid, c<br>
<br>
int cg_path_get_session(const char *path, char **session) {<br>
const char *e, *n;<br>
- char *s;<br>
+ char *s, *user = NULL;<br>
+<br>
+ cg_get_user_path(&user);<br>
<br>
assert(path);<br>
assert(session);<br>
+ assert(user);<br>
<br>
- e = path_startswith(path, "/user/");<br>
+ e = path_startswith(path, user);<br>
if (!e)<br>
return -ENOENT;<br>
<br>
@@ -1748,12 +1754,15 @@ int cg_pid_get_session(pid_t pid, char *<br>
<br>
int cg_path_get_owner_uid(const char *path, uid_t *uid) {<br>
const char *e, *n;<br>
- char *s;<br>
+ char *s, *user = NULL;<br>
+<br>
+ cg_get_user_path(&user);<br>
<br>
assert(path);<br>
assert(uid);<br>
+ assert(user);<br>
<br>
- e = path_startswith(path, "/user/");<br>
+ e = path_startswith(path, user);<br>
if (!e)<br>
return -ENOENT;<br>
<br>
Now, the next challenge is lightdm getting confused trying to do
VT_ACTIVATE when the screenlock kicks in:<br>
<br>
Error using VT_ACTIVATE 8 on /dev/console: Inappropriate ioctl for
device<br>
<br>
At this point my session is lost. If anyone has some insight here,
please share. In the mean time, no screen locking for me. :-)<br>
<br>
<br>
<div class="gmail_quote">Le 26 janvier 2016 11:10:08 HNE, Alain
St-Denis <a class="moz-txt-link-rfc2396E" href="mailto:alain@zenfolie.org"><alain@zenfolie.org></a> a écrit :
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex;
border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">
Le 2016-01-26 02:55, Serge Hallyn a écrit :
<blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> Quoting Alain St-Denis (<a class="moz-txt-link-abbreviated" href="mailto:alain@zenfolie.org">alain@zenfolie.org</a>):
<blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> Hi,
I experience the exact same problem. Similar setup (wily host, elementary freya container). No user session is created when I login the desktop so polkit won't grant elevated privileges.
In the container, /proc/1/cgroup shows:
10:cpu,cpuacct:/lxc/topaze
9:freezer:/lxc/topaze
8:devices:/lxc/topaze
7:memory:/lxc/topaze
6:cpuset:/lxc/topaze
5:net_cls,net_prio:/lxc/topaze
4:hugetlb:/lxc/topaze
3:perf_event:/lxc/topaze
2:blkio:/lxc/topaze
1:name=systemd:/lxc/topaze
In the container auth.log, I see those lines:
Jan 24 15:20:09 topaze systemd-logind[1739]: cgmanager: cgm_list_children for controller=systemd, cgroup_path=lxc/topaze/user failed: invalid request
Jan 24 15:20:09 topaze systemd-logind[1739]: New seat seat0.
Jan 24 15:20:09 topaze systemd-logind[1739]: Preallocating VTs...
Jan 24 15:20:09 topaze systemd-logind[1739]: systemd-logind running as pid 1739
Jan 24 15:20:11 topaze lightdm: pam_systemd(lightdm-greeter:session): Failed to create session: Invalid argument
The container runs cgproxy.
On the host, cgmanager reports:
jan 24 15:20:09 opale cgmanager[952]: cgmanager: Invalid path /run/cgmanager/fs/none,name=systemd//lxc/topaze/lxc/topaze/user (No such file or directory)
jan 24 15:20:09 opale cgmanager[952]: cgmanager:list_children_main: Could not determine the requested cgroup (systemd:lxc/topaze/user)
jan 24 15:20:09 opale cgmanager[952]: cgmanager: Error getting children for systemd:lxc/topaze/user for pid 2095
Does anybody have a hint on what causes this cgroup path duplication (lxc/topaze/lxc/topaze)? I suspect it may have something to do with the issue.
</blockquote>
I don't know what elementary freya is, but maybe this is a bug in the systemd
package there. Get the cgroxy logs (start it with --debug), and see what
calls are being made to it. Better yet strace the login process (maybe
start with the getty or sshd). If it is reading the cgroup path from
/proc/self/cgroup and then using cgmanager to movepid to something based on
that, that's wrong.
</blockquote>
Sorry, I should've provided more details. Elementary OS freya is based
on trusty. It's running with the same pieces of systemd 204-5ubuntu20.15
trusty runs.
cgproxy --debug only shows a message corresponding what is logged for
cgmanager on the host:
Connection from private client
ListChildren: Client fd is: 7 (pid=1722, uid=0, gid=0)
cgproxy:list_children_main: Server encountered an error: bad cgroup?
Disconnected from private client
I'm running the current lxc stable ppa in both the host and the container.
strace on lightdm does show /proc/1/cgroup being opened, but also shows
/proc/self/cgroup. BTW, being new to this list, what is the proper way
to attach large outputs?
Looking at /run/systemd/seats/seat0 in the container I see:
# This is private data. Do not parse.
IS_VTCONSOLE=1
CAN_MULTI_SESSION=0
CAN_TTY=1
CAN_GRAPHICAL=0
which doesn't look right. Something wrong with udev?
<hr>
lxc-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:lxc-users@lists.linuxcontainers.org">lxc-users@lists.linuxcontainers.org</a>
<a href="http://lists.linuxcontainers.org/listinfo/lxc-users">http://lists.linuxcontainers.org/listinfo/lxc-users</a></pre></blockquote></div>
</body></html>