On 02/25/2014 03:54 PM, François Andriot wrote:
> 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.
> 
> 
> Francois

You are a genius! (or at least are a LOT better a following rabbit trails than I)

If you have not looked into what the
kde-workspace-4.11.0-kdm-logind-multiseat.patch does, it may hold the key to
part of the problem. I have been looking through the tdebase/tdm/backend files
(as suggested by the patch). I may have been looking in the wrong place, but
since I was NOT getting a proper user session tracking response from loginctl
show-session $XDG_SESSION_ID response, that is where the freedesktop.org
migration links and the patch suggested starting.

Could the fact that tdelauncher is NOT receiving the "emit accepted" signal
point to a problem with basic session/process tracking described in the
freedesktop.org pages? What they suggest is unless TDE (or any desktop that used
consolekit) meets the requirements (1-4 listed in the bug), then interprocess
communication regarding sessions and processes is not guaranteed to work
properly. My thought is the "emit accepted" problem is the result of that issue.
We will have to further look to see if any of the tdebase/tdm/backend code is
involved between that signal/slot communication, that may be where the problem is.

Good catch on the idleTimout. I will try and look at both the mSaveList and
idleTimeout code, but I can't promise to be nearly as quick or as helpful in
sorting it out. Pass along anything you would like me to test on Arch. I'm more
than happy to patch/build/test anything on my end as well.



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