x2go error, stdin is not a tty
 

Hello. I'm not sure if I've posted this in the correct forum, I apologize if there is a better one.

I am using x2go server and I'm trying to run x applicatons on a remote client and when I try to connect, I'm getting the error: "stdin: is not a tty stty: standard input: Invalid argument". The environment that x2go server is installed on is Debian Jessie.

I also have installed x2go server on a different system, Ubuntu 16.04 installation, and it's working fine, I can remotely connect and run x window applications on the client.

I have tried to compare the two installs to spot differences that might be causing this problem but I can't really see anything. Google searching seems to lead me to the idea that there are some start up scripts running that are not properly testing for an interactive shell. I've only been able to find one place in /root/.profile that I thought might be the culprit and I amended from
to
But I still get the same error. I'm quite new to Linux so I'm at a bit of a loss at this point, any help would be appreciated, thanks!

often, debian packages need more configuring compared to ubuntu.
did you read the installation instructions, maybe a debian wiki article?
maybe start here (sidebar).

As a major aspect of the foundation of a session, x2go seems, by all accounts, to be executing both .bashrc and .bash_profile to fruition BEFORE really showing the session. I found that .bash_profile was executing mesg y and additionally another shell content that endeavored to utilize the esteem came back from tty as a variable (ie TTY=`tty`). Since these announcements are not being executed from inside a terminal they fizzled. The arrangement is to put them inside a test as pursues:
if `tty -s`
then
mesg y
TTY=`tty`
else`
TTY='not a tty'
fi
This fixed it on all sites I could not connect to. I suspect a recent change in x2go may have brought this into focus as these sites had not changed since my last successful x2go connections.

Sorry for the delayed response. I was able to figure out the problem. in /etc/profile, there was a custom script being included that I overlooked. /etc/profile was looping through and including all the scripts it could find in /etc/profile.d/ the culprit was called /etc/profile.d/custom.sh. This script was not testing for shell interactivity so I added the check and that fixed it.

thanks for psoting the solution!
could you mark this SOLVED, please (see my sig)?