Package: x2gobroker-agent
Version: 0.0.2.3

One of my users started to get their connections to the x2go broker 
failing with 'Error downloading http://x2go-broker-url/plain/inifile - 
server replied: Internal Server Error'

Tracking back through the commands the broker was logging the issue 
turned out be

/usr/lib/x2go/x2gobroker-agent $USER listsessions
(and other commands that x2gobroker-agent.pl runs by su - username -c 
command) returning things like

OK
[1] 32542
klipper: Command not found.
[1] + exit 1       klipper

which was a result of how the command is run;     since the 
x2gobroker-agent $USER FOO   commands all internally su to the named 
user to run the command it results in the user's environment being 
sourced which puts them at the risk of being broken by the user's 
environment.    My user in this case had embedded a command that didn't 
exist on the broker host to run as soon as their shell environment was 
created which caused the broker to error out.   (possibly compounded by 
in this case the shell tcsh being used as the user's default shell - 
tcsh in my experience being very temperamental with it's startup files - 
a single failure will stop the environment file sourcing to error our 
instantly and not process further lines.  I've not had time to cross 
compare with bash etc and see if this problem only exists for tcsh or if 
it effects most shells).

I managed to work around the issue in my case by fixing the su commands 
in x2gobroker-agent.pl to use /bin/sh (which links to /bin/dash) on my 
system to avoid user shell startup file environment issues breaking 
logging in via the broker.    It feels more like a workaround that a 
proper fix to me so I'm not suggesting the attached patch for merging,   
rather just as an example of how I got around it in my case.     My 
feeling is that there must be a better way to ensure these 
x2gobroker-agent commands can't be broken by the user env but I'm not 
managing to come up with a better solution currently.

Thanks
Jason