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