Dne st 26. února 2014 David C. Rankin napsal(a): > On 02/25/2014 03:54 PM, François Andriot wrote: > > 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 > > 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? 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