On 02/03/2014 11:46 AM, Slávek Banko wrote: > Dne po 3. února 2014 David C. Rankin napsal(a): >> Tim, All, >> >> I have stumbled upon an issue that may be responsible for the sound >> and sftp session closing (bug 1902) problems I experience running TDE >> on a systemd based system. The problem surrounds pam/tdm and polkit >> setup and tracking user sessions in the absence of Consolekit. The >> issue is addressed in the freedesktop articles: >> >> http://www.freedesktop.org/wiki/Software/systemd/writing-display-manage >> rs/ >> >> http://www.freedesktop.org/wiki/Software/systemd/writing-desktop-enviro >> nments/ >> >> The porting changes necessary for TDE to work in a systemd/polkit >> environment look minimal, but they are a bit above my understanding at >> the moment. >> >> I have detailed the sftp issue in >> http://bugs.pearsoncomputing.net/show_bug.cgi?id=1902 along with >> diagnostics. The crux of the current issue is that tdebase/tdebase >> mkpamserv does not provide an environment where proper session tracking >> occurs: >> >> 08:29 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 >> >> does not contain Remote=no and Active=yes which apparently indicate >> proper user session tracking. I need someone who has a bit more >> experience with tdebase code and in this area to review the freedesktop >> links regarding the new session tracking requirements under systemd and >> see if this is an issue that needs to be jumped on before RC1 is >> frozen. Currently, the current problems I have discovered under systemd >> impact user sound access/printer driver generation/and sftp session >> closure. I suspect the problems may be more widespread but I have yet >> to discover all of them. >> <snip> > > I have a test machine with Ubuntu 13.10 (Saucy), on which is used systemd. > Without giving anything set up in list from: > > loginctl show-session $ XDG_SESSION_ID > > I see the values: > > Id=c4 > Timestamp=Thu 2014-01-30 20:31:22 CET > TimestampMonotonic=267801422 > DefaultControlGroup=systemd:/user/1000.user/c4.session > VTNr=7 > Display=:0 > Remote=no > Service=tdm-trinity > Leader=1807 > Audit=0 > Type=x11 > Class=user > Active=yes > State=active > KillProcesses=no > IdleHint=no > IdleSinceHint=0 > IdleSinceHintMonotonic=0 > Name=axis > > I looked at the above referenced recommendations. > How did you get saucy to activate properly?? For Archlinux I am using tdm.service: [Unit] Description=TDE Display Manager After=systemd-user-sessions.service [Service] ExecStart=/opt/trinity/bin/tdm [Install] Alias=display-manager.service and /etc/X11/xinit/xinitrc.d is activating: 30-dbus pulseaudio yet I do not get any of the X specific setting you show in your response to 'loginctl show-session $ XDG_SESSION_ID' If this can be done via configuration, then I'm fine doing it that way, but I have not been able to find a working config that will do it... > Patch ready for tdepowersave includes monitoring systemd session and in > accordance with the recommendations set Inhibits, thereby declaring its > own event handling power management. See bug 1597 - I think that this > patch can be pushed. > > During the preparation of this patch I was considering whether to > implement into tdepowersave a response to a signal Lock() from systemd > (this way is addressed in KDE4 - a response to a signal is implemented in > PowerDevil). However, this solution I thought was wrong, because in my > opinion, belong to ksmserver or kdesktop_lock. Not all users will have > installed tdepowersave. > > Add call SetIdleHint(True / False) would not be difficult. Suitable place > seems kdesktop_lock - before / after activate the screen saver. > > Most recommendations bent to tdm, wherein is currently the integrated only > ConsoleKit. Does anyone know which distributions currently used > exclusively SystemD and do not contain ConsoleKit? I do not have an > estimate of how much work / time will be required to implement support > for systemd in TDM. I do not know if because of that delay the release > R14.0.0. Personally, I tend to not to consider this as blocking. > > What do you think? > > Slavek > Archlinux uses SystemD exclusively without ConsoleKit.... -- David C. Rankin, J.D.,P.E.