On 03/02/2014 03:59 PM, David C. Rankin wrote: Francios, Just logging in leave 2 open tdeio_file connections and 4 tdeio_http connections from KOrganizer checking the groupware calendar, etc. That is 6 open/abandoned tdeio processes before I have even launched any application. 578 ? S 0:00 \_ tdelauncher [tdeinit] --new-startup 589 ? S 0:01 \_ twin [tdeinit] -session 10d7cdd8c9000139108311200000009720000_1393 605 ? S 0:00 \_ tdeio_file [tdeinit] file /tmp/tdesocket-david/tdelauncherbcVCMs.s 606 ? S 0:00 \_ tdeio_file [tdeinit] file /tmp/tdesocket-david/tdelauncherbcVCMs.s 612 ? S 0:00 \_ notification-daemon-tde 631 ? S 0:00 \_ konqueror [tdeinit] -session 10d7cdd8c9000139235256900000063930014 632 ? S 0:00 \_ konqueror [tdeinit] -session 10d7cdd8c9000139241737300000063930020 633 ? S 0:00 \_ konqueror [tdeinit] -session 10d7cdd8c9000139269956500000004590015 634 ? S 0:00 \_ konqueror [tdeinit] -session 10d7cdd8c9000139271054100000004590028 635 ? S 0:00 \_ konqueror [tdeinit] -session 10d7cdd8c9000139340009600000013660015 636 ? S 0:00 \_ konqueror [tdeinit] -session 10d7cdd8c9000139346014900000005280015 675 ? S 0:00 \_ tdeio_http [tdeinit] https /tmp/tdesocket-david/tdelauncherbcVCMs. 679 ? S 0:00 \_ tdeio_http [tdeinit] https /tmp/tdesocket-david/tdelauncherbcVCMs. 682 ? S 0:00 \_ tdeio_http [tdeinit] https /tmp/tdesocket-david/tdelauncherbcVCMs. 683 ? S 0:00 \_ tdeio_http [tdeinit] https /tmp/tdesocket-david/tdelauncherbcVCMs. I think the tdeio_http process ARE included as part of this problem, BUT I think the idle_timeout for http is working and will eventually kill the tdeio_http procs. They are definitely left open after the http query from KOrganizer, but something kills them some time later (~60 seconds later). Then opening konqueror and selecting 1 remote file to edit in kate gives the following .xsession-error output: konqueror: tdeio_file: ========= LIST file:/// ========= tdeio_file: ========= LIST file:///home/david ========= tdeio_file: ============= COMPLETED LIST ============ tdeio_file: ============= COMPLETED LIST ============ tdeio: KSambaShare: Could not found smb.conf! tdeio: KNFSShare: Could not found exports file! tdeio (TDEIOJob): stat sftp://phoinix.rlfpllc.com/dat_e/ [tdeinit] Got EXEC_NEW 'tdeio_sftp' from launcher. tdeio (TDELauncher): tdeio_sftp (pid 725) up and running. tdeio_sftp: ERROR: KSshProcess::version(): pclose failed. tdeio (TDEIOJob): LocalURLJob::slotLocalURL(sftp://phoinix.rlfpllc.com/dat_e/) [tdeinit] Got EXEC_NEW 'tdeio_sftp' from launcher. tdeio (TDELauncher): tdeio_sftp (pid 729) up and running. tdeio_sftp: ERROR: KSshProcess::version(): pclose failed. tdeio (TDEIOJob): LocalURLJob::slotLocalURL(sftp://phoinix.rlfpllc.com/dat_e/tde) [tdeinit] Got EXEC_NEW 'tdeio_sftp' from launcher. tdeio (TDELauncher): tdeio_sftp (pid 733) up and running. tdeio (TDEIOJob): LocalURLJob::slotLocalURL(sftp://phoinix.rlfpllc.com/dat_e/tde/tmp) [tdeinit] Got EXEC_NEW 'tdeio_sftp' from launcher. tdeio (TDELauncher): tdeio_sftp (pid 737) up and running. tdeio_sftp: ERROR: KSshProcess::version(): pclose failed. open remote file in kate, edit and close: tdeio (TDELauncher): TDELauncher: Got start_service_by_desktop_path('/opt/trinity/share/applications/tde/kate.desktop', ...) [tdeinit] Got EXT_EXEC 'kate' from launcher. tdeio (TDELauncher): kate (pid 749) up and running. tdecore (TDEAction): WARNING: TDEActionCollection::TDEActionCollection( TQObject *parent, const char *name, TDEInstance *instance ) tdeio (TDEIOJob): Starting tdeio_uiserver tdeio (TDELauncher): TDELauncher: Got start_service_by_desktop_path('tdeio_uiserver.desktop', ...) [tdeinit] Got EXT_EXEC 'tdeio_uiserver' from launcher. tdeio (TDELauncher): tdeio_uiserver (pid 750) up and running. tdeio (TDEIOJob): startServiceByDesktopPath returned 0 tdeio (TDEIOJob): tdeio_uiserver registered [tdeinit] Got EXEC_NEW 'tdeio_file' from launcher. tdeio (TDELauncher): tdeio_file (pid 752) up and running. [tdeinit] Got EXEC_NEW 'tdeio_sftp' from launcher. tdeio (TDELauncher): tdeio_sftp (pid 753) up and running. tdeio_file: Starting 752 tdeio_file: ========= LIST file:///home/david ========= tdeio_file: ============= COMPLETED LIST ============ tdeio: KSambaShare: Could not found smb.conf! tdeio: KNFSShare: Could not found exports file! tdeio_sftp: ERROR: KSshProcess::version(): pclose failed. tdeio_sftp: ERROR: sftpRead: read failed with code 1 tdeio_file: Done tdeio_file: Done After opening/edit/closing the remote file I have 3 additional hung tdeio_sftp processes and 1 more tdeio_file process: 725 ? S 0:00 \_ tdeio_sftp [tdeinit] sftp /tmp/tdesocket-david/tdelauncherbcVCMs.s 729 ? S 0:00 \_ tdeio_sftp [tdeinit] sftp /tmp/tdesocket-david/tdelauncherbcVCMs.s 733 ? S 0:00 \_ tdeio_sftp [tdeinit] sftp /tmp/tdesocket-david/tdelauncherbcVCMs.s 752 ? S 0:00 \_ tdeio_file [tdeinit] file /tmp/tdesocket-david/tdelauncherbcVCMs.s These don't ever go away. -- David C. Rankin, J.D.,P.E.

On 03/03/2014 12:01 AM, François Andriot wrote: 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.

Le 03/03/2014 15:17, David C. Rankin a écrit : It looks like tdeio_http is a special case with hardcoded longer timeouts than the default ones. To be more precise, TDE does not lose tracks of the tdeio process. The tdeio scheduler is always aware of its slave threads. The actual problem is that the tdeio scheduler never receives the "job is finished" notification from some slaves. So it considers this slave as being eternally busy and keeps spawning new ones ... The nominal scenario looks like: 1) an application requests an URL to the tdeio scheduler (e.g. konqueror asks "directory listing for sftp://remotehost/") 2) the tdeio scheduler instantiates a "job" 3) the job looks for an idle "slave" that can do the job (e.g. correct protocol), uses one if it exists, or else asks the scheduler to instantiate a new slave. 4) the slave spawns a 3rd party process (ssh in my case) and waits for text output. (note: stheome slaves do the job directly without spawning a 3rd party process) 5) The 3rd party process does its job (remote directory listing for example) and writes output to the slave. 6) After the command is complete, the slave ceases receiving data because nothing is written anymore by the 3rd party process. 7) The slave sends "finished" to the job. 8) the job sends "finished" to the scheduler. 9) the scheduler deletes the job and puts the slave in the "idle slave list" so that it can be reused by another job, or will be killed after some minutes of idleness. What happens with my "kdirlist" problem (and probably your imap problem too), is that step 7 never occurs. For an unknown reason, the slave, after having received the correct data, never notifies the job that it has finished, then the job never notifies the scheduler, then the scheduler think the slave is still active and does not mark it as "idle" ... and here is our stale tdeioslave ... (note: the slave eventually gets killed if the remote host closes network connection for idleness ... but it looks like this does not happen with ssh protocol) I'm currently looking into the cache mechanism of the "kdirlist" job class. I believe (to be confirmed) that when kdirlist uses its internal cache, it still spawns a slave but does NOT uses it at all, since it already has the data it is looking for in its cache. Then it returns the cached data and ignores the spawned slave, which sits there forever, waiting for a query from the job that never comes ... Francois

Le 06/03/2014 06:45, David C. Rankin a écrit : Please check bug report #1902 : I've posted 2 patches there. If it's confirmed working, I'll explain what I believe is the root cause of this problem. Francois

On 03/06/2014 12:14 AM, François Andriot wrote: Francios, I have patches 1981 and 1982 for tdebase, but is there another patch for tdelibs? -- David C. Rankin, J.D.,P.E.

On 03/06/2014 12:14 AM, François Andriot wrote: Francios, I tested kioslave behavior in kde3. There are NO stale kioslave processes produced even with multiple sftp connections open in konqueror - none at all. So all of this stale tdeio mess is broken TDE behavior. Here is a screenshot and output of ps axf: http://www.3111skyline.com/dl/dt/trinity/ss/kde-konqueror-no-kioslaves.jpg 10:53 alchemy:~/cnf/mediawiki/img/bn2/128> ps axf | grep kio 8840 ? S 0:00 \_ kio_file [kdeinit] file /tmp/ksocket-david/klauncher0uEG8g.slav 24358 ? S 0:04 kio_uiserver [kdeinit] This has got to be the result of some stray k->tde rename that has messed up tdeio job/slave/scheduler communications. -- David C. Rankin, J.D.,P.E.

On 03/06/2014 03:13 PM, David C. Rankin wrote: It looks like the fix was: tdelibs/tdeio/tdeio/kdirlister.cpp - line 1974: job->slaveDone(); That would explain why #7 never got done. -- David C. Rankin, J.D.,P.E.