Tim, Slavek, Darrell, All, (whoever is left?)
I've checked from time to time to see if http://bugs.pearsoncomputing.net/show_bug.cgi?id=1998 has been resolved to crank up my Arch build system again. When we left, the problem was TDE did not provide user session tracking or a multi-seat implementation for a pure-systemd environment (without ConsoleKit).
This resulted in applications being launched, but never terminated after they had been closed by the user.
Can anyone confirm correct behavior of TDE in a pure-systemd setting w/o ConsoleKit? Even without multi-seat, it is worth building TDE if the issue described in bug 1998 has been resolved.
What says the brain trust?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 2015/08/26 11:49 AM, David C. Rankin wrote:
Tim, Slavek, Darrell, All, (whoever is left?)
I've checked from time to time to see if http://bugs.pearsoncomputing.net/show_bug.cgi?id=1998 has been resolved to crank up my Arch build system again. When we left, the problem was TDE did not provide user session tracking or a multi-seat implementation for a pure-systemd environment (without ConsoleKit).
This resulted in applications being launched, but never terminated after they had been closed by the user.
Can anyone confirm correct behavior of TDE in a pure-systemd setting w/o ConsoleKit? Even without multi-seat, it is worth building TDE if the issue described in bug 1998 has been resolved.
What says the brain trust?
Hi David, welcome back. Not sure if this helps, but my system is Debian Stretch with systemd and TDE. I don't have ConsoleKit (now obsolete anyway) or multiseat support, but I have not noticed any particular problem. I usually run only one session at a time, but occasionally I run 2 different ones for two different users on the same machine.
cheers Michele
On Wednesday 26 of August 2015 04:49:04 David C. Rankin wrote:
Tim, Slavek, Darrell, All, (whoever is left?)
I've checked from time to time to see if http://bugs.pearsoncomputing.net/show_bug.cgi?id=1998 has been resolved to crank up my Arch build system again. When we left, the problem was TDE did not provide user session tracking or a multi-seat implementation for a pure-systemd environment (without ConsoleKit).
TDE provides basic support for systemd - from TDM through kdesktop to tdepowersave. What is not yet implemented, is support for multi-seat.
By Darrell is also a proposal to add support into k3b - inhibitor for suspend / shutdown during recording media (bug 2389).
This resulted in applications being launched, but never terminated after they had been closed by the user.
In this I have again and again oppose. It has already been repeatedly shown that failure in closing the processes had a different cause and no connection with systemd. See bug 1902.
Can anyone confirm correct behavior of TDE in a pure-systemd setting w/o ConsoleKit? Even without multi-seat, it is worth building TDE if the issue described in bug 1998 has been resolved.
What says the brain trust?
Systemd is currently used on Debian 8.x (Jessie) and Ubuntu 15.04 (Vivid). I also do tests on Ubuntu 14.04 (Trusty) with added systemd. For Ubuntu is also created systemd service for TDM:
http://git.trinitydesktop.org/cgit/tde-packaging/tree/ubuntu/maverick/tdebas...
On 08/29/2015 06:42 PM, Slávek Banko wrote:
On Wednesday 26 of August 2015 04:49:04 David C. Rankin wrote:
Tim, Slavek, Darrell, All, (whoever is left?)
I've checked from time to time to see if http://bugs.pearsoncomputing.net/show_bug.cgi?id=1998 has been resolved to crank up my Arch build system again. When we left, the problem was TDE did not provide user session tracking or a multi-seat implementation for a pure-systemd environment (without ConsoleKit).
TDE provides basic support for systemd - from TDM through kdesktop to tdepowersave. What is not yet implemented, is support for multi-seat.
By Darrell is also a proposal to add support into k3b - inhibitor for suspend / shutdown during recording media (bug 2389).
This resulted in applications being launched, but never terminated after they had been closed by the user.
In this I have again and again oppose. It has already been repeatedly shown that failure in closing the processes had a different cause and no connection with systemd. See bug 1902.
Thanks, yes, I know. In all the related bugs we went through the discussion of it not being related to systemd, etc... But whatever the reason, without ConsoleKit, virtually kdeioslave apps and others would never be closed. I guess I'll just have to pull the latest and give it a shot
Can anyone confirm correct behavior of TDE in a pure-systemd setting w/o ConsoleKit? Even without multi-seat, it is worth building TDE if the issue described in bug 1998 has been resolved.
What says the brain trust?
Systemd is currently used on Debian 8.x (Jessie) and Ubuntu 15.04 (Vivid). I also do tests on Ubuntu 14.04 (Trusty) with added systemd. For Ubuntu is also created systemd service for TDM:
http://git.trinitydesktop.org/cgit/tde-packaging/tree/ubuntu/maverick/tdebas...
Michele, Slavek
That is all good news. I pull a fresh checkout and build and test. The only thing I need to know is:
(1) are there any alternative version distinctions that remain in the git repository (i.e. like the old 14 v. 3.5.13_SRU)?
(2) have there been any significant changes to the build process that need to be addressed on my end before I kick-off a build? (I expect changes that will need fixes, but as far as the normal approach and build-order, is that still the same?)
I loaded suse 13.1 a year or so ago when I got busy and have just use Ilya and Serghei's packaging for suse sense (suse still included ConsoleKit w/13.1) I haven't tried, but ConsoleKit (ConsoleKit-0.4.6-4.1.4.x86_64.rpm) is still part of the 13.2 release.
If you all are running tde on systemd without any ConsoleKit or other wrapper to launch TDE and are having all your apps tdeioslave apps closed, that's great. A pure systemd launch of tdm would be via a systemd tdm.service file such as:
[Unit] Description=TDE Display Manager After=systemd-user-sessions.service
[Service] ExecStart=/opt/trinity/bin/tdm
[Install] Alias=display-manager.service
Could those who are running tde on a systemd based system w/o ConsoleKit check how you are launching tde/tdm and let me know. That I believe is one of the critical components. If you are using anything other than systemd to launch tdm from a service file similar to the foregoing, I need to know what you are using. Thanks.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 08/31/2015 06:27 AM, David C. Rankin wrote: <snip>
David, see interleaved comments below. Sorry for mixed posting. Cheers Michele
Michele, Slavek
That is all good news. I pull a fresh checkout and build and test. The only thing I need to know is:
(1) are there any alternative version distinctions that remain in the git repository (i.e. like the old 14 v. 3.5.13_SRU)?
Main trunk is the future R14.1.x series. There is a R14.0.x branch that is basically R14.0.0 + bug fixes.
(2) have there been any significant changes to the build process that need to be addressed on my end before I kick-off a build? (I expect changes that will need fixes, but as far as the normal approach and build-order, is that still the same?)
Not really, perhaps some package renaming here and there but nothing major AFAICT.
I loaded suse 13.1 a year or so ago when I got busy and have just use Ilya and Serghei's packaging for suse sense (suse still included ConsoleKit w/13.1) I haven't tried, but ConsoleKit (ConsoleKit-0.4.6-4.1.4.x86_64.rpm) is still part of the 13.2 release.
If you all are running tde on systemd without any ConsoleKit or other wrapper to launch TDE and are having all your apps tdeioslave apps closed, that's great. A pure systemd launch of tdm would be via a systemd tdm.service file such as:
[Unit] Description=TDE Display Manager After=systemd-user-sessions.service
[Service] ExecStart=/opt/trinity/bin/tdm
[Install] Alias=display-manager.service
Could those who are running tde on a systemd based system w/o ConsoleKit check how you are launching tde/tdm and let me know. That I believe is one of the critical components. If you are using anything other than systemd to launch tdm from a service file similar to the foregoing, I need to know what you are using. Thanks.
-- David C. Rankin, J.D.,P.E.
Ran from /etc/init.d/tdm-trinity
On 08/31/2015 09:44 AM, Michele Calgaro wrote:
Ran from /etc/init.d/tdm-trinity
Michele,
Would you be so kind as to post how tde is launched from tdm-trinity? If you are still using init scripts, then you will probably find in lines 7-10 you are calling tdm directly:
7 start) 8 #Check for running tdm, start when not running 9 stat_busy "Starting TDE Desktop Manager (tdm)" 10 [ -z "$PID" ] && /opt/trinity/bin/tdm &> /dev/null
Different distros handle init scrip wrappers with systemd in different ways. I've looked at the debian wiki and can't tell how they are doing it. This is where the session management issue comes up. In a pure-systemd environment, there are no init scripts -- period. For example, on arch:
13:44 valkyrie:~> ls -al /etc/init.d ls: cannot access /etc/init.d: No such file or directory
systemd handles all processes directly through a service file. I would wager that debian has an additional layer between tdm and systemd that provides what ConsoleKit did in the past. Can you check to see how debian handles init-script/systemd integration.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 09/02/2015 03:59 AM, David C. Rankin wrote:
On 08/31/2015 09:44 AM, Michele Calgaro wrote:
Ran from /etc/init.d/tdm-trinity
Michele,
Would you be so kind as to post how tde is launched from tdm-trinity? If you are still using init scripts, then you will probably find in lines 7-10 you are calling tdm directly:
7 start) 8 #Check for running tdm, start when not running 9 stat_busy "Starting TDE Desktop Manager (tdm)" 10 [ -z "$PID" ] && /opt/trinity/bin/tdm &> /dev/null
Different distros handle init scrip wrappers with systemd in different ways. I've looked at the debian wiki and can't tell how they are doing it. This is where the session management issue comes up. In a pure-systemd environment, there are no init scripts -- period. For example, on arch:
13:44 valkyrie:~> ls -al /etc/init.d ls: cannot access /etc/init.d: No such file or directory
systemd handles all processes directly through a service file. I would wager that debian has an additional layer between tdm and systemd that provides what ConsoleKit did in the past. Can you check to see how debian handles init-script/systemd integration.
Hi David, sorry for the late reply, I am very busy recently. I will try to check this week and let you know. To be honest the migration to systemd in my Debian machine was done "behind the scenes" and I never bothered (== had no time) to look at it in detail. Cheers Michele
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 09/02/2015 03:59 AM, David C. Rankin wrote:
On 08/31/2015 09:44 AM, Michele Calgaro wrote:
Ran from /etc/init.d/tdm-trinity
Michele,
Would you be so kind as to post how tde is launched from tdm-trinity? If you are still using init scripts, then you will probably find in lines 7-10 you are calling tdm directly:
7 start) 8 #Check for running tdm, start when not running 9 stat_busy "Starting TDE Desktop Manager (tdm)" 10 [ -z "$PID" ] && /opt/trinity/bin/tdm &> /dev/null
Different distros handle init scrip wrappers with systemd in different ways. I've looked at the debian wiki and can't tell how they are doing it. This is where the session management issue comes up. In a pure-systemd environment, there are no init scripts -- period. For example, on arch:
13:44 valkyrie:~> ls -al /etc/init.d ls: cannot access /etc/init.d: No such file or directory
systemd handles all processes directly through a service file. I would wager that debian has an additional layer between tdm and systemd that provides what ConsoleKit did in the past. Can you check to see how debian handles init-script/systemd integration.
- From dmesg I got systemd-sysv-generator[179]: Overwriting existing symlink /run/systemd/generator.late/tdm-trinity.service with real service I little search on google pointed me here: http://www.freedesktop.org/software/systemd/man/systemd-sysv-generator.html So that's how systemd runs sysV init script on Debian I guess ;-) Cheers Michele
On 9/11/2015 9:22 AM, Michele Calgaro wrote:
systemd-sysv-generator[179]: Overwriting existing symlink /run/systemd/generator.late/tdm-trinity.service with real service I little search on google pointed me here: http://www.freedesktop.org/software/systemd/man/systemd-sysv-generator.html
So that's how systemd runs sysV init script on Debian I guess ;-)
Cheers Michele
Yes,
Thank you for checking. I knew without the fix to Bug 1998, there isn't any way tde could operate without an initscript type launch and automatically have proper user session tracking. We will keep our fingers crossed that a solution will be found for the pure-systemd environment :)
On Sunday 30 of August 2015 23:27:09 David C. Rankin wrote:
Thanks, yes, I know. In all the related bugs we went through the discussion of it not being related to systemd, etc... But whatever the reason, without ConsoleKit, virtually kdeioslave apps and others would never be closed. I guess I'll just have to pull the latest and give it a shot
And that's exactly what I repeat again and again and again: that the problem with tdeioslave does not have any relationship to systemd.
Already during solving bug 1902, have repeatedly shown that the problem occurred also on older distributions (for example Debian Squeeze) that uses classic init scripts, consolekit and have no connection to systemd. That problem was related to the termination of the objects in downstream processes. And fix was was then a one-line patch! See this commit:
http://git.trinitydesktop.org/cgit/tdelibs/commit/?id=13d6174c
I really do not know how it's better to say.
-
David C. Rankin -
Michele Calgaro -
Slávek Banko