On 08/29/2015 06:42 PM, Slávek Banko 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 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. -- David C. Rankin, J.D.,P.E.

On 08/31/2015 09:44 AM, Michele Calgaro wrote: 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. -- David C. Rankin, J.D.,P.E.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 09/02/2015 03:59 AM, David C. Rankin wrote: - 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 Sunday 30 of August 2015 23:27:09 David C. Rankin wrote: 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. -- Slávek