On 03/03/2014 12:01 AM, François Andriot wrote: > The difference between 220.127.116.11 and 14.0.0 occurs in remote tdeioslaves that are > listing directories, such as fish and ftp (not tried sftp yet). > In 14.0.0, Every time you list a directory content, you get a new stale > tdeioslave. So if you navigate in your folders, you can get lots of stale > processes ! > This problem does not exist in 18.104.22.168. > > Try to download a flle with a direct file with direct url: > sftp://remote_host/remote_file > and see how many tdeio_sftp appear. > > Francois Yes, I saw where you wrote that opening a 'single' remote file with a unique URL does not generate additional tdeio_x slaves. I have confirmed that if I use konqueror in type the complete URL: sftp://somehost.tld/path/to/a/filename.ext No stale tdeio_sftp processes are created. I have also, confirmed that the tdeio_http processes are ultimately killed by something (presumably the failsafe idle_timeout), but I don't think that behavior is correct. The dirlist on remote hosts does look like it is part of the problem. It's like TDE loses track of all the tdeio_x processes created to build the remote '/path/to/some/' before getting to 'filename.ext' Likewise, I was not able to resolve the 'loginctl show-session $XDG_SESSION_ID' problem by explicitly adding 'greeter' to pam environment. I need to know what 'magic' is being done on your pure-systemd boxes when the display manager is launched that allows you to get the needed session tracking established. Take a look at your setup and see if you can isolate the code. On Arch, the only thing I am doing to launch tdm.service is to enable that service in systemd. My service file contains nothing but: [Unit] Description=TDE Display Manager After=systemd-user-sessions.service [Service] ExecStart=/opt/trinity/bin/tdm [Install] Alias=display-manager.service Does yours contain anything else? -- David C. Rankin, J.D.,P.E.