Upgraded XPP from 9.2.2 to 9.4.0 and now a perl program can not find strict.pm

Question

We upgraded our XPP from 9.2.2 to 9.4.0 and a perl program that has been working for at least the last 7 years is complaining about finding strict.pm. 
 The program works if I compile it and run it with the XPP perl. 
 But when background process runs it - there is an error 
 Can't locate strict.pm: /root/perl5/lib/perl5/warnings.pm: Permission denied at /opt/xyvision/xz/procs/site/APT.pl line 105. 
 Can't locate warnings.pm: /root/perl5/lib/perl5/warnings.pm: Permission denied at /opt/xyvision/xz/procs/site/APT.pl line 106. 
 
 Is there something wrong with our global variables? 
 Is there something wrong with our @INC for XPP. 
 I do see the PM files in XPP perl.... 
 find /opt/xyvision/xz/etcxyvision -name "strict.pm" /opt/xyvision/xz/etcxyvision/common/perl/lib/5.28.1/strict.pm 
 find /opt/xyvision/xz/etcxyvision -name "warnings.pm" /opt/xyvision/xz/etcxyvision/common/perl/lib/5.28.1/encoding/warnings.pm /opt/xyvision/xz/etcxyvision/common/perl/lib/5.28.1/warnings.pm

Jonathan Dagresta · Accepted Answer

Yes, the bgquer (background queues) and sproc (auto-processing) daemons are started with the 'root' user's environment/settings when the XPP server starts (or reboots). 
 So, you'll need to fix up the environment settings for the 'root' user for XPP - but you should be able to do that in a way that only will affect the startup environment of the XPP bgquer/sproc daemons and not have to affect anyone logged in as 'root' (unless you want to). 
 The bgquer/sproc daemons are started (and stopped) by ***xyenterprise entries (or files) in the /etc/rc#.d directories, which all should be soft-links to a delivered /etc/init.d/xyenterprise file (so, best not to edit/change this file since it is delivered). 
 This /etc/init.d/xyenterprise file sources a delivered /etc/xyvision/xyv.profile file (again, best not to edit/change this file). 
 At the end of xyv.profile, it checks for the existence of an optional XYV_EXECS/global.profile file and if the file exists it sources it. This file is not delivered by XPP, so this is where you want to do anything you need to do. 
 At a minimum I would suggest that in your global.profile file you'll want to unset the PERL5LIB variable and I would think you would also want to remove the /root/perl5/bin path from $PATH. 
 You might also want to unset the other PERL_XX_YY variables (that are being set in root's bashrc file) for good measure. 
 But be careful with this global.profile file; if you get the code wrong (e.g. a syntax error) then you'll probably find that the bgquer/sproc daemons don't get started properly.

Bart Terryn · Answer

Bill, 
 If this apt.pl thing is started through auto proc, the first thing to check is the entry in the autoprocessing spec. Is the entry a fully specified path to the perl executable? If so it should normally point to /etc/xyvision/common/perl/bin/perl which is the perl delivered with the xpp system (unless somebody in your company has a very good reason to run a different version of perl - I would seriously doubt whatever reason somebody might have to do so- but that is a totally other thing) 
 If the entry in the autoproc spec, just says apt.pl, then the next thing to do is to verify the magic line (the !# line) at the top of the APT.pl script to see what 'perl' you are running. If should be something like 
 #!/etc/xyvision/common/perl/bin/perl 
 If that is the case, the better way to check if Perl can find a certain module would be in that case: 
 >/etc/xyvision/common/perl/bin/perl -Mstrict -e 
 
 You will get nothing back if the module can be loaded successfully. And an overview of the content of @INC if things go wrong. 
 Also check that the /etc/xyvision/common/perl is still linked to the xpp delivered version of perl 
 But from the error messages you are getting back either the autoproc entry is using the 'wrong' version of perl (remember that a linux system might come with loads of different perl installations) or the magic line on apt.pl is either missing or pointing to the wrong perl installation.

XPP > XPP

Upgraded XPP from 9.2.2 to 9.4.0 and now a perl program can not find strict.pm

Top Replies