Message: previous - next
Month: February 2014

Re: [trinity-devel] Bug 1902 - pam.d and preprocessor checks surrounding consolekit may be part of issue

From: "David C. Rankin" <drankinatty@...>
Date: Wed, 26 Feb 2014 11:34:45 -0600
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
>> auth       requisite
>> 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
>>    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


  One problem that I've found is WITH_CONSOLE_KIT is hard-coded in
tdebase/tdm/backend/dm.h (line 40):


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.