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.
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...
Le 25/02/2014 05:43, David C. Rankin a écrit :
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...
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
On 02/25/2014 12:03 AM, François Andriot wrote:
Le 25/02/2014 05:43, David C. Rankin a écrit :
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...
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
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.
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
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):
- The tdelauncher class is initialized line 165.
It runs a TDEServerSocket (line 197) and binds a signal "accepted" with slot "acceptslave" (line 198).
- 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.
- 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.
- 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.
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..
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):
- The tdelauncher class is initialized line 165.
It runs a TDEServerSocket (line 197) and binds a signal "accepted" with slot "acceptslave" (line 198).
- 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.
- 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.
- 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?
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):
- The tdelauncher class is initialized line 165.
It runs a TDEServerSocket (line 197) and binds a signal "accepted" with slot "acceptslave" (line 198).
- 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.
- 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.
- 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.
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?
Dne st 26. února 2014 David C. Rankin napsal(a):
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?
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 :)
On 02/26/2014 01:01 PM, Slávek Banko wrote:
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 :)
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...
On 02/26/2014 04:49 PM, David C. Rankin wrote:
On 02/26/2014 01:01 PM, Slávek Banko wrote:
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 :)
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
On 02/26/2014 05:03 PM, David C. Rankin wrote:
On 02/26/2014 04:49 PM, David C. Rankin wrote:
On 02/26/2014 01:01 PM, Slávek Banko wrote:
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 :)
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
Added as:
http://bugs.pearsoncomputing.net/attachment.cgi?id=1962&action=edit
On 02/26/2014 05:06 PM, David C. Rankin wrote:
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
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
On 02/26/2014 06:08 PM, David C. Rankin wrote:
On 02/26/2014 05:06 PM, David C. Rankin wrote:
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
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....
On Thursday 27 of February 2014 01:53:58 David C. Rankin wrote:
On 02/26/2014 06:08 PM, David C. Rankin wrote:
On 02/26/2014 05:06 PM, David C. Rankin wrote:
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
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....
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?
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?
On Thursday 27 of February 2014 01:53:58 David C. Rankin wrote:
On 02/26/2014 06:08 PM, David C. Rankin wrote:
On 02/26/2014 05:06 PM, David C. Rankin wrote:
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
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....
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.
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.
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 -
François Andriot -
Slávek Banko