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 3.5.13.2 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 3.5.13.2.
>>
>> 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 [393]: pam_unix(kde:session): session opened for user
david by (uid=0)
Feb 28 17:56:40 valhalla [393]: pam_unix(kde:session): session closed for user david
Feb 28 18:06:41 valhalla [407]: pam_unix(kde:session): session opened for user
david by (uid=0)
Mar 01 18:23:42 valhalla [407]: pam_unix(kde:session): session closed for user david
Mar 01 21:39:48 valhalla [1435]: pam_unix(kde:session): session opened for user
david by (uid=0)
Mar 01 22:32:40 valhalla [1435]: pam_unix(kde:session): session closed for user
david
Mar 02 16:14:06 valhalla [485]: pam_unix(kde:session): session opened for user
david by (uid=0)


-- 
David C. Rankin, J.D.,P.E.