On 09.04.2015 09:28 PM, Christoph Schmidt-Hieber wrote:
On Thu, Apr 09, 2015 at 09:18:15PM +0200, Mihai Moldovan wrote:
Please check ~/.xsession-x2go-errors This file doesn't exist in my home directory although I've set the x2goserver log level to "debug".
xfce4 is installed, and I can run xfce4-session through an ssh -X connection.
Ok.
Can you please check that x2goserver-xsession is installed? I suspect this is not the case.
Mihai
On Thu, Apr 09, 2015 at 09:31:48PM +0200, Mihai Moldovan wrote:
On 09.04.2015 09:28 PM, Christoph Schmidt-Hieber wrote:
On Thu, Apr 09, 2015 at 09:18:15PM +0200, Mihai Moldovan wrote:
Please check ~/.xsession-x2go-errors This file doesn't exist in my home directory although I've set the x2goserver log level to "debug".
xfce4 is installed, and I can run xfce4-session through an ssh -X connection.
Ok.
Can you please check that x2goserver-xsession is installed? I suspect this is not the case.
x2goserver-xsession is installed.
Re-installing didn't help. Also, there's still no ~/.xsession-x2go-errors file.
Thanks for your patience - much appreciated.
On 09.04.2015 09:35 PM, Christoph Schmidt-Hieber wrote:
x2goserver-xsession is installed.
Re-installing didn't help. Also, there's still no ~/.xsession-x2go-errors file.
That's very weird... according to your log file, xfce4-session terminates almost immediately after being launched. It's also launched via X2Go's xsession feature, so ~/.xsession-x2go-errors should be populated.
This is defined in /etc/x2go/Xsession. Can you check that file for ERRFILE, just in case?
Something must be "failing", either the Xsession script itself or the actual xfce4-session.
Mihai
On Thu, Apr 09, 2015 at 09:45:38PM +0200, Mihai Moldovan wrote:
On 09.04.2015 09:35 PM, Christoph Schmidt-Hieber wrote:
x2goserver-xsession is installed.
Re-installing didn't help. Also, there's still no ~/.xsession-x2go-errors file.
That's very weird... according to your log file, xfce4-session terminates almost immediately after being launched. It's also launched via X2Go's xsession feature, so ~/.xsession-x2go-errors should be populated.
This is defined in /etc/x2go/Xsession. Can you check that file for ERRFILE, just in case?
Something must be "failing", either the Xsession script itself or the actual xfce4-session.
$ grep -n ERRFILE /etc/x2go/Xsession
73:ERRFILE=$HOME/.xsession-x2go-errors
76:if (umask 077 && touch "$ERRFILE") 2> /dev/null && [ -w "$ERRFILE" ] && [ ! -L "$ERRFILE" ]; then
77: chmod 600 "$ERRFILE"
78:elif ERRFILE=$(mktemp 2> /dev/null); then
79: if ! ln -sf "$ERRFILE" "${TMPDIR:=/tmp}/xsession-x2go-$USER"; then
81: "\"$ERRFILE\"; look for session log/errors in"
88:exec >>"$ERRFILE" 2>&1
On Apr 9, 2015 3:55 PM, "Christoph Schmidt-Hieber" <christsc@gmx.de> wrote:
On Thu, Apr 09, 2015 at 09:45:38PM +0200, Mihai Moldovan wrote:
On 09.04.2015 09:35 PM, Christoph Schmidt-Hieber wrote:
x2goserver-xsession is installed.
Re-installing didn't help. Also, there's still no ~/.xsession-x2go-errors file.
That's very weird... according to your log file, xfce4-session terminates almost immediately after being launched. It's also launched via X2Go's xsession feature, so ~/.xsession-x2go-errors should be
populated.
This is defined in /etc/x2go/Xsession. Can you check that file for ERRFILE, just in case?
Something must be "failing", either the Xsession script itself or the actual xfce4-session.
$ grep -n ERRFILE /etc/x2go/Xsession 73:ERRFILE=$HOME/.xsession-x2go-errors 76:if (umask 077 && touch "$ERRFILE") 2> /dev/null && [ -w "$ERRFILE" ] && [ ! -L "$ERRFILE" ]; then 77: chmod 600 "$ERRFILE" 78:elif ERRFILE=$(mktemp 2> /dev/null); then 79: if ! ln -sf "$ERRFILE" "${TMPDIR:=/tmp}/xsession-x2go-$USER"; then 81: "\"$ERRFILE\"; look for session log/errors in"
88:exec >>"$ERRFILE" 2>&1
Hi Christoph,
What is your default shell on the server? I have seen various x2go problems (but not this exact problem) when it was set to /bin/tcsh (or a /bin/csh symlink to /bin/tcsh). I suspect that the actual legacy /bin/csh binary would behave even worse with x2go.
-Mike
On 10.04.2015 12:10 AM, Michael DePaulo wrote:
What is your default shell on the server? I have seen various x2go problems (but not this exact problem) when it was set to /bin/tcsh (or a /bin/csh symlink to /bin/tcsh). I suspect that the actual legacy /bin/csh binary would behave even worse with x2go.
We've figured the problem out privately. It was caused by a "exec bash" statement at the end of ~/.profile for one user. Didn't take a look at the other user, but I suspect the same thing there.
Mihai
On Fri, Apr 10, 2015 at 12:13:10AM +0200, Mihai Moldovan wrote:
On 10.04.2015 12:10 AM, Michael DePaulo wrote:
What is your default shell on the server? I have seen various x2go problems (but not this exact problem) when it was set to /bin/tcsh (or a /bin/csh symlink to /bin/tcsh). I suspect that the actual legacy /bin/csh binary would behave even worse with x2go.
We've figured the problem out privately. It was caused by a "exec bash" statement at the end of ~/.profile for one user. Didn't take a look at the other user, but I suspect the same thing there.
I can confirm that removing "exec bash" from .profile solved the problem for the other user as well.
Thanks a lot to Mihai for his extraordinarily fast and efficient help.
On Thu, Apr 9, 2015 at 6:42 PM, Christoph Schmidt-Hieber <christsc@gmx.de> wrote:
On Fri, Apr 10, 2015 at 12:13:10AM +0200, Mihai Moldovan wrote:
On 10.04.2015 12:10 AM, Michael DePaulo wrote:
What is your default shell on the server? I have seen various x2go problems (but not this exact problem) when it was set to /bin/tcsh (or a /bin/csh symlink to /bin/tcsh). I suspect that the actual legacy /bin/csh binary would behave even worse with x2go.
We've figured the problem out privately. It was caused by a "exec bash" statement at the end of ~/.profile for one user. Didn't take a look at the other user, but I suspect the same thing there.
I can confirm that removing "exec bash" from .profile solved the problem for the other user as well.
Thanks a lot to Mihai for his extraordinarily fast and efficient help.
Good job Mihai.
This brings up an issue with our documentation though. We should document (probably on our wiki) that a user's .bashrc / .profile / .bash_profile file can interfere with X2Go. Perhaps we should update the error message in x2goclient also.
-Mike#2
On 10.04.2015 12:53 AM, Michael DePaulo wrote:
This brings up an issue with our documentation though. We should document (probably on our wiki) that a user's .bashrc / .profile / .bash_profile file can interfere with X2Go. Perhaps we should update the error message in x2goclient also.
Well... this coin has two sides, as always.
X2Go Server's Xsession script sources ${HOME}/.profile. The "default" Xsession script provided in Debian as /etc/X11/Xsession does not. On the other hand, GDM, LightDM and other login managers would have been running into the same problem and not been able to start any desktop environment, because they all also source ~/.profile.
Doing questionable stuff in ~/.*profile or ~/.*rc will always lead to problems. But putting that on the wiki is like adding "Deleting /etc/passwd might cause problems with X2Go" there. It sure will - but that's not an insulated X2Go problem.
Mihai
It might be something to add to the troubleshooting section of the Wiki.-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- Eskimo North Linux Friendly Internet Access, Shell Accounts, and Hosting. Knowledgeable human assistance, not telephone trees or script readers. See our web site: http://www.eskimo.com/ (206) 812-0051 or (800) 246-6874.
On Fri, 10 Apr 2015, Mihai Moldovan wrote:
Date: Fri, 10 Apr 2015 01:41:02 +0200 From: Mihai Moldovan <ionic@ionic.de> To: Michael DePaulo <mikedep333@gmail.com>, Christoph Schmidt-Hieber <christsc@gmx.de> Cc: "x2go-user@lists.x2go.org" <x2go-user@lists.x2go.org> Subject: Re: [X2Go-User] X authorization issues
On 10.04.2015 12:53 AM, Michael DePaulo wrote:
This brings up an issue with our documentation though. We should document (probably on our wiki) that a user's .bashrc / .profile / .bash_profile file can interfere with X2Go. Perhaps we should update the error message in x2goclient also.
Well... this coin has two sides, as always.
X2Go Server's Xsession script sources ${HOME}/.profile. The "default" Xsession script provided in Debian as /etc/X11/Xsession does not. On the other hand, GDM, LightDM and other login managers would have been running into the same problem and not been able to start any desktop environment, because they all also source ~/.profile.
Doing questionable stuff in ~/.*profile or ~/.*rc will always lead to problems. But putting that on the wiki is like adding "Deleting /etc/passwd might cause problems with X2Go" there. It sure will - but that's not an insulated X2Go problem.
Mihai
On Thu, Apr 9, 2015 at 7:41 PM, Mihai Moldovan <ionic@ionic.de> wrote:
On 10.04.2015 12:53 AM, Michael DePaulo wrote:
This brings up an issue with our documentation though. We should document (probably on our wiki) that a user's .bashrc / .profile / .bash_profile file can interfere with X2Go. Perhaps we should update the error message in x2goclient also.
Well... this coin has two sides, as always.
X2Go Server's Xsession script sources ${HOME}/.profile. The "default" Xsession script provided in Debian as /etc/X11/Xsession does not. On the other hand, GDM, LightDM and other login managers would have been running into the same problem and not been able to start any desktop environment, because they all also source ~/.profile.
Doing questionable stuff in ~/.*profile or ~/.*rc will always lead to problems. But putting that on the wiki is like adding "Deleting /etc/passwd might cause problems with X2Go" there. It sure will - but that's not an insulated X2Go problem.
Mihai
Most beginner Linux sysadmins know that bad things will happen if you delete /etc/passwd. Very few beginner Linux sysadmins know that your desktop environment might not start if you have weird syntax in ~/.*profile or ~/.*rc . A moderately skilled Linux sysadmin who rarely uses a GUI is unlikely to know about this also.
So I think we should document it somewhere on the wiki, perhaps under a troubleshooting section.
Also, a more helpful error message might still be worth implementing.
-Mike#2
On 10.04.2015 02:05 AM, Michael DePaulo wrote:
Most beginner Linux sysadmins know that bad things will happen if you delete /etc/passwd. Very few beginner Linux sysadmins know that your desktop environment might not start if you have weird syntax in ~/.*profile or ~/.*rc . A moderately skilled Linux sysadmin who rarely uses a GUI is unlikely to know about this also.
So I think we should document it somewhere on the wiki, perhaps under a troubleshooting section.
On 10.04.2015 02:05 AM, Robert Dinse wrote:
It might be something to add to the troubleshooting section ofthe Wiki.
That sounds very reasonable.
Also, a more helpful error message might still be worth implementing.
Mh, nope. There's no error message, because there was no error, as far as X2Go Client/nx is concerned. A command was successfully started and terminated. Although a "stray" bash process is not what the user *intended* to get, it's what the command ultimately did.
The only way to detect a session almost immediately terminating is to track the time between x2goruncommand start and session termination. If that's too low, say, under a minute, print out an error message. But this will also cause a false positive if the user really *intended* to terminate the session very quickly - for whatever reason. Maybe because it was meant as a quick test to see if X2Go is working at all.
I'd like to avoid such ambiguity.
I can generally change the error message Chris did get by sheer "luck" the second time around, but the point is that this (in this special case unhelpful) error message doesn't even come up reproducibly -- because a successfully created or attached session terminating is in general no error, as explained above.
Mihai
On Thu, Apr 9, 2015 at 8:25 PM, Mihai Moldovan <ionic@ionic.de> wrote:
On 10.04.2015 02:05 AM, Michael DePaulo wrote:
Most beginner Linux sysadmins know that bad things will happen if you delete /etc/passwd. Very few beginner Linux sysadmins know that your desktop environment might not start if you have weird syntax in ~/.*profile or ~/.*rc . A moderately skilled Linux sysadmin who rarely uses a GUI is unlikely to know about this also.
So I think we should document it somewhere on the wiki, perhaps under a troubleshooting section.
On 10.04.2015 02:05 AM, Robert Dinse wrote:
It might be something to add to the troubleshooting section ofthe Wiki.
That sounds very reasonable.
Also, a more helpful error message might still be worth implementing.
Mh, nope. There's no error message, because there was no error, as far as X2Go Client/nx is concerned. A command was successfully started and terminated. Although a "stray" bash process is not what the user *intended* to get, it's what the command ultimately did.
The only way to detect a session almost immediately terminating is to track the time between x2goruncommand start and session termination. If that's too low, say, under a minute, print out an error message. But this will also cause a false positive if the user really *intended* to terminate the session very quickly - for whatever reason. Maybe because it was meant as a quick test to see if X2Go is working at all.
I'd like to avoid such ambiguity.
I was thinking more like 5 seconds. Or perhaps 2 seconds if that turns out to be sufficient empirically.
I can generally change the error message Chris did get by sheer "luck" the second time around, but the point is that this (in this special case unhelpful) error message doesn't even come up reproducibly -- because a successfully created or attached session terminating is in general no error, as explained above.
Mihai
OK, this was the point of confusion. I was thinking for some reason that he got this error message reproducibly.
-Mike
To test this theory, I tried setting my shell to csh and tcsh on theDebian server with xfce desktop, x2go worked fine with both for me. Only difference was when I brought up a terminal emulator I got a csh % shell prompt instead of the ksh prompt I usually get.
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- Eskimo North Linux Friendly Internet Access, Shell Accounts, and Hosting. Knowledgeable human assistance, not telephone trees or script readers. See our web site: http://www.eskimo.com/ (206) 812-0051 or (800) 246-6874.
On Thu, 9 Apr 2015, Michael DePaulo wrote:
Date: Thu, 9 Apr 2015 18:10:38 -0400 From: Michael DePaulo <mikedep333@gmail.com> To: Christoph Schmidt-Hieber <christsc@gmx.de> Cc: Mihai Moldovan <ionic@ionic.de>, x2go-user@lists.x2go.org Subject: Re: [X2Go-User] X authorization issues
On Apr 9, 2015 3:55 PM, "Christoph Schmidt-Hieber" <christsc@gmx.de> wrote:
On Thu, Apr 09, 2015 at 09:45:38PM +0200, Mihai Moldovan wrote:
On 09.04.2015 09:35 PM, Christoph Schmidt-Hieber wrote:
x2goserver-xsession is installed.
Re-installing didn't help. Also, there's still no ~/.xsession-x2go-errors file.
That's very weird... according to your log file, xfce4-session terminates almost immediately after being launched. It's also launched via X2Go's xsession feature, so ~/.xsession-x2go-errors should be
populated.
This is defined in /etc/x2go/Xsession. Can you check that file for ERRFILE, just in case?
Something must be "failing", either the Xsession script itself or the actual xfce4-session.
$ grep -n ERRFILE /etc/x2go/Xsession 73:ERRFILE=$HOME/.xsession-x2go-errors 76:if (umask 077 && touch "$ERRFILE") 2> /dev/null && [ -w "$ERRFILE" ] && [ ! -L "$ERRFILE" ]; then 77: chmod 600 "$ERRFILE" 78:elif ERRFILE=$(mktemp 2> /dev/null); then 79: if ! ln -sf "$ERRFILE" "${TMPDIR:=/tmp}/xsession-x2go-$USER"; then 81: "\"$ERRFILE\"; look for session log/errors in"
88:exec >>"$ERRFILE" 2>&1Hi Christoph,
What is your default shell on the server? I have seen various x2go problems (but not this exact problem) when it was set to /bin/tcsh (or a /bin/csh symlink to /bin/tcsh). I suspect that the actual legacy /bin/csh binary would behave even worse with x2go.
-Mike
With tcsh, I have observed:
- X2Go Client for Windows Kerberos 5 (GSSAPI) authentication failing.
- Sessions not being cleaned up after a user logs out of the desktop environment. (But the session being gracefully terminated from the user's perspective.) To see if this is happening, run: sudo x2golistsessions_root
I need to try to reproduce these issues at home.
-Mike
On Thu, Apr 9, 2015 at 6:20 PM, Robert Dinse <nanook@eskimo.com> wrote:
To test this theory, I tried setting my shell to csh and tcsh on theDebian server with xfce desktop, x2go worked fine with both for me. Only difference was when I brought up a terminal emulator I got a csh % shell prompt instead of the ksh prompt I usually get.
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- Eskimo North Linux Friendly Internet Access, Shell Accounts, and Hosting. Knowledgeable human assistance, not telephone trees or script readers. See our web site: http://www.eskimo.com/ (206) 812-0051 or (800) 246-6874.
On Thu, 9 Apr 2015, Michael DePaulo wrote:
Date: Thu, 9 Apr 2015 18:10:38 -0400 From: Michael DePaulo <mikedep333@gmail.com> To: Christoph Schmidt-Hieber <christsc@gmx.de> Cc: Mihai Moldovan <ionic@ionic.de>, x2go-user@lists.x2go.org Subject: Re: [X2Go-User] X authorization issues
On Apr 9, 2015 3:55 PM, "Christoph Schmidt-Hieber" <christsc@gmx.de> wrote:
On Thu, Apr 09, 2015 at 09:45:38PM +0200, Mihai Moldovan wrote:
On 09.04.2015 09:35 PM, Christoph Schmidt-Hieber wrote:
x2goserver-xsession is installed.
Re-installing didn't help. Also, there's still no ~/.xsession-x2go-errors file.
That's very weird... according to your log file, xfce4-session terminates almost immediately after being launched. It's also launched via X2Go's xsession feature, so ~/.xsession-x2go-errors should be
populated.
This is defined in /etc/x2go/Xsession. Can you check that file for ERRFILE, just in case?
Something must be "failing", either the Xsession script itself or the actual xfce4-session.
$ grep -n ERRFILE /etc/x2go/Xsession 73:ERRFILE=$HOME/.xsession-x2go-errors 76:if (umask 077 && touch "$ERRFILE") 2> /dev/null && [ -w "$ERRFILE" ]
&& [ ! -L "$ERRFILE" ]; then
77: chmod 600 "$ERRFILE" 78:elif ERRFILE=$(mktemp 2> /dev/null); then 79: if ! ln -sf "$ERRFILE" "${TMPDIR:=/tmp}/xsession-x2go-$USER"; then 81: "\"$ERRFILE\"; look for session log/errors in"
88:exec >>"$ERRFILE" 2>&1Hi Christoph,
What is your default shell on the server? I have seen various x2go problems (but not this exact problem) when it was set to /bin/tcsh (or a /bin/csh symlink to /bin/tcsh). I suspect that the actual legacy /bin/csh binary would behave even worse with x2go.
-Mike
-
Christoph Schmidt-Hieber -
Michael DePaulo -
Mihai Moldovan -
Robert Dinse