On Fri, 10 Oct 2014 16:19:51 +0200 Marcin Szewczyk
<marcin.szewc...@wodny.org> wrote:
> I have done almost exactly the same research yesterday evening.
>
> On Thu, Oct 09, 2014 at 09:16:07PM +0100, OmegaPhil wrote:
> > It looks like polkit has a hard dependency on systemd as init
currently
> > - the 'session' being sought goes through
> >
src/polkit/polkit/polkitunixsession-systemd.c:polkit_unix_session_initable_init,
> > which then calls into sd_pid_get_session from the libsystemd0
package.
> > This uses the PID of the pkcheck-calling process to read the proc
file
> > '/proc/<pid>/cgroup' - it looks for a line containing 'systemd',
and
> > then extracts the 'path', the bit at the end, to get at the
session.
>
> It bothers me a bit. As I see this logind has its internal list of
> sessions in its memory. On the other hand there is a hierarchy in
> /sys/fs/cgroup/systemd which (using some specially formatted names)
> codes session names. What happens if they desynchronize (for example
> when the logind daemon dies)?
There is also /run/systemd/{seats,users,sessions}. I suspect these
directories are to allow internal state to be recovered in case of a
crash, you know? Not sure though.
>
> > On my current session, every single process has '/' as this path -
in
> >
libsystemd0/systemd-215/src/shared/cgroup-util.c:cg_path_get_session
> > line 1320, this path is explicitly rejected - its checked for and
> > '-ENOENT' is returned.
>
> Same here.
Are you sure you have cgmanager running? Maybe the sysvinit script has
some problems; I am using Upstart al momento so maybe that is it.
>
> > Under a systemd-as-init system, a valid example of a path would be
> > '/user.slice/user-1000.slice/session-1.scope'.
>
> I have done an experiment:
> /sys/fs/cgroup/systemd/user.slice/user-1000.slice/session-1.scope
> echo SHELLPID >
/sys/fs/cgroup/systemd/user.slice/user-1000.slice/session-1.scope/tasks
>
> Calls to polkit from that shell started working again.
>
> After adding all the gvfs processes to that cgroup (using pgrep and
echo
> to tasks) I was able to mount a USB drive.
>
> > So far I haven't seen logind factor in here.
>
> The question is: who is responsible for adding my X11 process during
its
> startup to that specially named cgroup?
>
> There are so many actors. pid eins, cgmanager, logind, lightdm, X11
> scripts in /etc/X11, polkit, consolekit and PAM session modules (for
> both consolekit and systemd).
On sysvinit and Upstart, PID1 has nothing to do with this situation. On
systemd, systemd puts the session init process into a cgroup.
systemd-shim offers systemd's D-Bus interface and implements the
cgroups bits (which logind is concerned with) through cgmanager. Can
you tell me what your cgmanager version is?
Basically the flow is:
PAM module for logind calls the logind CreateSession() method
logind calls the systemd cgroup slice creation methods (delivered to
systemd-shim)
systemd-shim calls the cgmanager cgroup methods, and the session init
process is then put into the appropiate cgroup
I have this stuff working, and my /proc/$$/cgroup looks like so:
11:name=systemd:/user.slice/user-1000.slice/session-1.scope
10:perf_event:/user.slice/user-1000.slice/session-1.scope
9:net_prio:/user.slice/user-1000.slice/session-1.scope
8:net_cls:/user.slice/user-1000.slice/session-1.scope
7:memory:/user.slice/user-1000.slice/session-1.scope
6:freezer:/user.slice/user-1000.slice/session-1.scope
5:devices:/user.slice/user-1000.slice/session-1.scope
4:cpuset:/user.slice/user-1000.slice/session-1.scope
3:cpuacct:/user.slice/user-1000.slice/session-1.scope
2:cpu:/user.slice/user-1000.slice/session-1.scope
1:blkio:/user.slice/user-1000.slice/session-1.scope
> [snip]
Can you tell me what your systemd-shim and cgmanager versions are?
Thanks a ton,
--
Cameron Norman
