Am 29.11.2011 um 15:57 schrieb Prentice Bisbal: > 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
If you check with: $ env it might be there (on the headnode I assume - or any default variables defined for export in any of the sge_request files?). This is the bug in SGE 6.2u5, that it can't handle multi lines variables. But it's still curious: where it's coming from. -- Reuti >> >>> -- >>> 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 >>>>>> users@gridengine.org >>>>>> https://gridengine.org/mailman/listinfo/users >>>>> _______________________________________________ >>>>> users mailing list >>>>> users@gridengine.org >>>>> https://gridengine.org/mailman/listinfo/users >> > _______________________________________________ > users mailing list > users@gridengine.org > https://gridengine.org/mailman/listinfo/users _______________________________________________ users mailing list users@gridengine.org https://gridengine.org/mailman/listinfo/users
