25 Feb
2014
25 Feb
'14
9:54 p.m.
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