On 11/28/2011 07:01 PM, Reuti wrote: > Am 28.11.2011 um 21:00 schrieb Prentice Bisbal: > >> On 11/23/2011 10:10 AM, Reuti wrote: >>> Am 23.11.2011 um 16:01 schrieb Prentice Bisbal: >>> >>>> Schmidt, >>>> >>>> I've been having the same problem ever since I upgraded my cluster >>>> nodes to RHEL 6. A few weeks ago. My SGE installation was not touched >>>> during the upgrade, since it's on an NFS partition, and the head node >>>> was not touched during the upgrade, either. The error seems harmless, >>>> and I haven't tracked it down yet, but the existence of that error >>>> message, harmless or not, is a problem, as users keep reporting it when >>>> they see it. >>> Interesting. Did the version of the bash change with the upgrade? >>> >>> -- Reuti >>> >> Sorry for the delayed response. Still behind on my mailing lists since >> going to SC11. >> >> Yes, the version of bash changed with the upgrade. >> >> On a 5.7 system: >> >> $ bash --version >> GNU bash, version 3.2.25(1)-release (x86_64-redhat-linux-gnu) >> Copyright (C) 2005 Free Software Foundation, Inc. >> >> $ rpm -q bash >> bash-3.2-32.el5 > Is this one and the same package. I mean the first looks like 64 bit the > latter like 32bit. Or do they use a 32 bit shell on a 64 bit system? >
I just double-checked. Yes, those are one and the same package. I have no idea why the 64-bit package doesn't end in x86_64 in this case. To verify: # which bash /bin/bash # /bin/bash --version GNU bash, version 3.2.25(1)-release (x86_64-redhat-linux-gnu) Copyright (C) 2005 Free Software Foundation, Inc. # rpm -qf /bin/bash bash-3.2-32.el5 I'm using a local rebuild of RHEL, called PUIAS Linux (google it), so maybe the maintainers (ie the guy down the hall) messed up the packaging when rebuilding. >> On a 6.1 system: >> >> $ bash --version >> >> GNU bash, version 4.1.2(1)-release (x86_64-unknown-linux-gnu) >> Copyright (C) 2009 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later >> <http://gnu.org/licenses/gpl.html> >> >> $ rpm -q bash >> bash-4.1.2-8.el6.x86_64 > Do you use modules on the headnode of the cluster and forward all variables > with -V like the OP? The environment is set by sourcing the created > "environment" in the job's spool directory. You can peek into this file and > check whether it's there. > > The question is for the OP too: do you need -V? Open MPI will use it > automatically when going from the master node of the parallel job to the > slaves. I don't use modules on any of my systems (yet). After getting this error, I did install the modules package, thinking it might fix the problem, but it didn't. The environment-modules RPM isn't even installed on the head node. I do instruct my users to use -V to forward environment variables in their job scripts. Not all of the jobs submitted on my cluster are Open MPI jobs. I did verify that the environment file is in the job's spool directory for a test job, and I also saw this line was in there: module=() { eval `/usr/bin/modulecmd bash $*` I don't know where the missing closing brace disappeared to, or where that module > >> -- >> Prentice >> >> >>>> --- >>>> Prentice >>>> >>>> >>>> On 11/23/2011 09:07 AM, Schmidt U. wrote: >>>>> Dear all, >>>>> I know, the problem was discusses one or two years before, but I still >>>>> have trouble to eliminate messages in.err file: >>>>> I'm using SGE 6.2u5 and for every allocated node of an openmpi job the >>>>> sge job's error file has two lines like this: >>>>> //bin/bash: module: line 1: syntax error: unexpected end of file >>>>> /bin/bash: error importing function definition for `module'/ >>>>> I defined in global bashrc: >>>>> /MODULEPATH=... >>>>> MODULESHOME=... >>>>> alias module='/usr/bin/modulecmd bash $*' >>>>> module load default_module/ >>>>> So far I do not need additional settings in the job script file >>>>> concerning module environment, as well >>>>> /#$ -V/ >>>>> is used. >>>>> The both lines/ /bin/bash:.../ in the err file have no effects, but >>>>> even new users are sometimes rattled. >>>>> Is anybody affected as well with this problem and found a solution to >>>>> eliminate these messages ? >>>>> >>>>> Udo >>>>> >>>>> >>>>> _______________________________________________ >>>>> users mailing list >>>>> [email protected] >>>>> https://gridengine.org/mailman/listinfo/users >>>> _______________________________________________ >>>> users mailing list >>>> [email protected] >>>> https://gridengine.org/mailman/listinfo/users > _______________________________________________ users mailing list [email protected] https://gridengine.org/mailman/listinfo/users
