On 03/06/2014 12:14 AM, François Andriot wrote: > Le 06/03/2014 06:45, David C. Rankin a écrit : >> On 03/03/2014 02:06 PM, François Andriot wrote: >>> [...] >> Francois, >> >> I'll say it again, "you're good!" >> >> Is the slave in #7 actually sending the "finished" and it never makes it to >> the job? Or is it not sending "finished" at all? >> >> Is there any possibility that #7 does not occur because the slave does not >> know where to send "finished"? What links/connects the slave to the job? Is it a >> signal/slot, or some memory address that the job originally passed to the slave >> in #3? Or does the slave just generate the "finished" and pass some type of job >> number along with it after #6?? >> >> Could the slave/job connection created in #3 be broken somehow such that the >> reverse path in #7 no longer exits after the delay in #6? >> > > > 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 > 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.