Le 25/02/2014 20:53, David C. Rankin a écrit :
>
> Thank you Francios,
>
>    On Arch the only pam file was /etc/pam.d/trinity:
>
> /etc/pam.d/trinity
> #%PAM-1.0
>
> auth       required     pam_securetty.so
> auth       requisite    pam_nologin.so
> auth       include      system-local-login
> account    include      system-local-login
> session    include      system-local-login
>
>    I updated it to test the Arch kde4 /apm file:
> #%PAM-1.0
>
> auth            include         system-login
> account         include         system-login
> password        include         system-login
> session         include         system-login
>
>    However, that made no difference (system-local-login is just an alias of
> system-login). There was no 'kdescreensaver' in the Arch TDE install, so I
> created a 'tdescreensaver' pam file:
>
> /etc/pam.d/tdescreensaver
> #%PAM-1.0
>
> auth            required        pam_unix_auth.so
>
>    Again, it made no difference. I have poked around the mkpamserv executable and
> think I can patch it for arch to generate the tdescreensaver file on tdebase
> install, but I'm still not clear on how/where in the code to insure the name
> 'tdescreensaver' will be recognized as a pam file by the system. (the
> inter-workings of pam are a learning experience as well). I'll test with your
> config and report back. If you get the process tracking figured out, let me
> know. Thanks.
>
>

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