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.
>
>   I have compared what TDE does with /etc/pam.d/trinity and what is
> currently done with kde4 on arch. The current TDE pam.d settings are:
>
> /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
>
>   The comparable pam setup for kde4 on Arch uses (noc is cat with
> no-comment):
>
> 09:56 alchemy:~/tde/tmp/pam> noc kde4/kde
> #%PAM-1.0
> auth            include         system-login
> account         include         system-login
> password        include         system-login
> session         include         system-login
> 09:56 alchemy:~/tde/tmp/pam> noc kde4/kde-np
> #%PAM-1.0
> auth            required        pam_tally.so    onerr=succeed
> file=/var/log/faillog auth            required        pam_shells.so
> auth            requisite       pam_nologin.so
> auth            required        pam_env.so
> auth            optional        pam_permit.so
> account         include      system-login
> password        include      system-login
> session         include      system-login
> 10:00 alchemy:~/tde/tmp/pam> noc kde4/kscreensaver
> #%PAM-1.0
> auth            required        pam_unix_auth.so
>
>   I have tried changing /etc/pam.d/trinity to use:
>
> #%PAM-1.0
> #auth       required     pam_securetty.so
> auth       requisite    pam_nologin.so
> auth            include         system-login
> account         include         system-login
> password        include         system-login
> session         include         system-login
>
>   Login is fine using system-login instead of the current
> 'system-local-login', but the output of 'loginctl show-session
> $XDG_SESSION_ID' is unchanged.
>
>   I have posted the issue to the Arch list and will report any
> suggestins back. Experts, what say you?

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.

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
--