24 Feb
2014
24 Feb
'14
8:34 p.m.
Francios, All,
I wanted to take this discussion out of bug 1902 temporarily to see if we
cannot further the issue on list. According to the freedesktop links for
accommodating clean-systemd (consolekit free) user session/process tracking, one
of the tests to establish if session tracking is active is to check:
$ loginctl show-session $XDG_SESSION_ID
Id=1
Timestamp=jeu. 2014-02-20 21:01:46 CET
TimestampMonotonic=14146902
VTNr=7
Display=:0
Remote=no
Service=tdm-trinity
Scope=session-1.scope
Leader=984
Audit=1
Type=x11
Class=user
Active=yes
State=active
IdleHint=no
IdleSinceHint=0
IdleSinceHintMonotonic=0
Name=francois
for the presence of 'Remote=no' and 'Active=yes'. Francios reports that he
is
using a consolekit free environment and has provided the output above which
indicates that session tracking is active on his install -- BUT -- he is
experiencing the exact same problems with tdeio_sftp /file/http/ connection
being left open on his install. I have been making very slow progress
understanding what is going on. I think in Francios case he has established
proper 'user session tracking' showing that session tracking can with in TDE in
this case without code changes. However, I think it is the 'user process
tracking' part that is not working and causing the tdeio process to remain open.
What we need to establish is what config Francios is using that allows proper
user session tracking to be established. In my clean-systemd environment, I get:
22:19 valhalla:~> loginctl show-session $XDG_SESSION_ID
NAutoVTs=6
KillExcludeUsers=root
KillUserProcesses=no
IdleHint=yes
IdleSinceHint=0
IdleSinceHintMonotonic=0
InhibitDelayMaxUSec=5s
HandlePowerKey=poweroff
HandleSuspendKey=suspend
HandleHibernateKey=hibernate
HandleLidSwitch=suspend
IdleAction=ignore
IdleActionUSec=30min
PreparingForShutdown=no
PreparingForSleep=no
From the documentation that shows I do not have it configured properly. I
believe it may have to do with differences in the /etc/pam.d config. Francios,
what are you using?
I think the users 'process' tracking may have to do with code current wrapped
within consolekit preprocessor checks that is not duplicated outside these
checks but is necessary for process tracking in the absence of consolekit. This
is also where I am focusing effort to learn what additions to the
kdebase/tdm/backend code may be needed to comply with the freedesktop.org
systemd environment.
Francios, let me know your thoughts on this and Slavek let me know if you have
any other suggestions as well. I am encouraged to see Francios has part of the
correct config working.
--
David C. Rankin, J.D.,P.E.
24 Feb
24 Feb
8:43 p.m.
New subject: [trinity-devel] Bug 1902 - pam.d and preprocessor checks surrounding consolekit may be part of issue
On 02/24/2014 10:34 PM, David C. Rankin wrote:
showing that session tracking can with
Grrr... autotext, should be:
showing that session tracking can work in TDE...
--
David C. Rankin, J.D.,P.E.
10:03 p.m.
New subject: [trinity-devel] Bug 1902 - pam.d and preprocessor checks surrounding consolekit may be part of issue
Le 25/02/2014 05:43, David C. Rankin a écrit :
On 02/24/2014 10:34 PM, David C. Rankin wrote:
Here are the PAM files I'm using on Mageia 4.
This is simply a copy/paste from what KDE4 uses on the same distribution.
I've done some investigation on this issue and I'll write my findings
later (not enough time right now).
Francois
showing that session tracking can with
Grrr... autotext, should be:
showing that session tracking can work in TDE...
25 Feb
25 Feb
11:53 a.m.
New subject: [trinity-devel] Bug 1902 - pam.d and preprocessor checks surrounding consolekit may be part of issue
On 02/25/2014 12:03 AM, François Andriot wrote:
Le 25/02/2014 05:43, 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.
--
David C. Rankin, J.D.,P.E.
On 02/24/2014 10:34 PM, David C. Rankin wrote:
Here are the PAM files I'm using on Mageia 4.
This is simply a copy/paste from what KDE4 uses on the same distribution.
I've done some investigation on this issue and I'll write my findings later (not
enough time right now).
Francois
showing that session tracking can with
Grrr... autotext, should be:
showing that session tracking can work in TDE...
1:54 p.m.
New subject: [trinity-devel] Bug 1902 - pam.d and preprocessor checks surrounding consolekit may be part of issue
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
2:28 p.m.
New subject: [trinity-devel] Bug 1902 - pam.d and preprocessor checks surrounding consolekit may be part of issue
On 02/25/2014 03:54 PM, François Andriot wrote:
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
You are a genius! (or at least are a LOT better a following rabbit trails than I)
If you have not looked into what the
kde-workspace-4.11.0-kdm-logind-multiseat.patch does, it may hold the key to
part of the problem. I have been looking through the tdebase/tdm/backend files
(as suggested by the patch). I may have been looking in the wrong place, but
since I was NOT getting a proper user session tracking response from loginctl
show-session $XDG_SESSION_ID response, that is where the freedesktop.org
migration links and the patch suggested starting.
Could the fact that tdelauncher is NOT receiving the "emit accepted" signal
point to a problem with basic session/process tracking described in the
freedesktop.org pages? What they suggest is unless TDE (or any desktop that used
consolekit) meets the requirements (1-4 listed in the bug), then interprocess
communication regarding sessions and processes is not guaranteed to work
properly. My thought is the "emit accepted" problem is the result of that
issue.
We will have to further look to see if any of the tdebase/tdm/backend code is
involved between that signal/slot communication, that may be where the problem is.
Good catch on the idleTimout. I will try and look at both the mSaveList and
idleTimeout code, but I can't promise to be nearly as quick or as helpful in
sorting it out. Pass along anything you would like me to test on Arch. I'm more
than happy to patch/build/test anything on my end as well.
--
David C. Rankin, J.D.,P.E.
9:42 p.m.
New subject: [trinity-devel] Bug 1902 - pam.d and preprocessor checks surrounding consolekit may be part of issue
On 02/25/2014 03:54 PM, François Andriot wrote:
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.
Building tdebase to test the logind multiseat patch, I notice many deprecated
warnings on string conversions, etc.. I know deprecated should work, but check
your logs, there must be 50 tdeioslave deprecated warning..
--
David C. Rankin, J.D.,P.E.
26 Feb
26 Feb
9:34 a.m.
New subject: [trinity-devel] Bug 1902 - pam.d and preprocessor checks surrounding consolekit may be part of issue
On 02/25/2014 03:54 PM, François Andriot wrote:
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?
--
David C. Rankin, J.D.,P.E.
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
9:38 a.m.
New subject: [trinity-devel] Bug 1902 - pam.d and preprocessor checks surrounding consolekit may be part of issue
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
10:13 a.m.
New subject: [trinity-devel] Bug 1902 - pam.d and preprocessor checks surrounding consolekit may be part of issue
On 02/26/2014 11:38 AM, Slávek Banko 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.
The freedesktop.org documents say you MUST REMOVE ALL REFERENCES TO CONSOLEKIT
in order for systemd logind session tracking to work properly. I see your point,
that if it has no effect --> it has no effect. My concern is that leaving
"#define WITH_CONSOLE_KIT" hardcoded may be biting us.
How hard is it to do a:
#ifdef HAVE_CONSOLE_KIT
#define WITH_CONSOLE_KIT
#endif
I also need a
#ifdef HAVE_SYSTEMD
#define WITH_SYSTEMD
#endif
Will including the check in ConfigureChecks.cmake accomplish this?
if( BUILD_TDM )
pkg_search_module( SYSTEMD systemd )
if( NOT SYSTEMD_FOUND )
message( STATUS "***** systemd NOT found on your system *****" )
else( )
message( STATUS "***** systemd FOUND on your system *****" )
set ( HAVE_SYSTEMD 1)
endif( )
endif( )
Will this work? Will HAVE_SYSTEMD be seen in dm.h (or any other header) so it
can be used as a preprocessor check?
--
David C. Rankin, J.D.,P.E.
11:01 a.m.
New subject: [trinity-devel] Bug 1902 - pam.d and preprocessor checks surrounding consolekit may be part of issue
Dne st 26. února 2014 David C. Rankin napsal(a):
On 02/26/2014 11:38 AM, Slávek Banko wrote:
Must remove is nice requirement, but when the code in reality without the
presence of consolekit can not do anything, so it is quite the same as if
there was not :)
--
Slavek
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.
The freedesktop.org documents say you MUST REMOVE ALL REFERENCES TO
CONSOLEKIT in order for systemd logind session tracking to work
properly. I see your point, that if it has no effect --> it has no
effect. My concern is that leaving "#define WITH_CONSOLE_KIT" hardcoded
may be biting us.
How hard is it to do a:
#ifdef HAVE_CONSOLE_KIT
#define WITH_CONSOLE_KIT
#endif
I also need a
#ifdef HAVE_SYSTEMD
#define WITH_SYSTEMD
#endif
Will including the check in ConfigureChecks.cmake accomplish this?
if( BUILD_TDM )
pkg_search_module( SYSTEMD systemd )
if( NOT SYSTEMD_FOUND )
message( STATUS "***** systemd NOT found on your system *****" )
else( )
message( STATUS "***** systemd FOUND on your system *****" )
set ( HAVE_SYSTEMD 1)
endif( )
endif( )
Will this work? Will HAVE_SYSTEMD be seen in dm.h (or any other header)
so it can be used as a preprocessor check?
2:49 p.m.
New subject: [trinity-devel] Bug 1902 - pam.d and preprocessor checks surrounding consolekit may be part of issue
On 02/26/2014 01:01 PM, Slávek Banko wrote:
Ok,
I've made some progress. We will need to add:
add_definitions(-DWITH_SYSTEMD)
in order to get the preprocessor definition to be recognized (only took about 3
hours to find that out :p)
I'll rebuild - this time actually tripping the WITH_SYSTEMD preprocessor flag...
--
David C. Rankin, J.D.,P.E.
Will this
work? Will HAVE_SYSTEMD be seen in dm.h (or any other header)
> so it can be used as a preprocessor check?
Must remove is nice requirement,
but when the code in reality without the
presence of consolekit can not do anything, so it is quite the same as if
there was not :)
3:03 p.m.
New subject: [trinity-devel] Bug 1902 - pam.d and preprocessor checks surrounding consolekit may be part of issue
On 02/26/2014 04:49 PM, David C. Rankin wrote:
On 02/26/2014 01:01 PM, Slávek Banko wrote:
Ok,
I've made some progress. We will need to add:
add_definitions(-DWITH_SYSTEMD)
in order to get the preprocessor definition to be recognized (only took about 3
hours to find that out :p)
I'll rebuild - this time actually tripping the WITH_SYSTEMD preprocessor flag...
Slavek, Francios,
Here is an updated patch that sets the WITH_SYSTEMD preprocessor flag
--
David C. Rankin, J.D.,P.E.
Will this
work? Will HAVE_SYSTEMD be seen in dm.h (or any other header)
> so it can be used as a preprocessor check?
Must remove is nice requirement,
but when the code in reality without the
presence of consolekit can not do anything, so it is quite the same as if
there was not :)
3:06 p.m.
New subject: [trinity-devel] Bug 1902 - pam.d and preprocessor checks surrounding consolekit may be part of issue
On 02/26/2014 05:03 PM, David C. Rankin wrote:
On 02/26/2014 04:49 PM, David C. Rankin wrote:
Added as:
http://bugs.pearsoncomputing.net/attachment.cgi?id=1962&action=edit
--
David C. Rankin, J.D.,P.E.
On 02/26/2014 01:01 PM, Slávek Banko wrote:
Ok,
I've made some progress. We will need to add:
add_definitions(-DWITH_SYSTEMD)
in order to get the preprocessor definition to be recognized (only took about 3
hours to find that out :p)
I'll rebuild - this time actually tripping the WITH_SYSTEMD preprocessor flag...
Slavek, Francios,
Here is an updated patch that sets the WITH_SYSTEMD preprocessor flag
Will this
work? Will HAVE_SYSTEMD be seen in dm.h (or any other header)
> so it can be used as a preprocessor check?
Must remove is nice requirement,
but when the code in reality without the
presence of consolekit can not do anything, so it is quite the same as if
there was not :)
4:08 p.m.
New subject: [trinity-devel] Bug 1902 - pam.d and preprocessor checks surrounding consolekit may be part of issue
On 02/26/2014 05:06 PM, David C. Rankin wrote:
tdebase build with WITH_SYSTEMD preprocessor flag explicitly set with
add_definitions(-DWITH_SYSTEMD). I included in as follows:
##### check if systemd is installed #############
find_package(Systemd)
if(SYSTEMD_FOUND)
add_definitions(-DWITH_SYSTEMD)
message( STATUS "***** Systemd preprocessor flag WITH_SYSTEMD set *****" )
else()
message( STATUS "***** Systemd preprocessor flag WITH_SYSTEMD -- NOT set
*****" )
endif()
testing to follow
--
David C. Rankin, J.D.,P.E.
> I'll
rebuild - this time actually tripping the WITH_SYSTEMD preprocessor flag...
> >>
>
> Slavek, Francios,
>
> Here is an updated patch that sets the WITH_SYSTEMD preprocessor flag
>
>
Added as:
http://bugs.pearsoncomputing.net/attachment.cgi?id=1962&action=edit
4:53 p.m.
New subject: [trinity-devel] Bug 1902 - pam.d and preprocessor checks surrounding consolekit may be part of issue
On 02/26/2014 06:08 PM, David C. Rankin wrote:
On 02/26/2014 05:06 PM, David C. Rankin wrote:
tdebase build with WITH_SYSTEMD preprocessor flag explicitly set with
add_definitions(-DWITH_SYSTEMD). I included in as follows:
##### check if systemd is installed #############
find_package(Systemd)
if(SYSTEMD_FOUND)
add_definitions(-DWITH_SYSTEMD)
message( STATUS "***** Systemd preprocessor flag WITH_SYSTEMD set *****" )
else()
message( STATUS "***** Systemd preprocessor flag WITH_SYSTEMD -- NOT set
*****" )
endif()
testing to follow
The good news - it builds -> the bad news -> I still have a tone of tdeio
processes open everywhere and loginctl show-session $XDG_USER_SESSION is unchanged.
Slavek, you and Francios will need to work on this. It would be 2016 before I
made it through the process.
For debugging, are you simply adding fprinf(stderr statements or are you using a
kde utility for log output? I'll go back and load the file with fprintf
statements and see if I can figure anything else out.
THIS MUST BE DONE BEFORE THE SOFT FREEZE OR TDE WILL NOT WORK ON SYSTEMD BASED
DISTROS WITH NO CONSOLE KIT -- THIS NEEDS PRIORITY AND SKILLED ATTENTION.
Tim this could use your eyes as well....
--
David C. Rankin, J.D.,P.E.
>
I'll rebuild - this time actually tripping the WITH_SYSTEMD preprocessor flag...
>>>
>
> Slavek, Francios,
>
> Here is an updated patch that sets the WITH_SYSTEMD preprocessor flag
>
>
Added as:
http://bugs.pearsoncomputing.net/attachment.cgi?id=1962&action=edit
5:06 p.m.
New subject: [trinity-devel] Bug 1902 - pam.d and preprocessor checks surrounding consolekit may be part of issue
On Thursday 27 of February 2014 01:53:58 David C. Rankin wrote:
On 02/26/2014 06:08 PM, David C. Rankin wrote:
Moment - in command loginctl show-session you use variable $XDG_USER_SESSION
instead of $XDG_SESSION_ID? Variable $XDG_USER_SESSION contains something?
When you try to extractly the same command with variable $XDG_SESSION_ID?
--
Slavek
On 02/26/2014 05:06 PM, David C. Rankin wrote:
tdebase build with WITH_SYSTEMD preprocessor flag explicitly set with
add_definitions(-DWITH_SYSTEMD). I included in as follows:
##### check if systemd is installed #############
find_package(Systemd)
if(SYSTEMD_FOUND)
add_definitions(-DWITH_SYSTEMD)
message( STATUS "***** Systemd preprocessor flag WITH_SYSTEMD set
*****" ) else()
message( STATUS "***** Systemd preprocessor flag WITH_SYSTEMD -- NOT
set *****" )
endif()
testing to follow
The good news - it builds -> the bad news -> I still have a tone of tdeio
processes open everywhere and loginctl show-session $XDG_USER_SESSION is
unchanged.
Slavek, you and Francios will need to work on this. It would be 2016 before
I made it through the process.
For debugging, are you simply adding fprinf(stderr statements or are you
using a kde utility for log output? I'll go back and load the file with
fprintf statements and see if I can figure anything else out.
THIS MUST BE DONE BEFORE THE SOFT FREEZE OR TDE WILL NOT WORK ON SYSTEMD
BASED DISTROS WITH NO CONSOLE KIT -- THIS NEEDS PRIORITY AND SKILLED
ATTENTION.
Tim this could use your eyes as well.... >
I'll rebuild - this time actually tripping the WITH_SYSTEMD
> preprocessor flag...
>
>
> Slavek, Francios,
>
> Here is an updated patch that sets the WITH_SYSTEMD preprocessor
> flag
Added as:
http://bugs.pearsoncomputing.net/attachment.cgi?id=1962&action=edit
5:21 p.m.
New subject: [trinity-devel] Bug 1902 - pam.d and preprocessor checks surrounding consolekit may be part of issue
On 02/26/2014 07:06 PM, Slávek Banko wrote:
Moment - in command loginctl show-session you use
variable $XDG_USER_SESSION
instead of $XDG_SESSION_ID? Variable $XDG_USER_SESSION contains something?
When you try to extractly the same command with variable $XDG_SESSION_ID?
That was a typo, I've been using $XDG_SESSION_ID. My old brain just slipped out
of gear :)
Is there anything you use to dump output other than fprintf(stderr in cases like
this?
--
David C. Rankin, J.D.,P.E.
5:55 p.m.
New subject: [trinity-devel] Bug 1902 - pam.d and preprocessor checks surrounding consolekit may be part of issue
On Thursday 27 of February 2014 01:53:58 David C. Rankin wrote:
On 02/26/2014 06:08 PM, David C. Rankin wrote:
Detailed information I mentioned in the bug report 1902. I accepted the part
that this is a problem that need to be solved. But I have to say that at the
present time it is absolutely useless to distract our attention with patch
for full support systemd multi-seats, because it is not related to this
problem.
--
Slavek
On 02/26/2014 05:06 PM, David C. Rankin wrote:
tdebase build with WITH_SYSTEMD preprocessor flag explicitly set with
add_definitions(-DWITH_SYSTEMD). I included in as follows:
##### check if systemd is installed #############
find_package(Systemd)
if(SYSTEMD_FOUND)
add_definitions(-DWITH_SYSTEMD)
message( STATUS "***** Systemd preprocessor flag WITH_SYSTEMD set
*****" ) else()
message( STATUS "***** Systemd preprocessor flag WITH_SYSTEMD -- NOT
set *****" )
endif()
testing to follow
The good news - it builds -> the bad news -> I still have a tone of tdeio
processes open everywhere and loginctl show-session $XDG_USER_SESSION is
unchanged.
Slavek, you and Francios will need to work on this. It would be 2016 before
I made it through the process.
For debugging, are you simply adding fprinf(stderr statements or are you
using a kde utility for log output? I'll go back and load the file with
fprintf statements and see if I can figure anything else out.
THIS MUST BE DONE BEFORE THE SOFT FREEZE OR TDE WILL NOT WORK ON SYSTEMD
BASED DISTROS WITH NO CONSOLE KIT -- THIS NEEDS PRIORITY AND SKILLED
ATTENTION.
Tim this could use your eyes as well.... >
I'll rebuild - this time actually tripping the WITH_SYSTEMD
> preprocessor flag...
>
>
> Slavek, Francios,
>
> Here is an updated patch that sets the WITH_SYSTEMD preprocessor
> flag
Added as:
http://bugs.pearsoncomputing.net/attachment.cgi?id=1962&action=edit
9:27 p.m.
New subject: [trinity-devel] Bug 1902 - pam.d and preprocessor checks surrounding consolekit may be part of issue
On 02/26/2014 07:55 PM, Slávek Banko wrote:
Detailed information I mentioned in the bug report
1902. I accepted the part
that this is a problem that need to be solved. But I have to say that at the
present time it is absolutely useless to distract our attention with patch
for full support systemd multi-seats, because it is not related to this
problem.
OK,
If not needed or if it won't help, then we can pursue another avenue, but in
researching the migration requirements:
1. Remove/disable all code responsible for registering your service with ConsoleKit.
2. Make sure to register your greeter session via the PAM session stack, and
make sure the PAM session modules include pam_systemd. Also, make sure to set
the session class to "greeter." This may be done by setting the environment
variable XDG_SESSION_CLASS to "greeter" with pam_misc_setenv() or setting the
"class=greeter" option in the pam_systemd module, in order to allow
applications
to filter out greeter sessions from normal login sessions.
3. Make sure to register your logged in session via the PAM session stack as
well, also including pam_systemd in it.
4. Optionally, use pam_misc_setenv() to set the environment variables XDG_SEAT
and XDG_VTNR. The former should contain "seat0", the latter the VT number your
session runs on. pam_systemd can determine these values automatically but it's
nice to pass these variables anyway. In summary: porting a display manager from
ConsoleKit to systemd primarily means removing code, not necessarily adding any
new code. Here, a cheers to simplicity!
The multiseat patch does part of #2 and all of #4, so I fail to see how that is
a 'distraction'? What the problem is -- is that the TDE code needs MORE than
just a migration to systemd. There are parts of the code that DO NOT work in a
clean-systemd environment on-and-above the freedesktop migration requirements.
That's fair, but it doesn't make implementing the multiseat patch a distraction,
it just means that implementing multiseat will not solve all the problems :(
Even though the patch multiseat patch did not fix those problem, the upside is
that the port of the patch builds and installs without any adverse impact on TDE
bringing tdm that much closer to being up to date.
Now, do you have anything beyond tdebase-kdesktop-systemd.diff that I can help
test? Let me know. If not, I'll go add more print statements and try to figure
out where you are going with your dbus solution and where Francios was going
with the dumps he made.
One thing I did find out was that kdm (kde4) was still virtually identical to
tdm as far as implementing the multiseat patch, so it may be worth taking a look
at the kde4 kdm files regarding the tdeio issue since it has probably already
been solved in a manner we can port directly to tde rather than reinventing the
wheel.
--
David C. Rankin, J.D.,P.E.
10:17 p.m.
New subject: [trinity-devel] Bug 1902 - pam.d and preprocessor checks surrounding consolekit may be part of issue
On 02/26/2014 11:38 AM, Slávek Banko 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,
dm.h:40: #define WITH_CONSOLE_KIT
** there is NO conditional surround this define, it is defined always.
dm.h:488: #ifdef WITH_CONSOLE_KIT
dm.h:489: int StartClient( const char *ck_session_cookie );
dm.h:490: #else
dm.h:491: int StartClient( void );
dm.h:492: #endif
client.c:1205: #ifdef WITH_CONSOLE_KIT
client.c:1206: int
client.c:1207: StartClient( const char *ck_session_cookie )
client.c:1208: #else
client.c:1209: int
client.c:1210: StartClient()
client.c:1211: #endif
client.c:1311: env = setEnv ( env, "XDG_SESSION_COOKIE", ck_session_cookie );
session.c:642: #ifdef WITH_CONSOLE_KIT
session.c:643: ck_session_cookie = open_ck_session (getpwnam(curuser), d);
session.c:644: if (!(clientPid = StartClient(ck_session_cookie))) {
session.c:645: #else
session.c:646: if (!(clientPid = StartClient())) {
session.c:647: #endif
Even without consolekit installed on the system, this still causes StartClient
to be declared as:
int StartClient( const char *ck_session_cookie );
instead of
int StartClient( void );
and client.c causes StartClient to be initialized with the character pointer
ck_session_cookie (hopefully NULL) and part of the XDG_SESSION_COOKIE
environment to be set (if not NULL).
It may not matter, but it does not seem like good practice to leave code like
that hanging around in the absence of concolekit. I have put fprintf statements
inside all WITH_CONSOLE_KIT preprocessor conditionals and will report back with
which ones are being executed..
--
David C. Rankin, J.D.,P.E.
3734
days inactive
3736
days old
20 comments
3 participants
participants (3)
-
David C. Rankin -
François Andriot -
Slávek Banko