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