X2Go Bug report logs - #1133
Inconsistent Perl used by server or its agent on connect

Full log

Message #26 received at 1133@bugs.x2go.org (full text, mbox, reply):

Received: (at 1133) by bugs.x2go.org; 10 Jan 2017 23:42:40 +0000
From X2Go-ML-1@baur-itcs.de  Wed Jan 11 00:42:38 2017
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on
	ymir.das-netzwerkteam.de
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00,URIBL_BLOCKED
	autolearn=ham version=3.3.2
Received: from localhost (localhost [127.0.0.1])
	by ymir.das-netzwerkteam.de (Postfix) with ESMTP id 509923CC5F
	for <1133@bugs.x2go.org>; Wed, 11 Jan 2017 00:42:38 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at ymir.das-netzwerkteam.de
Received: from ymir.das-netzwerkteam.de ([127.0.0.1])
	by localhost (ymir.das-netzwerkteam.de [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id JL3ytssL2riJ for <1133@bugs.x2go.org>;
	Wed, 11 Jan 2017 00:42:31 +0100 (CET)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24])
	by ymir.das-netzwerkteam.de (Postfix) with ESMTPS id 941DE5DA91
	for <1133@bugs.x2go.org>; Wed, 11 Jan 2017 00:42:31 +0100 (CET)
Received: from [192.168.0.23] ([78.43.90.159]) by mrelayeu.kundenserver.de
 (mreue103 [212.227.15.145]) with ESMTPSA (Nemesis) id
 0MLRLO-1cReI10FNq-000ZnW for <1133@bugs.x2go.org>; Wed, 11 Jan 2017 00:42:31
 +0100
Subject: Re: [X2Go-Dev] Bug#1133: Inconsistent Perl used by server or its
 agent on connect
To: 1133@bugs.x2go.org
References: <BF57B030-7BF4-4307-9333-49782AB84D74@ucdavis.edu>
 <7a1f025f-6a4f-9c6a-ffe6-4d18a712da86@baur-itcs.de>
 <E4861E92-0216-40D2-91E6-A6A693F5E30B@ucdavis.edu>
From: Stefan Baur <X2Go-ML-1@baur-itcs.de>
Message-ID: <836dd91e-6bc3-35e1-3759-e66b55715b1b@baur-itcs.de>
Date: Wed, 11 Jan 2017 00:42:20 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <E4861E92-0216-40D2-91E6-A6A693F5E30B@ucdavis.edu>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="I3E8O7epx7H1XM4VMxdX69M87uuO2tCpj"
X-Provags-ID: V03:K0:sl/ACYXeJZw76ZViGMuBf9vUsdz3v29FrL/bc2Kvo6v69xZft78
 5A/cVeNn9KKNgxwVxetTIpRawbbCvFxpWMh9QSXmuoSw50W0JbPJpepfhfgQtExJcuozSjd
 CoLVynOVNN34mwZsM7VZ7SzMCihMvbrvksOkK5//w7mdsNIgRxuSxJMEts/sYMlKzgB1jL7
 vEl4WxNSRy0eawBhf4yTQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:XaMyKqLlr38=:J24xaYe6u/PXAmNNvrEzo9
 gnUNDLXEgAUyLYhdWI3EYZyh1MWCbXKCvTAi97ARd6/bL32G9gk8C8ExVcEQtvzBN6ykP+/kb
 k/Umn9vy70PeUoAj9SpT5+362SmpZkkDYmPhvRR3YWB6YyoVrIO5axJkpkHC3jVG6IUppsBlb
 6tupakm2/xqdYpTo9jP4cnBhBFhpZgWAuMRpi2XiETt5m44PTU41OXNSG2YVFSrvdu2WjOT/d
 emVq5WvU8HzC4u662KPVFMQUEGCVOpHlJzv/GFaLCzl2sqo6CVhqFh/zs4QgzLyTCptxX6AmF
 rWqjyZhqTVTt8rcHE736i7x0qjLCCg7s0gHaR8vGg4BQVHDW5h7rnSdY0PG1UvZI2oXz4ADat
 4uQdol8pfMPiCvSWKSmkLBT9VXAk03W9gS4uCdWGImmteNiVR1VxLJVAh5y+7SToC7dAHNNHo
 TzH0mIzxDzWofsljk7KiY5+ayshUVwUoVe7GC3mVo/66XPi46nCaME6jFHGcMU9mQOlzpa4yn
 3I3nKYh1h2eAxjQOlzSzZocrCcaSUUue1BDByLGPN45HFFrp1Mgu9uBNX/CdJiLX7x1LO5zOw
 0LBQyO8VeaHbc14jadyW9uyZggSWRwl5U1D9L8XEGrrilla0F4BUtB0QTUxeQOnLxRtxF24Nx
 aD0dB+9Xk9d/rr948iYIk8lHLvnICF0GEcJ1dnmt77+0eTO+bO9g1bvhegMQagz9Bu8Q=

[Message part 1 (text/plain, inline)]

Ted,

let's examine a few things here:

You're saying that nxagent is doing things in Perl, and not the right
things.  When examining the contents of the nxagent package, all I'm
seeing wrt/ executables are bash scripts and compiled binaries, but
nothing written in Perl.
So the nxagent package can't be at fault.

We *do* have scripts that are written in Perl, and that might throw the
error you quoted.  Those are e.g. in the package with the name
x2goserver (and I wouldn't be surprised to find more of them in other
packages that have names beginning with x2go*).

grep '^#!.*perl*' /usr/bin/x2go* returns a list of scripts that all have
#!/usr/bin/perl as shebang, so yes, it's probably safe to say that the
use of /usr/bin/perl as the Perl interpreter for our scripts is hardcoded.

But again, that's not a bug, but how scripting works on Linux/Unix.
First line with shebang tells the shell which interpreter to use, so you
don't have to prefix the script name with the name of the interpreter
each time.

And of course, if you set a variable with a name matching one that "a"
Perl interpreter (be it ActivePerl or the system standard shipped with
your distribution) looks for, it will use it.

Your statement that the version of Perl being used depends on which one
comes first in the path might be true on Windows; on Unix, it will only
be true for when you type "perl" without a path in an interactive shell,
or for when call it from within, say, a bash script without preceding it
with a path.
Once you chmod +x a Perl script and call it by its name, without
prefacing the name and full path to the interpreter, the shebang line
will be used to determine the interpreter.

So, if you need to set PERL5LIB for your ActivePerl installation, it
should be unset (by adding a suitable if/then clause) when your .bashrc
/ .bash_profile are read and parsed by an X2Go task.
It's kind of weird that, according to your other bug report, you have
exactly 0 indication that you're running from within an X2Go session.
I can see how that makes it difficult to script around it ;-) - but
let's track that in the other bug report.

Kind Regards,
Stefan Baur

Am 10.01.2017 um 23:48 schrieb Ted Toal:
> I disagree.  Perl behavior is to look at env. var. PERL5LIB to find its library.  This should be set to match the Perl that is being invoked, which is normally done by placing that Perl’s bin directory on the path.  Since I did place it on the path, there are only two possibilities for why x2go ran /usr/bin/perl: either it hard-coded the path to Perl, in which case it should first set PERL5LIB (or maybe there is a Perl command line arg to specify the library folder), OR x2go ignored my changes to PATH when it ran perl (in which case it should also ignore PERL5LIB).
> 
> - Ted
> 
> 
> 
> 
>> On Jan 10, 2017, at 2:35 PM, Stefan Baur <X2Go-ML-1@baur-itcs.de> wrote:
>>
>> Control: close -1
>> Control: tag -1 not-a-bug
>>
>> Am 10.01.2017 um 22:15 schrieb Ted Toal:
>>> Package: NXAGENT
>>> Version: 3.5.0
>>>
>>> My .bash_profile defines Perl environment variables for Active Perl, and adds the Active Perl bin directory to the start of the path. This causes an x2go session to fail with the message:
>>> Connection failed. /usr/bin/perl: symbol lookup error: /share/carvajal-archive/PACKAGES/local/ActivePerl-5.24/lib/auto/Sys/Hostname/Hostname.so: undefined symbol: Perl_xs_handshake
>>> NXAGENT is user /usr/bin/perl and ignoring the Perl bin directory at the start of the path, but it is nevertheless using the Perl environment variables and so is looking in the wrong place for the Perl library.
>>
>> I'd say this isn't a bug, but actually expected behavior.
>> If you need different values for variables depending on which software
>> you run, you either need to prefix them manually each time you call that
>> software, or write a wrapper script, or use if/then clauses in your
>> .bash_profile.  The latter is what you seem to have decided to do, and
>> ran into problems with, judging from your bug report #1134, thus closing
>> this one.
>>
>> -Stefan
>>
>>
>> -- 
>> BAUR-ITCS UG (haftungsbeschränkt)
>> Geschäftsführer: Stefan Baur
>> Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364
>> Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
>>
> 


-- 
BAUR-ITCS UG (haftungsbeschränkt)
Geschäftsführer: Stefan Baur
Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364
Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243

[signature.asc (application/pgp-signature, attachment)]

Send a report that this bug log contains spam.