On 03/03/2014 08:17 AM, David C. Rankin wrote: > On 03/03/2014 12:01 AM, François Andriot wrote: >> The difference between 18.104.22.168 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 22.214.171.124. >> >> 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? > The minimal kde:session tracking is working on my system (since my xsession fix on 1/30), but none of the internal user session tools polkit/udev, etc. work to provide access to sound, user mount, etc. The logs are clear that the kde:session is seen, opened and closed: Feb 28 17:51:59 valhalla : pam_unix(kde:session): session opened for user david by (uid=0) Feb 28 17:56:40 valhalla : pam_unix(kde:session): session closed for user david Feb 28 18:06:41 valhalla : pam_unix(kde:session): session opened for user david by (uid=0) Mar 01 18:23:42 valhalla : pam_unix(kde:session): session closed for user david Mar 01 21:39:48 valhalla : pam_unix(kde:session): session opened for user david by (uid=0) Mar 01 22:32:40 valhalla : pam_unix(kde:session): session closed for user david Mar 02 16:14:06 valhalla : pam_unix(kde:session): session opened for user david by (uid=0) -- David C. Rankin, J.D.,P.E.