|
Description
David C. Rankin
2014-02-02 18:27:50 CST
The error is coming from ksshprocess.cpp:
ksshprocess.cpp:258: if( pclose(p) == -1 ) {
ksshprocess.cpp:259: kdError(KSSHPROC) << "KSshProcess::version(): pclose failed." << endl;
I don't know where it originates before that.
This may have to do with a user-session tracking issue resulting for systemd starting tdm. Apparently, in order for proper session tracking to occur, X must run on the same tty where the login occurred in order for logind to properly track sessions. To verify proper configuration, you check: $ loginctl show-session $XDG_SESSION_ID If the configuration is correct, you will find Remote=no and Active=yes among the output. However with TDE, you get the following: 08:29 valhalla:~> loginctl show-session $XDG_SESSION_ID NAutoVTs=6 KillExcludeUsers=root KillUserProcesses=no IdleHint=yes IdleSinceHint=0 IdleSinceHintMonotonic=0 InhibitDelayMaxUSec=5s HandlePowerKey=poweroff HandleSuspendKey=suspend HandleHibernateKey=hibernate HandleLidSwitch=suspend IdleAction=ignore IdleActionUSec=30min PreparingForShutdown=no PreparingForSleep=no I have posted to the Arch list to get help from the Arch side. Faulty session tracking may be the cause of tdeio failing to close sftp sessions after they are started and may also contribute to the user having no access to sound unless added to the audio group. Apparently the lack of starting the login on the same vt as running X also effects polkit and the ability to control device access permissions. However, this may be all for naught. I cannot see how tdm could be providing login on other than vt7 where X is running. In that case, this issue is still a tdeioslave/sftp issue. This bug has been further discussed and confirmed for distros running pure systemd in the thread: [trinity-devel] TDE running on systemd will require code changes proper session tracking? As referenced above, the required freedesktop standards needed to accommodate pure systemd session tracking are detailed in: http://www.freedesktop.org/wiki/Software/systemd/writing-display-managers/ http://www.freedesktop.org/wiki/Software/systemd/writing-desktop-environments/ While the porting requirements seem to require a minimal or little change to TDE code, a solution is needed for TDE or user session/process tracking completely fails in a pure systemd setup without consolekit. At a minimum, the porting requirements (without multiseat) recommended by freedesktop are: 1. Remove/disable all code responsible for registering your service with ConsoleKit. 2. Make sure to register your greeter session via the PAM session stack, and make sure the PAM session modules include pam_systemd. Also, make sure to set the session class to "greeter." This may be done by setting the environment variable XDG_SESSION_CLASS to "greeter" with pam_misc_setenv() or setting the "class=greeter" option in the pam_systemd module, in order to allow applications to filter out greeter sessions from normal login sessions. 3. Make sure to register your logged in session via the PAM session stack as well, also including pam_systemd in it. 4. Optionally, use pam_misc_setenv() to set the environment variables XDG_SEAT and XDG_VTNR. The former should contain "seat0", the latter the VT number your session runs on. pam_systemd can determine these values automatically but it's nice to pass these variables anyway. In summary: porting a display manager from ConsoleKit to systemd primarily means removing code, not necessarily adding any new code. Here, a cheers to simplicity! It is worse than initially reported. It doesn't just effect fringe tdeio_slaves like the sftp tdeio_slave it effects *ALL* tdeio_slaves, including tdeio_file and tdeio_http. I browsed in konqueror looking for configuration help and help with a python error and I had 50+ tdeio_file and tdeio_http processes like the following: ... tdeio_file [tdeinit] file /tmp/tdesocket-david/tdelauncher0fCUxj.s tdeio_file [tdeinit] file /tmp/tdesocket-david/tdelauncher0fCUxj.s tdeio_file [tdeinit] file /tmp/tdesocket-david/tdelauncher0fCUxj.s tdeio_http [tdeinit] https /tmp/tdesocket-david/tdelauncher0fCUxj. tdeio_http [tdeinit] https /tmp/tdesocket-david/tdelauncher0fCUxj. ... Apparently with every http connection, including browser search, a tdeio_file slave is also opened to check/update the cache entries in addition to the tdeio_http slave opened for the connection, so this will spin out of control quickly with internet browsing. I believe that this problem is not related to the registration of systemd session. I notice the same problems on Debian Wheezy (systemd is not present, consolekit on board). It seems to me that the same problems were observed with connection to bug 1656. Created attachment 1942 [details] kde4 kdm logind multiseat patch implementing pure systemd fix This is the patch implemented on kde4 that fixes the systemd user session/process tracking issue with a multi-seat approach. The kde.org review board page for the patch is here: kde-workspace-4.11.0-kdm-logind-multiseat The development history for the patch is found here: https://bugzilla.redhat.com/show_bug.cgi?id=975079 https://bugzilla.redhat.com/show_bug.cgi?id=884271 (In reply to comment #7) > Created attachment 1942 [details] > kde4 kdm logind multiseat patch implementing pure systemd fix > > This is the patch implemented on kde4 that fixes the systemd user > session/process tracking issue with a multi-seat approach. The kde.org review > board page for the patch is here: > > kde-workspace-4.11.0-kdm-logind-multiseat > > The development history for the patch is found here: > > https://bugzilla.redhat.com/show_bug.cgi?id=975079 > https://bugzilla.redhat.com/show_bug.cgi?id=884271 The correct kde.org review board location is here: https://git.reviewboard.kde.org/r/112294/ and the patch download link is: https://git.reviewboard.kde.org/r/112294/diff/raw/ For those wanting to help, compared to the logind listing contained in [comment 3], successful user/process tracking will be indicated in the output of 'loginctl show-session $XDG_SESSION_ID' by the parameters: Active=yes Remote=no With proper user/process tracking the output of the command will look similar to that provided by Slavek running systemd+consolekit on (saucy): $ loginctl show-session $XDG_SESSION_ID Id=c4 Timestamp=Thu 2014-01-30 20:31:22 CET TimestampMonotonic=267801422 DefaultControlGroup=systemd:/user/1000.user/c4.session VTNr=7 Display=:0 Remote=no Service=tdm-trinity Leader=1807 Audit=0 Type=x11 Class=user Active=yes State=active KillProcesses=no IdleHint=no IdleSinceHint=0 IdleSinceHintMonotonic=0 Name=axis Should tdebase/tdescreensaver.pamd be updated to: auth required pam_unix_auth.so Hello, I'm running a consolekit-free distribution (Mageia 4). I have the problem with stale tdeio_XXX processes as you describe, but I don't see why it's related to Systemd. It looks like my session is correctly seen by Systemd : $ loginctl show-session $XDG_SESSION_ID Id=1 Timestamp=jeu. 2014-02-20 21:01:46 CET TimestampMonotonic=14146902 VTNr=7 Display=:0 Remote=no Service=tdm-trinity Scope=session-1.scope Leader=984 Audit=1 Type=x11 Class=user Active=yes State=active IdleHint=no IdleSinceHint=0 IdleSinceHintMonotonic=0 Name=francois (In reply to comment #11) > Hello, I'm running a consolekit-free distribution (Mageia 4). > > I have the problem with stale tdeio_XXX processes as you describe, but I don't > see why it's related to Systemd. > > It looks like my session is correctly seen by Systemd : > > $ loginctl show-session $XDG_SESSION_ID > Id=1 > Timestamp=jeu. 2014-02-20 21:01:46 CET > TimestampMonotonic=14146902 > VTNr=7 > Display=:0 > Remote=no > Service=tdm-trinity > Scope=session-1.scope > Leader=984 > Audit=1 > Type=x11 > Class=user > Active=yes > State=active > IdleHint=no > IdleSinceHint=0 > IdleSinceHintMonotonic=0 > Name=francois That is impressive - what is your /etc/pam.d config? I think that may be part of the solution, but this is a systemd issue. The solution is described in the freedesktop.org links above. There will be some additions to the TDE code needed (or possibly, just fixing the preprocessor checks surrounding the consolekit code) Created attachment 1957 [details]
port of kde4-workspace logind multiseat patch to TDE
This is a port of the kde-workspace-4.11.0-kdm-logind-multiseat.patch to TDE tdebase code. The patch was applied manually in the exact context provided by the kde4 patch. It can be applied with
cd tdebase
patch -Np1 -i tdebase-tdm-logind-multiseat_02.patch
It is currently building on my test machine, I'll report back.
It looks like more work is needed. WITH_CONSOLE_KIT is hard-coded in tdebase/tdm/backend/dm.h: #define WITH_CONSOLE_KIT So all builds are building as if consolekit is present (In reply to David C. Rankin from comment #14) > It looks like more work is needed. WITH_CONSOLE_KIT is hard-coded in > tdebase/tdm/backend/dm.h: > > #define WITH_CONSOLE_KIT > > So all builds are building as if consolekit is present This is not a problem. Presence code for ConsoleKit has no effect unless ConsoleKit present on system - at runtime. Created attachment 1962 [details]
port of kde4-workspace logind multiseat patch to TDE
This is an updated patch that sets the WITH_SYSTEMD preprocessor flag
The use of add_definitions(-DWITH_SYSTEMD) should mandate that all the systemd code is built. However, after rebuilding, I do not notice any difference in tdebase/tdm. loginctl show-session $XDG_SESSION_ID still lacks Active=yes and Remote=yes and I still have numerous unclosed tdeio_sftp tdeio_file tdeio_http connections littering my system. The patch applies correctly: ==> apply logind multiseat patch to tdm patching file cmake/modules/FindSystemd.cmake patching file CMakeLists.txt patching file ConfigureChecks.cmake patching file tdm/backend/client.c patching file tdm/backend/CMakeLists.txt patching file tdm/backend/dm.c patching file tdm/backend/dm.h patching file tdm/backend/server.c patching file tdm/backend/session.c systemd is found by cmake: -- Found systemd -- ***** Systemd preprocessor flag WITH_SYSTEMD set ***** The TDM files are compiled and linked without any error other than: Scanning dependencies of target tdm [ 71%] Building C object tdm/backend/CMakeFiles/tdm.dir/access.c.o cc1: warning: command line option '-fvisibility-inlines-hidden' is valid for C++/ObjC++ but not for C [enabled by default] <snip> Linking C executable tdm [ 72%] Built target tdm I would expect to see some difference in TDE behavior, but at this point, I don't. I tried on a test machine with Debian 6.0 (Squeeze) alternately run konqueror in many ways. On many startups, open folders, reload window content,... I see more and more tdeio_* processes. The terminating tdeio_* processes thereafter was very very slow. Some, it seems to have no end. This would correspond to behavior that is described in this bug report, and the fact that François describes in the mail http://trinity-devel.pearsoncomputing.net/?0::13014 Well, now note that Debian 6.0 (Squeeze) is completely free of systemd. The same problem was mentioned in connection with the bug 1656 - observations on Slackware - again without systemd on board. That I believe I can repeat here what I have said many times before: Problem described in this bug report has absolutely no connection to systemd! OK, I believe you, the connection to user processes tracking and the exhibited behavior was one whale of a coincidence. Here are the note from Francios that I think are at the heart of the issue: Both on Mageia 4 and openSUSE 13.1, there is no TDM specific configuration file for systemd. The distribution use a generic "dm.service" or "xdm.service" systemd unit, which in turns run a wrapper script that chooses among GDM/KDM/TDM/... I think (not checked yet) that there is some magic in there, which allows using any DM in a systemd-only distribution. Now about the "stale tdeio_xxxx" processes. I've read the source code in "tdelibs/tdeinit/tdelauncher.cpp". From what I understand (I've added lots of debug output to find out): 1) The tdelauncher class is initialized line 165. It runs a TDEServerSocket (line 197) and binds a signal "accepted" with slot "acceptslave" (line 198). 2) The tdeserversocket is instanciated in "tdelibs/tdecore/ksock.cpp" (line 287). Then it calls "init()" line 305, then "bindAndListen()" line 333. It binds an "activated" signal to "slotAccept" slot. slotAccept() line 404 in turns does the "emit accepted" line 420. 3) back to "tdelauncher.cpp", the acceptSlave() slot does the following action: mSlaveList.append(slave) line 1360. => the tdelauncher keeps a reference of the tdeioslave in a list. (mSlaveList) This list is used to know which tdeio_xxx processes are already running. 4) Whenever konqueror opens an URL, it calls the "TDELauncher::requestSlave" (line 1245). This function checks if there is an already idle tdeioslave (by parsing the "mSlaveList"), and then reuses it if appropriate (same requested protocol, same host ...). If no available idle tdeioslave is there, it spawns a new one. After adding lots of kddebug output, I've found that, on my system, we go correctly from step 1 to step 2: The "emit accepted" is run correctly every time. However, for an unknown reason, this signal is NOT received by the tdelauncher, so the "acceptslave" slot is NEVER run. Then, the "mSlaveList" variable is never populated. As a consequence, the tdelauncher NEVER reuses an existing tdeioslave, it spawns a new one every time. Also, the "idleTimeout" slot (line 1404) does nothing at all, since there is no process to terminate in the mSlaveList ! The actual question is: why is the "emit accepted" signal never received ??? It causes lots of troubles. I also note that in tdelauncher.cpp, there is a max idle time for the processes that is being ignored: line 61: // Dispose slaves after being idle for SLAVE_MAX_IDLE seconds #define SLAVE_MAX_IDLE 30 Slavek, What I don't want to get lost in not embracing the multiseat patch, is that in addition to the tdeio issue (which I know is not multiseat), I have NO access to sound, to user mount/unmount or any of the other services in TDE that consolekit provided auth for. This is why the multiseat (or single seat) fix is so important. Francios has the correct loginctl XDG_SESSION_ID response perhaps provided by the wrapper that is launching tdm, but absent implementing multiseat, that stuff does NOT work on Arch. That was what I am looking for the multiseat patch to do. With the patch above integrated into TDE, there is no reason not to move forward with that patch as well. Perhaps for 14.0.1 if it cannot make it into 14.0.0, but we have to find some solution to the user session problem or any distro that uses clean-systemd (without some tdm wrapper magic) will have no sound or any ability to use usb, etc.. I would like to see the tdeio fix for R14 and at least your dbus/dcop solution for user session tracking. That would provide a usable TDE for those without consolekit and fix all the hung/abandoned tdeio processes. I'm doing more testing tonight on what Francios found regarding the emit_accepted problem, idle_timeout, etc.. Slavek, Francios One more issue with the tdeio_slaves failing to close is if kmail is left open, the automatic checks for new mails done every 10 minutes or so, will cause the mail server to begin rejecting connections after its anvil connection limit is reached (due to the imap connections never being closed): This was from my mail server after I began getting imap connection rejects: (all of those logins are from kmail that are stuck open) 953 ? Ss 0:29 /usr/sbin/dovecot 1087 ? S 0:05 \_ dovecot/anvil 1088 ? S 0:05 \_ dovecot/log 15680 ? S 0:09 \_ dovecot/config 31108 ? S 0:05 \_ dovecot/imap-login 31112 ? S 0:11 \_ dovecot/imap 1022 ? S 0:04 \_ dovecot/imap-login 1026 ? S 0:06 \_ dovecot/imap 20731 ? S 0:01 \_ dovecot/imap-login 20737 ? S 0:02 \_ dovecot/imap 21919 ? S 0:00 \_ dovecot/imap-login 21921 ? S 0:01 \_ dovecot/imap 23254 ? S 0:00 \_ dovecot/imap-login 23255 ? S 0:01 \_ dovecot/imap 25991 ? S 0:00 \_ dovecot/imap-login 25993 ? S 0:01 \_ dovecot/imap 32553 ? S 0:00 \_ dovecot/imap-login 32557 ? S 0:01 \_ dovecot/imap 15881 ? S 0:00 \_ dovecot/imap-login 15883 ? S 0:00 \_ dovecot/imap 16677 ? S 0:00 \_ dovecot/imap-login 16678 ? S 0:00 \_ dovecot/imap 19776 ? S 0:00 \_ dovecot/imap-login 19780 ? S 0:00 \_ dovecot/imap 23531 ? S 0:00 \_ dovecot/imap-login 23535 ? S 0:00 \_ dovecot/imap 23537 ? S 0:00 \_ dovecot/imap-login 23538 ? S 0:00 \_ dovecot/imap Additionally, there is a systemd-coredump associated with tdecontrol screensaver: Mar 01 22:29:29 valhalla systemd-coredump[1780]: Process 1775 (kflux.kss) dumped core. This may be related to the requirement that the screensaver register with the pam_stack in a pure-systemd environment. That's the only thing that stands out. Why else would a screensaver crash cause a systemd-coredump? Created attachment 1972 [details]
Mageia 4 : display manager unit for systemd
Created attachment 1973 [details]
Mageia 4 : display manager startup script
Note that my current preference file /etc/sysconfig/desktop, which is used by this script, currently contains the line:
DISPLAYMANAGER=TDM
Created attachment 1974 [details]
Mageia 4 : display manager lookup script
This script is named '/etc/X11/lookupdm'
Created attachment 1975 [details]
Mageia 4 : TDM configuration file for Mageia display manager script
This file was written by me explicitely for Mageia 4.
It goes to:
/usr/share/X11/dm.d/45TDE.conf
Created attachment 1976 [details]
Mageia 4 : TDE session template for Display Managers
This file is used as a template for starting TDE session.
Mageia 4 configuration tools then generate session configurations for GDM, KDM, or any other DM installed on the desktop.
It goes to:
/etc/X11/wmsession.d/45TDE
Then the "chksession" command found in "/usr/share/X11/dm.d/45TDE.conf" configuration file generates the following file:
/usr/share/xsessions/45TDE.desktop
Then TDM uses all files found under /usr/share/xsessions .
Alas, I don't see any systemd trickery in the Mageia 4 scripts ... I still have no idea why it works here and not on your side ... :'( Created attachment 1980 [details]
tdelibs : fix stale tdeioslave spawned by kdirlister
Please, try the attached patch to see if it solves your issue with tdeio_sftp .
Created attachment 1981 [details]
tdelibs : fix stale tdeioslave spawned by kdirlister (2)
Updated patch to fix signal/slot in "forwardingslavebase"
Created attachment 1982 [details]
tdebase : fix localURL signal
This patch is useful in tdebase if you have applied previous patch in tdelibs.
I tried both patches. Browse local folders works perfectly. However, when I went through the same folders through media:/*, opening each folder lead to the start of two new tdeio processes. Termination of these processes was subsequently very very slow. Some, it seems to have no end. (In reply to Slávek Banko from comment #31) > I tried both patches. Browse local folders works perfectly. However, when I > went through the same folders through media:/*, opening each folder lead to > the start of two new tdeio processes. Termination of these processes was > subsequently very very slow. Some, it seems to have no end. Do you mean this behaviour is caused by the patches I posted ? Normally, the patches can only affect the behaviour of remote URL, not local URL ... On my side, I noticed that the "tdeio_file" are always spawned numerous at once, and it was already in 3.5.13.2 ! E.g. when opening "konqueror web browser" from the start menu, it shows up the konqueror welcome page (blue background with message "conquer your desktop"). At this point, there are already 4 tdeio_file ! When starting kmail, it runs 2 tdeio_file ... These processes are not staled, they end up being closed normally. I'm not sure if this is intended or not, maybe someone can try in KDE3 to see what happens there. (In reply to Francois Andriot from comment #32) > (In reply to Slávek Banko from comment #31) > > I tried both patches. Browse local folders works perfectly. However, when I > > went through the same folders through media:/*, opening each folder lead to > > the start of two new tdeio processes. Termination of these processes was > > subsequently very very slow. Some, it seems to have no end. > > Do you mean this behaviour is caused by the patches I posted ? > Normally, the patches can only affect the behaviour of remote URL, not local > URL ... > > On my side, I noticed that the "tdeio_file" are always spawned numerous at > once, and it was already in 3.5.13.2 ! > > E.g. when opening "konqueror web browser" from the start menu, it shows up > the konqueror welcome page (blue background with message "conquer your > desktop"). At this point, there are already 4 tdeio_file ! > When starting kmail, it runs 2 tdeio_file ... > These processes are not staled, they end up being closed normally. > > I'm not sure if this is intended or not, maybe someone can try in KDE3 to > see what happens there. No, this behavior I observed earlier. I tried, if this patches fix also this behavior. Incidentally, the processes from previous test are still running - after several hours of inactivity. (In reply to Francois Andriot from comment #32) > (In reply to Slávek Banko from comment #31) > > I tried both patches. Browse local folders works perfectly. However, when I > > went through the same folders through media:/*, opening each folder lead to > > the start of two new tdeio processes. Termination of these processes was > > subsequently very very slow. Some, it seems to have no end. > > Do you mean this behaviour is caused by the patches I posted ? > Normally, the patches can only affect the behaviour of remote URL, not local > URL ... > > On my side, I noticed that the "tdeio_file" are always spawned numerous at > once, and it was already in 3.5.13.2 ! > > E.g. when opening "konqueror web browser" from the start menu, it shows up > the konqueror welcome page (blue background with message "conquer your > desktop"). At this point, there are already 4 tdeio_file ! > When starting kmail, it runs 2 tdeio_file ... > These processes are not staled, they end up being closed normally. > > I'm not sure if this is intended or not, maybe someone can try in KDE3 to > see what happens there. Franscio, I have kde3 (SuSE) running. I can confirm all of this tdeio mess is BROKEN TDE behavior. There are NO stale kio processes in kde. Here is a kde3/konqueror screenshot showing 2 open sftp connections with NO stale kioslaves: http://www.3111skyline.com/dl/dt/trinity/ss/kde-konqueror-no-kioslaves.jpg As ps axf of kio shows no stale slaves anywhere: 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] Hey, I've just installed opensuse 13.1 in virtual machine, then opensuse-kde3. Test 1: running command "konqueror about:konqueror" (to display the konqueror welcome page), I get the 4 kio_file processes exactly like TDE gets 4 tdeio_file ... Test 2: running command "konqueror ~" (to open home directory). Under KDE3, I get only one kio_file . Under TDE, I have two tdeio_file . Something is still wrong here (but the stale process is killed after some minutes) Francios, I think your patches fixed the tdeio_sftp problem. I just installed and opened konqueror and checked my remote tde files with sftp and I do not have any stale tdeio_slave processes left over -- good job! After testing konqueror(about) and checking the remote hosts, I have: 15:03 valhalla:~> ps axf | grep tdeio 3172 pts/3 S+ 0:00 | \_ grep tdeio 3158 ? S 0:00 \_ tdeio_file [tdeinit] file /tmp/tdesocket-david/tdelauncheroC3iIf.s 3159 ? S 0:00 \_ tdeio_about [tdeinit] about /tmp/tdesocket-david/tdelauncheroC3iIf 3160 ? S 0:00 \_ tdeio_sftp [tdeinit] sftp /tmp/tdesocket-david/tdelauncheroC3iIf.s I'll continue looking at the logs, but first looks are promising. The user session tracking XDG_SESSION_ID output still fails: NAutoVTs=6 KillExcludeUsers=root KillUserProcesses=no IdleHint=yes IdleSinceHint=0 IdleSinceHintMonotonic=0 InhibitDelayMaxUSec=5s HandlePowerKey=poweroff HandleSuspendKey=suspend HandleHibernateKey=hibernate HandleLidSwitch=suspend IdleAction=ignore IdleActionUSec=30min PreparingForShutdown=no PreparingForSleep=no François, please, I should to push the current patches or wait, if you manage to solve the remaining problems? (In reply to Slávek Banko from comment #37) > François, please, I should to push the current patches or wait, if you > manage to solve the remaining problems? I think that the remaining problems are not related to the current one. So I'd say you can push, if everyone agrees ... Comment on attachment 1981 [details]
tdelibs : fix stale tdeioslave spawned by kdirlister (2)
Pushed to GIT in hash 6f561820.
Comment on attachment 1982 [details]
tdebase : fix localURL signal
Pushed to GIT in hash 6cfb2ba0.
The above mentioned problems tdeio_file, tdeio_media and possibly others will be addressed in the context of this bug report or to open a new one? (In reply to David C. Rankin from comment #34) > (In reply to Francois Andriot from comment #32) > > (In reply to Slávek Banko from comment #31) > > > I tried both patches. Browse local folders works perfectly. However, when I > > > went through the same folders through media:/*, opening each folder lead to > > > the start of two new tdeio processes. Termination of these processes was > > > subsequently very very slow. Some, it seems to have no end. > > > > Do you mean this behaviour is caused by the patches I posted ? > > Normally, the patches can only affect the behaviour of remote URL, not local > > URL ... > > > > On my side, I noticed that the "tdeio_file" are always spawned numerous at > > once, and it was already in 3.5.13.2 ! > > > > E.g. when opening "konqueror web browser" from the start menu, it shows up > > the konqueror welcome page (blue background with message "conquer your > > desktop"). At this point, there are already 4 tdeio_file ! > > When starting kmail, it runs 2 tdeio_file ... > > These processes are not staled, they end up being closed normally. > > > > I'm not sure if this is intended or not, maybe someone can try in KDE3 to > > see what happens there. > > Franscio, > > I have kde3 (SuSE) running. I can confirm all of this tdeio mess is BROKEN > TDE behavior. There are NO stale kio processes in kde. Here is a > kde3/konqueror screenshot showing 2 open sftp connections with NO stale > kioslaves: > > http://www.3111skyline.com/dl/dt/trinity/ss/kde-konqueror-no-kioslaves.jpg > > As ps axf of kio shows no stale slaves anywhere: > > 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 might be causing some of the problems I am noticing while working on Bug 1666. Any chance of you or Darrell running a regression test for me? I suspect the problem might have been introduced in tdelibs/tdebase last spring (i.e. somewhere between January and April 2013) but have not tested this yet. Thanks! Tim The problem I've found out was in this commit: http://git.trinitydesktop.org/cgit/tdelibs/commit/tdeio/tdeio/kdirlister.cpp?id=4d6667159ef183f83e64ed0c8479162dc5629951 Look after line 1907. Previously in "KDirLister::openURL", there was a "sleep loop", waiting for a slave job to finish, before continuing. Then, the loop was replaced by a signal/slot mechanism. The kdirlister::openURL code is now split into 2 parts: - the first part spawns a slave job, connects to the "finished" signal that will be emitted on completion, and returns. This code is the part that was BEFORE the sleep loop. - the second part is the slot that is run when the slave job emit "finished". This code is the part that was AFTER the sleep loop. I've found out that splitting the code is causing the tdeio scheduler to somehow lose track of its childs, leaving some of them in a staled state (this is what this bug report is talking about). It looks like having a connect signal/slot is preventing some objects from being automatically destroyed on returning... That's why, in attachment #1981 [details], I explicitely added the "slaveDone" call in the slot code, so that the slave job is explicitely terminated. Also, I had to change the "job" class to "localUrlJob" in several locations because "slaveDone" does not exist for "job". I've found out that the strange "sleep" loop is also present (copy/paste code ??) in the konqueror context menu. (See attachment #1982 [details] for the approximate location) I have the feeling that, before using the signal/slot mechanism, some things used to work in TDE but we did not know how ... Thanks for the information! It looks like bug 1666 was partially caused by the patch in attachment #1981 [details] ; can you please look at bug 1666 and see if there is a better way to fix it than my sledgehammer patch? Thanks! Created attachment 2032 [details] tdelibs : fix the stale "localurl" jobs Another attempt (since previous patch was reverted in bug #1666) to fix the stale tdeioslave issues here. What I found this time: It looks like the tdeio jobs of type "localurljob", which are invoked by the kdirlister, are never terminated by the TDEIO scheduler, and remain staled forever. This results in having many, many processes "tdeio_xxx" running and never ending. I've found that the slave process that is spawned by the "localurljob" never sends the "finished" message to its job after sending the "localurl" signal. This causes the job to finish correclty (e.g. displaying the items in konqueror), but leaving a stale slave behind it, which in turns prevents the job itself to finish correctly. This scenario is even worse when using "forwardedslave" type of tdeioslave, such as tdeio_media, because each tdeio_media spawns a tdeio_file, and they both become staled with their associated jobs ... The attached patch simply makes the slave emit the "finished" signal immediatly after it sends the "localurl" to the localurljob. I've read the scheduler/job/slave code several times and this patch should be safe in all current use cases. I've found no regression on local storage media ioslave (bug #1666) and fish ioslave (this bug). Please, test carefully and report back. (In reply to Francois Andriot from comment #43) Still, I do NOT understand how this stuff could work in 3.5.13.2 and previous versions of TDE/KDE3 ... I'm 99% sure that having split the "kdirlister::openURL" code in 2 separate functions, connected through the signal/slot mechanism, has caused this bug to appear; but even before this split, it should'nt have worked anyway ... My only hypothesis is that there were some implicit C++ object destruction that were triggered upon leaving the "kdirlister::openURL". That would explain why the original coded attempted to do ALL the job in a single function, with dirty loop in the middle, instead of using the nicer signal/slot mechanism. Now I still have an issue even after the patch. MAYBE this issue existed in 3.5.13.2 already, I'm not sure. You can reproduce it easily with network-protocol ioslave like fish, but in fact it occurs for every types, but some ioslaves are so fast that you won't see it. The problem is that the "KDirLister::openURL" always spawns 2 identical tdeioslaves when using non-local URL. Don't panic, they are correctly managed by the scheduler and they both end up dying after some time, so this is normally not a big deal. The problem is that some remote servers are limiting the number of concurrent connections. What if the remote SSH server is limiting me to a single connection ? In that scenario, the tdeio_fish won't work because the 2nd ioslave will get a "connection refused". This was exactly why I added the "job->slaveDone()" in the first place. The purpose was to explicitely disconnect the slave from the 1st job BEFORE the 2nd job is created, so that the latter can reuse the now-available slave. But it does not work anymore after the new patch, so I'll have to investigate more ... (In reply to Francois Andriot from comment #45) > Created attachment 2032 [details] > tdelibs : fix the stale "localurl" jobs > > Another attempt (since previous patch was reverted in bug #1666) to fix the > stale tdeioslave issues here. Thus far in my testing the directory traversal issue has been fixed, but the top level media:/ URL is completely blank in Konqueror. Strangely the media desktop icons still work. Did you notice anything like this in your testing? I am wondering if something else broke or if the failure is a result of this patch. Thanks! Strangely it seems to work the first time in konqueror, then simply reload the page (F5) , ang I too get a blank listing on media:/ URL ... I can see an error with the tdeioslave traces, I'll have a look at it again ... (In reply to Francois Andriot from comment #49) > Strangely it seems to work the first time in konqueror, then simply reload > the page (F5) , ang I too get a blank listing on media:/ URL ... > > I can see an error with the tdeioslave traces, I'll have a look at it again > ... Any progress on this? Marking NEEDINFO pending response from Francois David, if I were to commit these patches as-is right now, would existing functionality break? I am concerned about bit-rot of the patches themselves, and in any case it is far easier to resolve small bugs in new unused functionality once the bulk of the functionality is already committed. Thanks! (In reply to Timothy Pearson from comment #51) > Marking NEEDINFO pending response from Francois > > David, if I were to commit these patches as-is right now, would existing > functionality break? I am concerned about bit-rot of the patches > themselves, and in any case it is far easier to resolve small bugs in new > unused functionality once the bulk of the functionality is already committed. > > Thanks! Please do not push the patch from attachment 1962 [details] - for systemd MultiSeat. 1) This patch has no connection with this bug. 2) Base support for systemd is already included (TDM, KDesktop, TDEpowersave). 3) Instead of linking functions sd_* I prefer to use d-bus interface that keeps systemd as an option - just like is consolekit. By the way, the original patch for KDE4 is still under review and is not pushed into KDE4. (In reply to Slávek Banko from comment #52) > (In reply to Timothy Pearson from comment #51) > > Marking NEEDINFO pending response from Francois > > > > David, if I were to commit these patches as-is right now, would existing > > functionality break? I am concerned about bit-rot of the patches > > themselves, and in any case it is far easier to resolve small bugs in new > > unused functionality once the bulk of the functionality is already committed. > > > > Thanks! > > Please do not push the patch from attachment 1962 [details] - for systemd > MultiSeat. > > 1) This patch has no connection with this bug. > 2) Base support for systemd is already included (TDM, KDesktop, > TDEpowersave). > 3) Instead of linking functions sd_* I prefer to use d-bus interface that > keeps systemd as an option - just like is consolekit. > > By the way, the original patch for KDE4 is still under review and is not > pushed into KDE4. Thank you, that is exactly what I needed to know. Tim Created attachment 2084 [details] tdelibs : fix stale "localurl" jobs (2) I've done research and testing, and it seems that I found the solution! media:/ URL works correctly, processes tdeio_fish do not breed and overall tdeio_* processes are completed very swiftly. It looks promising. Please can someone test if this solution does not cause regression of bug 1666? Comment on attachment 2084 [details] tdelibs : fix stale "localurl" jobs (2) I tried to test mounting, as described in bug 1666. And I have found no regression. Pushed to GIT in hash 13d6174c. Comment on attachment 1942 [details]
kde4 kdm logind multiseat patch implementing pure systemd fix
Unrelated to this bug.
Comment on attachment 1962 [details]
port of kde4-workspace logind multiseat patch to TDE
Unrelated to this bug.
Because support for systemd MultiSeat has no connection with this bug (was moved to separate bug 1998), I close this bug report as resolved. |
