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? -- David C. Rankin, J.D.,P.E.