Hi Sebastian,

On Mo 16 Sep 2013 16:17:31 CEST Sebastian Flothow wrote:

> I did some further testing, and the resume failures are indeed due  
> to missing AFS tokens. When suspending a session, the SSH connection  
> is closed, sshd will call pam_close_session(), which means that  
> pam_krb5 and pam_afs_session will delete the user's ticket/token  
> (resp.). The session therefore loses access to the home directory  
> and appears to freeze up, preventing it from being resumed.
>
> Both pam_krb5 and pam_afs_session accept retain_after_close as a  
> parameter, which disables the delete-on-close behavior. With this  
> parameter set, it becomes possible to resume sessions, unless the  
> AFS token has expired.

Thanks for digging this out. Good work!!!

> This solves at least the case where the user reconnects quickly (eg.  
> after a short network outage), but it still means sessions will  
> become unresumable when left unused for a few days.

I get that. NFSv4 with Kerberos is very similar to the AFS token behaviour.

> I guess the only way to avoid this is to not store session data in  
> the home directory. Can X2go be configured such that it uses eg.  
> /tmp or /var/lib for this purpose?

In earlier versions of X2Go every session detail was in $HOME. Some of  
the session information has to be accessible by super-user root. Those  
bits, I have already moved out of the home (e.g. the session.log file).

Normally, the AFS token should be immediately restored after SSH login  
(which is the first action taken when resuming a session). However,  
this AFS token does not re-awake the session so it can be resumed. The  
question is why...

Does a session simply not resume (with an x2goagent still being  
present for this session)? Or does the x2goagent crash somewhere on  
the run (i.e. when the session is suspended and the AFS home freezes  
some time later)?

When evoking x2golistsessions, the first field of each output line is  
the x2goagent PID that is associated to that session in the same line.  
With non-resumable sessions, please check if the x2goagent processes  
remain active on the X2Go server or if the x2goagent processes crash  
(disappear). I can only imagine that the x2goagent processes remain  
alive (frozen) until the AFS token gets reinstated by the X2Go  
resuming SSH login. If x2goagent crashes somewhere on the way, we have  
to find out why and how to prevent it.

However, if x2goagent stays functional, we have to investigate, if  
there is anything AFS-critical in /usr/bin/x2goresume-session. If you  
look at the script /usr/bin/x2goresume-session, can you spot anything  
that might fail on AFS?


Greets,
Mike

-- 

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb