TDE running on systemd will require code changes proper session tracking? - tde-devels

Slávek Banko

3 Feb 3 Feb

5:46 p.m.

New subject: [trinity-devel] TDE running on systemd will require code changes proper session tracking?

Dne po 3. února 2014 David C. Rankin napsal(a):

Tim, All, I have stumbled upon an issue that may be responsible for the sound and sftp session closing (bug 1902) problems I experience running TDE on a systemd based system. The problem surrounds pam/tdm and polkit setup and tracking user sessions in the absence of Consolekit. The issue is addressed in the freedesktop articles: http://www.freedesktop.org/wiki/Software/systemd/writing-display-manage rs/ http://www.freedesktop.org/wiki/Software/systemd/writing-desktop-enviro nments/ The porting changes necessary for TDE to work in a systemd/polkit environment look minimal, but they are a bit above my understanding at the moment. I have detailed the sftp issue in http://bugs.pearsoncomputing.net/show_bug.cgi?id=1902 along with diagnostics. The crux of the current issue is that tdebase/tdebase mkpamserv does not provide an environment where proper session tracking occurs: 08:29 valhalla:~> loginctl show-session $XDG_SESSION_ID NAutoVTs=6 KillExcludeUsers=root KillUserProcesses=no IdleHint=yes IdleSinceHint=0 IdleSinceHintMonotonic=0 InhibitDelayMaxUSec=5s HandlePowerKey=poweroff HandleSuspendKey=suspend HandleHibernateKey=hibernate HandleLidSwitch=suspend IdleAction=ignore IdleActionUSec=30min PreparingForShutdown=no PreparingForSleep=no does not contain Remote=no and Active=yes which apparently indicate proper user session tracking. I need someone who has a bit more experience with tdebase code and in this area to review the freedesktop links regarding the new session tracking requirements under systemd and see if this is an issue that needs to be jumped on before RC1 is frozen. Currently, the current problems I have discovered under systemd impact user sound access/printer driver generation/and sftp session closure. I suspect the problems may be more widespread but I have yet to discover all of them. I have compared what TDE does with /etc/pam.d/trinity and what is currently done with kde4 on arch. The current TDE pam.d settings are: /etc/pam.d/trinity #%PAM-1.0 #auth required pam_securetty.so auth requisite pam_nologin.so auth include system-local-login account include system-local-login session include system-local-login The comparable pam setup for kde4 on Arch uses (noc is cat with no-comment): 09:56 alchemy:~/tde/tmp/pam> noc kde4/kde #%PAM-1.0 auth include system-login account include system-login password include system-login session include system-login 09:56 alchemy:~/tde/tmp/pam> noc kde4/kde-np #%PAM-1.0 auth required pam_tally.so onerr=succeed file=/var/log/faillog auth required pam_shells.so auth requisite pam_nologin.so auth required pam_env.so auth optional pam_permit.so account include system-login password include system-login session include system-login 10:00 alchemy:~/tde/tmp/pam> noc kde4/kscreensaver #%PAM-1.0 auth required pam_unix_auth.so I have tried changing /etc/pam.d/trinity to use: #%PAM-1.0 #auth required pam_securetty.so auth requisite pam_nologin.so auth include system-login account include system-login password include system-login session include system-login Login is fine using system-login instead of the current 'system-local-login', but the output of 'loginctl show-session $XDG_SESSION_ID' is unchanged. I have posted the issue to the Arch list and will report any suggestins back. Experts, what say you?

I have a test machine with Ubuntu 13.10 (Saucy), on which is used systemd. Without giving anything set up in list from: loginctl show-session $ XDG_SESSION_ID I see the values: Id=c4 Timestamp=Thu 2014-01-30 20:31:22 CET TimestampMonotonic=267801422 DefaultControlGroup=systemd:/user/1000.user/c4.session VTNr=7 Display=:0 Remote=no Service=tdm-trinity Leader=1807 Audit=0 Type=x11 Class=user Active=yes State=active KillProcesses=no IdleHint=no IdleSinceHint=0 IdleSinceHintMonotonic=0 Name=axis I looked at the above referenced recommendations. Patch ready for tdepowersave includes monitoring systemd session and in accordance with the recommendations set Inhibits, thereby declaring its own event handling power management. See bug 1597 - I think that this patch can be pushed. During the preparation of this patch I was considering whether to implement into tdepowersave a response to a signal Lock() from systemd (this way is addressed in KDE4 - a response to a signal is implemented in PowerDevil). However, this solution I thought was wrong, because in my opinion, belong to ksmserver or kdesktop_lock. Not all users will have installed tdepowersave. Add call SetIdleHint(True / False) would not be difficult. Suitable place seems kdesktop_lock - before / after activate the screen saver. Most recommendations bent to tdm, wherein is currently the integrated only ConsoleKit. Does anyone know which distributions currently used exclusively SystemD and do not contain ConsoleKit? I do not have an estimate of how much work / time will be required to implement support for systemd in TDM. I do not know if because of that delay the release R14.0.0. Personally, I tend to not to consider this as blocking. What do you think? Slavek --

Reply

Slávek Banko

6:06 p.m.

New subject: [trinity-devel] TDE running on systemd will require code changes proper session tracking?

Dne po 3. února 2014 David C. Rankin napsal(a):

...

On 02/03/2014 11:46 AM, Slávek Banko wrote:

Dne po 3. února 2014 David C. Rankin napsal(a): > Tim, All, > > I have stumbled upon an issue that may be responsible for the > sound and sftp session closing (bug 1902) problems I experience > running TDE on a systemd based system. The problem surrounds pam/tdm > and polkit setup and tracking user sessions in the absence of > Consolekit. The issue is addressed in the freedesktop articles: > > http://www.freedesktop.org/wiki/Software/systemd/writing-display-man >age rs/ > > http://www.freedesktop.org/wiki/Software/systemd/writing-desktop-env >iro nments/ > > The porting changes necessary for TDE to work in a systemd/polkit > environment look minimal, but they are a bit above my understanding > at the moment. > > I have detailed the sftp issue in > http://bugs.pearsoncomputing.net/show_bug.cgi?id=1902 along with > diagnostics. The crux of the current issue is that tdebase/tdebase > mkpamserv does not provide an environment where proper session > tracking occurs: > > 08:29 valhalla:~> loginctl show-session $XDG_SESSION_ID > NAutoVTs=6 > KillExcludeUsers=root > KillUserProcesses=no > IdleHint=yes > IdleSinceHint=0 > IdleSinceHintMonotonic=0 > InhibitDelayMaxUSec=5s > HandlePowerKey=poweroff > HandleSuspendKey=suspend > HandleHibernateKey=hibernate > HandleLidSwitch=suspend > IdleAction=ignore > IdleActionUSec=30min > PreparingForShutdown=no > PreparingForSleep=no > > does not contain Remote=no and Active=yes which apparently > indicate proper user session tracking. I need someone who has a bit > more experience with tdebase code and in this area to review the > freedesktop links regarding the new session tracking requirements > under systemd and see if this is an issue that needs to be jumped on > before RC1 is frozen. Currently, the current problems I have > discovered under systemd impact user sound access/printer driver > generation/and sftp session closure. I suspect the problems may be > more widespread but I have yet to discover all of them.

<snip>

I have a test machine with Ubuntu 13.10 (Saucy), on which is used systemd. Without giving anything set up in list from: loginctl show-session $ XDG_SESSION_ID I see the values: Id=c4 Timestamp=Thu 2014-01-30 20:31:22 CET TimestampMonotonic=267801422 DefaultControlGroup=systemd:/user/1000.user/c4.session VTNr=7 Display=:0 Remote=no Service=tdm-trinity Leader=1807 Audit=0 Type=x11 Class=user Active=yes State=active KillProcesses=no IdleHint=no IdleSinceHint=0 IdleSinceHintMonotonic=0 Name=axis I looked at the above referenced recommendations.

How did you get saucy to activate properly?? For Archlinux I am using tdm.service: [Unit] Description=TDE Display Manager After=systemd-user-sessions.service [Service] ExecStart=/opt/trinity/bin/tdm [Install] Alias=display-manager.service and /etc/X11/xinit/xinitrc.d is activating: 30-dbus pulseaudio yet I do not get any of the X specific setting you show in your response to 'loginctl show-session $ XDG_SESSION_ID' If this can be done via configuration, then I'm fine doing it that way, but I have not been able to find a working config that will do it...

Patch ready for tdepowersave includes monitoring systemd session and in accordance with the recommendations set Inhibits, thereby declaring its own event handling power management. See bug 1597 - I think that this patch can be pushed. During the preparation of this patch I was considering whether to implement into tdepowersave a response to a signal Lock() from systemd (this way is addressed in KDE4 - a response to a signal is implemented in PowerDevil). However, this solution I thought was wrong, because in my opinion, belong to ksmserver or kdesktop_lock. Not all users will have installed tdepowersave. Add call SetIdleHint(True / False) would not be difficult. Suitable place seems kdesktop_lock - before / after activate the screen saver. Most recommendations bent to tdm, wherein is currently the integrated only ConsoleKit. Does anyone know which distributions currently used exclusively SystemD and do not contain ConsoleKit? I do not have an estimate of how much work / time will be required to implement support for systemd in TDM. I do not know if because of that delay the release R14.0.0. Personally, I tend to not to consider this as blocking. What do you think? Slavek

Archlinux uses SystemD exclusively without ConsoleKit....

As I wrote - I did not do anything :) On the Saucy is present SystemD and ConsoleKit simultaneously. To run tdm-trinity is used classic init script (/etc/init.d/tdm-trinity). Slavek --

Reply

Slávek Banko

7:01 p.m.

New subject: [trinity-devel] TDE running on systemd will require code changes proper session tracking?

Dne po 3. února 2014 David C. Rankin napsal(a):

...

On 02/03/2014 12:06 PM, Slávek Banko wrote:

As I wrote - I did not do anything :) On the Saucy is present SystemD and ConsoleKit simultaneously. To run tdm-trinity is used classic init script (/etc/init.d/tdm-trinity)

Oh... I don't even install that anymore. I have nothing in /etc/rc.d.... in fact, I don't even have an /etc/rc.d directory... Is there anything we can add to /etc/profile.d/trinity.sh that might help?

I assume that the essence of 'good conduct' on Ubuntu Saucy's is presence ConsoleKit and creating ConsoleKit session in TDM. I'm afraid that the absence ConsoleKit requires to add SystemD session management into TDM. Right now I search the entire git tree if anything use XDG_SESSION_COOKIE, which is specific for ConsoleKit. Such would require a fix for the "clean" SystemD session. Slavek --

Reply

David C. Rankin

8:40 p.m.

New subject: [trinity-devel] TDE running on systemd will require code changes proper session tracking?

On 02/03/2014 02:02 PM, David C. Rankin wrote:

...

On 02/03/2014 01:01 PM, Slávek Banko wrote:

Is there anything we can add to /etc/profile.d/trinity.sh that might > help?

I assume that the essence of 'good conduct' on Ubuntu Saucy's is presence ConsoleKit and creating ConsoleKit session in TDM. I'm afraid that the absence ConsoleKit requires to add SystemD session management into TDM. Right now I search the entire git tree if anything use XDG_SESSION_COOKIE, which is specific for ConsoleKit. Such would require a fix for the "clean" SystemD session.

Slavek, What graphical authentication agent does TDE load? Does it work with polkit? Also, I found: 14:00 phoinix:/dat_e/tde/tde/main/tdebase> grep -rn XDG_SESSION_COOKIE * tdm/backend/client.c:1315: env = setEnv ( env, "XDG_SESSION_COOKIE", ck_session_cookie ); tdm/backend/client.c:1320: env = setEnv ( env, "XDG_SESSION_COOKIE", ck_session_cookie ); So what kind of fix do we need?

There are already preprocessor checks around the consolekit code, so in Arch's case, they should not even be part of the build: #ifdef WITH_CONSOLE_KIT if (ck_session_cookie != NULL) { env = setEnv ( env, "XDG_SESSION_COOKIE", ck_session_cookie ); } #endif #ifdef WITH_CONSOLE_KIT if (ck_session_cookie != NULL) { env = setEnv ( env, "XDG_SESSION_COOKIE", ck_session_cookie ); } #endif The question become what do we need to add to accommodate systemd. Can we implement the following in the same place? Minimal porting (without multi-seat) requires the following: Remove/disable all code responsible for registering your service with ConsoleKit. Make sure to register your greeter session via the PAM session stack, and make sure the PAM session modules include pam_systemd. Also, make sure to set the session class to "greeter." This may be done by setting the environment variable XDG_SESSION_CLASS to "greeter" with pam_misc_setenv() or setting the "class=greeter" option in the pam_systemd module, in order to allow applications to filter out greeter sessions from normal login sessions. Make sure to register your logged in session via the PAM session stack as well, also including pam_systemd in it. Optionally, use pam_misc_setenv() to set the environment variables XDG_SEAT and XDG_VTNR. The former should contain "seat0", the latter the VT number your session runs on. pam_systemd can determine these values automatically but it's nice to pass these variables anyway. In summary: porting a display manager from ConsoleKit to systemd primarily means removing code, not necessarily adding any new code. Here, a cheers to simplicity! -- David C. Rankin, J.D.,P.E.

Reply

David C. Rankin

8:58 p.m.

New subject: [trinity-devel] TDE running on systemd will require code changes proper session tracking?

On 02/03/2014 02:41 PM, Slávek Banko wrote:

...

Outside of that was found in tdebase, XDG_SESSION_COOKIE is used in kpowersave and tdepowersave (will be fixed after commit patch from bug 1597). This is good news - on the ConsoleKit no more dependent - only TDM. In other words, it should be enough to add support for SystemD session into TDM. I will try to assess how difficult this task is... Slavek

That is good news! Also, at least for tdebase, the preprocessor checks already exclude the console kit code when not defined. Checking the running processes, it looks like everything required from Arch is already started and running: /sbin/init /usr/lib/systemd/systemd-journald /usr/lib/systemd/systemd-udevd /usr/lib/systemd/systemd-logind /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation /sbin/agetty --noclear tty1 /opt/trinity/bin/tdm \_ /usr/bin/X -br -nolisten tcp :0 vt7 -auth /var/run/xauth/A:0-LI4Qla \_ -:0 \_ /bin/sh /opt/trinity/bin/starttde \_ /opt/trinity/bin/tdeinit_phase1 \_ kwrapper ksmserver --windowmanager twin /usr/bin/gpg-agent --daemon /usr/bin/ssh-agent -s dcopserver [tdeinit] --nosid --suicide kded [tdeinit] --new-startup start_tdeinit --new-startup +kcminit_startup All we need is to provide is the minimum porting requirements: Minimal porting (without multi-seat) requires the following: 1. Remove/disable all code responsible for registering your service with ConsoleKit. 2. Make sure to register your greeter session via the PAM session stack, and make sure the PAM session modules include pam_systemd. Also, make sure to set the session class to "greeter." This may be done by setting the environment variable XDG_SESSION_CLASS to "greeter" with pam_misc_setenv() or setting the "class=greeter" option in the pam_systemd module, in order to allow applications to filter out greeter sessions from normal login sessions. 3. Make sure to register your logged in session via the PAM session stack as well, also including pam_systemd in it. 4. Optionally, use pam_misc_setenv() to set the environment variables XDG_SEAT and XDG_VTNR. The former should contain "seat0", the latter the VT number your session runs on. pam_systemd can determine these values automatically but it's nice to pass these variables anyway. In summary: porting a display manager from ConsoleKit to systemd primarily means removing code, not necessarily adding any new code. Here, a cheers to simplicity! It looks like #2 is where the work is. Coding wizard like you - no sweat.. -- David C. Rankin, J.D.,P.E.

Reply

David C. Rankin

9:59 p.m.

New subject: [trinity-devel] TDE running on systemd will require code changes proper session tracking?

On 02/03/2014 03:28 PM, David C. Rankin wrote:

...

On 02/03/2014 02:58 PM, David C. Rankin wrote:

On 02/03/2014 02:41 PM, Slávek Banko wrote:

Outside of that was found in tdebase, XDG_SESSION_COOKIE is used in kpowersave and tdepowersave (will be fixed after commit patch from bug 1597). This is good news - on the ConsoleKit no more dependent - only TDM. In other words, it should be enough to add support for SystemD session into TDM. I will try to assess how difficult this task is... Slavek

That is good news! Also, at least for tdebase, the preprocessor checks already exclude the console kit code when not defined. Checking the running processes, it looks like everything required from Arch is already started and running: /sbin/init /usr/lib/systemd/systemd-journald /usr/lib/systemd/systemd-udevd /usr/lib/systemd/systemd-logind /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation /sbin/agetty --noclear tty1 /opt/trinity/bin/tdm \_ /usr/bin/X -br -nolisten tcp :0 vt7 -auth /var/run/xauth/A:0-LI4Qla \_ -:0 \_ /bin/sh /opt/trinity/bin/starttde \_ /opt/trinity/bin/tdeinit_phase1 \_ kwrapper ksmserver --windowmanager twin /usr/bin/gpg-agent --daemon /usr/bin/ssh-agent -s dcopserver [tdeinit] --nosid --suicide kded [tdeinit] --new-startup start_tdeinit --new-startup +kcminit_startup All we need is to provide is the minimum porting requirements: Minimal porting (without multi-seat) requires the following: 1. Remove/disable all code responsible for registering your service with ConsoleKit. 2. Make sure to register your greeter session via the PAM session stack, and make sure the PAM session modules include pam_systemd. Also, make sure to set the session class to "greeter." This may be done by setting the environment variable XDG_SESSION_CLASS to "greeter" with pam_misc_setenv() or setting the "class=greeter" option in the pam_systemd module, in order to allow applications to filter out greeter sessions from normal login sessions. 3. Make sure to register your logged in session via the PAM session stack as well, also including pam_systemd in it. 4. Optionally, use pam_misc_setenv() to set the environment variables XDG_SEAT and XDG_VTNR. The former should contain "seat0", the latter the VT number your session runs on. pam_systemd can determine these values automatically but it's nice to pass these variables anyway. In summary: porting a display manager from ConsoleKit to systemd primarily means removing code, not necessarily adding any new code. Here, a cheers to simplicity! It looks like #2 is where the work is. Coding wizard like you - no sweat..

I don't know if this helps or not, but I noticed that mkpamserv installed as part of tdebase and used in the tdebase.install script creates a trinity pam file with: #%PAM-1.0 #auth required pam_securetty.so auth requisite pam_nologin.so auth include system-local-login account include system-local-login session include system-local-login The inclusion of system-local-login, include the following: cat ../pam.d/system-local-login #%PAM-1.0 auth include system-login account include system-login password include system-login session include system-login Which in-turn includes 'system-login' for each auth, account, password and session: cat ../pam.d/system-login #%PAM-1.0 auth required pam_tally.so onerr=succeed file=/var/log/faillog auth required pam_shells.so auth requisite pam_nologin.so auth include system-auth account required pam_access.so account required pam_nologin.so account include system-auth password include system-auth session optional pam_loginuid.so session include system-auth session optional pam_motd.so motd=/etc/motd session optional pam_mail.so dir=/var/spool/mail standard quiet -session optional pam_systemd.so session required pam_env.so I don't know if this is common, but that shows what pam modules are available/called on arch to allow logind/dbus/polit to track and manage user sessions and device access on arch -- if it makes any difference.

Per the suggestion on the freedesktop page, perhaps adding something like the following around line 1320 of client.c would make explicit the needed environment: if ((pretc = pam_misc_setenv( pamh, XDG_SESSION_CLASS, "greeter", 0 )) != PAM_SUCCESS) { ReInitErrorLog(); LogError( "pam_misc_setenv() for %s failed: %s\n", curuser, pam_strerror( pamh, pretc ) ); return 0; } if ((pretc = pam_misc_setenv( pamh, XDG_SEAT, "seat0", 0 )) != PAM_SUCCESS) { ReInitErrorLog(); LogError( "pam_misc_setenv() for %s failed: %s\n", curuser, pam_strerror( pamh, pretc ) ); return 0; } if ((pretc = pam_misc_setenv( pamh, XDG_VTNR, "7", 0 )) != PAM_SUCCESS) { ReInitErrorLog(); LogError( "pam_misc_setenv() for %s failed: %s\n", curuser, pam_strerror( pamh, pretc ) ); return 0; } ** check syntax, this is my guess at it or we could use something like: pam_putenv(pamh, "XDG_SESSION_CLASS=greeter"); instead of pam_misc_setenv. Other than that, the other area where I don't fully understand what is needed is in #3 - "Make sure to register your logged in session via the PAM session stack as well, also including pam_systemd in it." That may already be done, but I would like to understand a bit better how/where logged in user registration takes place and what it means to include pam_systemd in it? -- David C. Rankin, J.D.,P.E.

Reply

Slávek Banko

10:15 p.m.

New subject: [trinity-devel] TDE running on systemd will require code changes proper session tracking?

On Monday 03 of February 2014 22:59:39 David C. Rankin wrote:

...

On 02/03/2014 03:28 PM, David C. Rankin wrote:

On 02/03/2014 02:58 PM, David C. Rankin wrote:

On 02/03/2014 02:41 PM, Slávek Banko wrote:

Outside of that was found in tdebase, XDG_SESSION_COOKIE is used in kpowersave and tdepowersave (will be fixed after commit patch from bug 1597). This is good news - on the ConsoleKit no more dependent - only TDM. In other words, it should be enough to add support for SystemD session into TDM. I will try to assess how difficult this task is... Slavek

That is good news! Also, at least for tdebase, the preprocessor checks already exclude the console kit code when not defined. Checking the running processes, it looks like everything required from Arch is already started and running: /sbin/init /usr/lib/systemd/systemd-journald /usr/lib/systemd/systemd-udevd /usr/lib/systemd/systemd-logind /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation /sbin/agetty --noclear tty1 /opt/trinity/bin/tdm \_ /usr/bin/X -br -nolisten tcp :0 vt7 -auth /var/run/xauth/A:0-LI4Qla \_ -:0 \_ /bin/sh /opt/trinity/bin/starttde \_ /opt/trinity/bin/tdeinit_phase1 \_ kwrapper ksmserver --windowmanager twin /usr/bin/gpg-agent --daemon /usr/bin/ssh-agent -s dcopserver [tdeinit] --nosid --suicide kded [tdeinit] --new-startup start_tdeinit --new-startup +kcminit_startup All we need is to provide is the minimum porting requirements: Minimal porting (without multi-seat) requires the following: 1. Remove/disable all code responsible for registering your service with ConsoleKit. 2. Make sure to register your greeter session via the PAM session stack, and make sure the PAM session modules include pam_systemd. Also, make sure to set the session class to "greeter." This may be done by setting the environment variable XDG_SESSION_CLASS to "greeter" with pam_misc_setenv() or setting the "class=greeter" option in the pam_systemd module, in order to allow applications to filter out greeter sessions from normal login sessions. 3. Make sure to register your logged in session via the PAM session stack as well, also including pam_systemd in it. 4. Optionally, use pam_misc_setenv() to set the environment variables XDG_SEAT and XDG_VTNR. The former should contain "seat0", the latter the VT number your session runs on. pam_systemd can determine these values automatically but it's nice to pass these variables anyway. In summary: porting a display manager from ConsoleKit to systemd primarily means removing code, not necessarily adding any new code. Here, a cheers to simplicity! It looks like #2 is where the work is. Coding wizard like you - no sweat..

I don't know if this helps or not, but I noticed that mkpamserv installed as part of tdebase and used in the tdebase.install script creates a trinity pam file with: #%PAM-1.0 #auth required pam_securetty.so auth requisite pam_nologin.so auth include system-local-login account include system-local-login session include system-local-login The inclusion of system-local-login, include the following: cat ../pam.d/system-local-login #%PAM-1.0 auth include system-login account include system-login password include system-login session include system-login Which in-turn includes 'system-login' for each auth, account, password and session: cat ../pam.d/system-login #%PAM-1.0 auth required pam_tally.so onerr=succeed file=/var/log/faillog auth required pam_shells.so auth requisite pam_nologin.so auth include system-auth account required pam_access.so account required pam_nologin.so account include system-auth password include system-auth session optional pam_loginuid.so session include system-auth session optional pam_motd.so motd=/etc/motd session optional pam_mail.so dir=/var/spool/mail standard quiet -session optional pam_systemd.so session required pam_env.so I don't know if this is common, but that shows what pam modules are available/called on arch to allow logind/dbus/polit to track and manage user sessions and device access on arch -- if it makes any difference.

Per the suggestion on the freedesktop page, perhaps adding something like the following around line 1320 of client.c would make explicit the needed environment: if ((pretc = pam_misc_setenv( pamh, XDG_SESSION_CLASS, "greeter", 0 )) != PAM_SUCCESS) { ReInitErrorLog(); LogError( "pam_misc_setenv() for %s failed: %s\n", curuser, pam_strerror( pamh, pretc ) ); return 0; } if ((pretc = pam_misc_setenv( pamh, XDG_SEAT, "seat0", 0 )) != PAM_SUCCESS) { ReInitErrorLog(); LogError( "pam_misc_setenv() for %s failed: %s\n", curuser, pam_strerror( pamh, pretc ) ); return 0; } if ((pretc = pam_misc_setenv( pamh, XDG_VTNR, "7", 0 )) != PAM_SUCCESS) { ReInitErrorLog(); LogError( "pam_misc_setenv() for %s failed: %s\n", curuser, pam_strerror( pamh, pretc ) ); return 0; } ** check syntax, this is my guess at it or we could use something like: pam_putenv(pamh, "XDG_SESSION_CLASS=greeter"); instead of pam_misc_setenv. Other than that, the other area where I don't fully understand what is needed is in #3 - "Make sure to register your logged in session via the PAM session stack as well, also including pam_systemd in it." That may already be done, but I would like to understand a bit better how/where logged in user registration takes place and what it means to include pam_systemd in it?

Now I read it again and if I understand it correctly, is that about correct setting PAM => no need to change the source code of TDM? Slavek --

Reply

Slávek Banko

10:41 p.m.

New subject: [trinity-devel] TDE running on systemd will require code changes proper session tracking?

On Monday 03 of February 2014 23:32:02 David C. Rankin wrote:

...

On 02/03/2014 04:15 PM, Slávek Banko wrote:

Now I read it again and if I understand it correctly, is that about correct setting PAM => no need to change the source code of TDM?

Yes -- there may be minor changes, but I believe the key is #3 and making sure the pam stack has the needed information including pam_systemd. The coding should be negligible. We just have to figure out how to tell if the pam stack is set properly in TDE/TDM. How in the heck do you do that? The environment settings are what was suggested in #2 and #4 on the http://www.freedesktop.org/wiki/Software/systemd/writing-display-managers/ page.

Aha, so #1 is a little different :) For #1: WITH_CONSOLE_KIT is defined in dm.h => is always set. However, if ConsoleKit is not available on your system, it should not be a problem. Session will not be registered under the ConsoleKit and XDG_SESSION_COOKIE will not be set => no need to change source code TDM. If I understand correctly, #2 can be set in PAM configuration => no need to change source code TDM. And #4 is optional => no need to change source code TDM. Slavek --

Reply

David C. Rankin

4 Feb 4 Feb

12:01 a.m.

New subject: [trinity-devel] TDE running on systemd will require code changes proper session tracking?

On 02/03/2014 05:37 PM, David C. Rankin wrote:

...

On 02/03/2014 04:41 PM, Slávek Banko wrote:

On Monday 03 of February 2014 23:32:02 David C. Rankin wrote:

On 02/03/2014 04:15 PM, Slávek Banko wrote:

Now I read it again and if I understand it correctly, is that about correct setting PAM => no need to change the source code of TDM?

Yes -- there may be minor changes, but I believe the key is #3 and making sure the pam stack has the needed information including pam_systemd. The coding should be negligible. We just have to figure out how to tell if the pam stack is set properly in TDE/TDM. How in the heck do you do that? The environment settings are what was suggested in #2 and #4 on the http://www.freedesktop.org/wiki/Software/systemd/writing-display-managers/ page.

Aha, so #1 is a little different :) For #1: WITH_CONSOLE_KIT is defined in dm.h => is always set. However, if ConsoleKit is not available on your system, it should not be a problem. Session will not be registered under the ConsoleKit and XDG_SESSION_COOKIE will not be set => no need to change source code TDM. If I understand correctly, #2 can be set in PAM configuration => no need to change source code TDM. And #4 is optional => no need to change source code TDM. Slavek

I see what you are saying, but I'm a bit concerned that all the preprocessor directives may be causing problems. For example, since WITH_CONSOLE_KIT is aways set, then what if (ck_session_cookie != NULL), then the XDG_SESSION_COOKIE is still set. Won't that screw up the pure systemd session tracking? For #2 how in the heck to we set that? I don't see any options to register the greeter session via the PAM session stack or how to make sure the PAM session modules include pam_systemd?? It seems simple, but how/where are these things set? Are these additional pam_misc_setenv() or pam_setenv() calls that are needed are is there another way to set these? What does it mean "make sure the PAM session modules include pam_systemd"? #3 is a reminder to make sure we did #2 correctly.... and then to do it AGAIN for the "logged in user". What? #4 that is optional, but I don't see the harm in adding the pam_misc_setenv() calls to make sure pam has "seat0" and vt"7" -- or at least we need a way to confirm that it does. The running process information show vt7 is set correctly, but what is "seat0" and how to check? /opt/trinity/bin/tdm \_ /usr/bin/X -br -nolisten tcp :0 vt7 -auth /var/run/xauth/A:0-LI4Qla \_ -:0 \_ /bin/sh /opt/trinity/bin/starttde \_ /opt/trinity/bin/tdeinit_phase1 \_ kwrapper ksmserver --windowmanager twin I need more aspirin...

Whether it is config or code, I need to find a solution. Just to open a connection to my server and check dm.h in tdebase/tdm, I'm left with 9 open sftp connections: [tdeinit] tdeinit Running... \_ tdelauncher [tdeinit] --new-startup \_ twin [tdeinit] -session 10d7cdd8c9000139108311200000009720000_1391 \_ konqueror [tdeinit] -session 10d7cdd8c9000139137984400000009830033 \_ konqueror [tdeinit] -session 10d7cdd8c9000139144380300000007290014 \_ konsole [tdeinit] | \_ /bin/bash | | \_ su | | \_ bash | \_ /bin/bash | \_ ps axf | \_ cut -c28- \_ tdeio_file [tdeinit] file /tmp/tdesocket-david/tdelauncherkQTzd6.s \_ tdeio_sftp [tdeinit] sftp /tmp/tdesocket-david/tdelauncherkQTzd6.s \_ tdeio_sftp [tdeinit] sftp /tmp/tdesocket-david/tdelauncherkQTzd6.s \_ tdeio_sftp [tdeinit] sftp /tmp/tdesocket-david/tdelauncherkQTzd6.s \_ tdeio_sftp [tdeinit] sftp /tmp/tdesocket-david/tdelauncherkQTzd6.s \_ tdeio_sftp [tdeinit] sftp /tmp/tdesocket-david/tdelauncherkQTzd6.s \_ tdeio_sftp [tdeinit] sftp /tmp/tdesocket-david/tdelauncherkQTzd6.s \_ tdeio_sftp [tdeinit] sftp /tmp/tdesocket-david/tdelauncherkQTzd6.s \_ tdeio_sftp [tdeinit] sftp /tmp/tdesocket-david/tdelauncherkQTzd6.s \_ tdeio_sftp [tdeinit] sftp /tmp/tdesocket-david/tdelauncherkQTzd6.s \_ tdeio_sftp [tdeinit] sftp /tmp/tdesocket-david/tdelauncherkQTzd6.s If I check another file, I'm up to 18 connections, then 27, etc... You get it.. -- David C. Rankin, J.D.,P.E.

Reply

David C. Rankin

2:08 p.m.

New subject: [trinity-devel] TDE running on systemd will require code changes proper session tracking?

On 02/03/2014 08:40 PM, Slávek Banko wrote:

...

I tried on my test machine with Ubuntu 13.10 (Saucy) uninstall ConsoleKit and now I have the same problem with the proper initialization SystemD session. In the coming days I will try to work on it.

Thank you Slavek - It is indeed a real problem for distros moving to systemd. I'll reference this thread in bug 1902. -- David C. Rankin, J.D.,P.E.

Reply

Slávek Banko

5:24 p.m.

New subject: [trinity-devel] TDE running on systemd will require code changes proper session tracking?

Dne út 4. února 2014 David C. Rankin napsal(a):

...

On 02/04/2014 08:08 AM, David C. Rankin wrote:

On 02/03/2014 08:40 PM, Slávek Banko wrote:

I tried on my test machine with Ubuntu 13.10 (Saucy) uninstall ConsoleKit and now I have the same problem with the proper initialization SystemD session. In the coming days I will try to work on it.

Thank you Slavek - It is indeed a real problem for distros moving to systemd. I'll reference this thread in bug 1902.

Slavek, I stumbled across the attached patch for kde/kdm that seems to address the systemd session tracking issue. This provides the multi-seat patch to kdm to the same files we have been looking at. Take a look:

Great, thank you. I have downloaded the source code kde-workspace 4.8 and 4.10, so that's why I have not found systemd session handling in them :) Slavek --

Reply