26 Feb
2014
26 Feb
'14
5:34 p.m.
On 02/25/2014 03:54 PM, François Andriot wrote:
Le 25/02/2014 20:53, David C. Rankin a écrit :
Francios,
One problem that I've found is WITH_CONSOLE_KIT is hard-coded in
tdebase/tdm/backend/dm.h (line 40):
#define WITH_CONSOLE_KIT
So all builds are building as if consolekit is present even if consolekit is NOT
installed. How do we wrap this define in a conditional check so WITH_CONSOLE_KIT
is only defined if consolekit is actually present?
--
David C. Rankin, J.D.,P.E.
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