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 --

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 --

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!

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..

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?

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 --

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 --

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..

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.

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 --