26 Feb
2014
26 Feb
'14
5:38 p.m.
Dne st 26. února 2014 David C. Rankin napsal(a):
On 02/25/2014 03:54 PM, François Andriot wrote:
As I noted in the bug report: This is not a problem. Presence code for
ConsoleKit has no effect unless ConsoleKit present on system. With the
ConsoleKit communicates via D-Bus. If ConsoleKit not present, not with
whom to communicate => code has no effect == same as it was not used.
--
Slavek
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? 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