|
From: Paul FM <pa...@me...> - 2012-01-10 13:35:48
|
To get rid of the error, you will have to do a test to see if the module function is defined before trying to define it in your init scripts. My guess is that jobs start in a sub shell which causes a second call to module init when the module function is already defined (you could also stop exporting the module function). The syntax error might just be a result of the error importing the module function (the line where the function definition starts is invalid but the lines OF the function are still being interpreted - bash still has a few minor bugs). We are still using Modules 3.1.6 which does NOT export the module function in the init script - and non of our init scripts export it either (so this problem doesn't seem to happen). Also, the module definition is ONE line in the modules/default/init/bash script (I don't know what it looks like in the later versions). Our modules are initialized in the rc scripts (the login script calls the rc script if the shell doesn't do so by default). Mark Suhovecky wrote: > > I wanted to follow up on my previous mail. > > To Recap, we run Modules 3.2.8 under RHEL5.7 in a cluster environment > managed with SGE (actually Univa GE as of last weekend). The problem > we were seeing is that sourcing the Modules/current/init/bash from > .bash_profile doesn't seem to work with for the non-interactive bash shells > for submitted GE jobs. > > After trying the various remedies suggested by this group, the one that seemed > to work for us was to use the qsub -v BASH_ENV=~/.bash_profile. This works; > however, now that we've tested it for several days, there is a side effect. We > have a number of MPI packages we manage with Modules, and when > someone submits an mpijob using bash shell, Modules, and mpiexec, we'll > see the following errors in the output: > > bash: module: line 1: syntax error: unexpected end of file > bash: error importing function definition for `module' > > and these two messages will be repeated for each machine, > so if for instance my MPI job was spread across 4 machines, these > two errors show up 4 times. Curiously, the job still runs successfully > > I've got no idea what's causing this, but at least it works. > > We' tried going back to Modules 3.2.6, and using Modules 3.2.9, > but experienced the same symptoms. > > Quite puzzling, this. > > Mark Suhovecky > HPC System Administrator > Center for Research Computing > University of Notre Dame > suh...@nd... > ________________________________________ > From: Mark Suhovecky [suh...@nd...] > Sent: Tuesday, January 03, 2012 5:34 PM > To: Environment Modules usage and discussion. > Subject: Re: [Modules] bash init problem? > > Josea, Erin, Orion, Mark- > > Thank you all for your comments. This was my first post to this list- it looks like > there's a good user community here! > > Josea, I tried adding a modules.sh to the /etc/profile.d, sourcing in the modules bash init. It didn't make a difference. You mentioned > having to "patch" 3.2.8- do you recall what changes were needed? > > Orion, we've already added bash to the login_shell list, and our .bash_profile sources the .bashrc. I tried the qsub -v BASH_ENV , and > that worked! I got one solution now :) > > Mark, we moved to 3.2.8 from 3.2.6 about a year ago. At the time we used it, we only supported csh. We're going to trying going back to 3.2.6 > this evening and see if out bash submissions work with the older version. > > Mark > > > Mark Suhovecky > HPC System Administrator > Center for Research Computing > University of Notre Dame > suh...@nd... > ________________________________________ > From: J Alejandro Medina [jos...@gm...] > Sent: Tuesday, January 03, 2012 4:45 PM > To: Environment Modules usage and discussion. > Subject: Re: [Modules] bash init problem? > > I do remember having to patch this to make it work with /bin/bash although it used to work without error when using -S /bin/sh instead of -S /bin/bash > > On Tue, Jan 3, 2012 at 3:34 PM, Orion Poplawski<or...@co...<mailto:or...@co...>> wrote: > On 01/02/2012 08:10 PM, Mark Suhovecky wrote: >> Hi- >> >> We're running modules 3.2.8 under RHEL 5.5. >> It's compiled from C. >> >> We support both csh and bash as login shells; >> the .cshrc and .bashrc files contain the line >> >>> source /opt/Modules/current/init/bash >> >> or >> >>> source /opt/Modules/current/init/csh >> >> to set up the modules environment. >> >> This works fine for both shells for normal logins via ssh. >> >> Our user environment also includes a job submission system (SGE). >> When a user submits a job, remote jobs with have access to the module environment; >> however, jobs with bash do not- the module command cannot be found. >> >> I've verified that the .bashrc is being called. >> >> I notice that the csh init creates an alias for module, whereas the bash script defines and exports a function >> named module. I'm guessing this might have something to do with it, but after several days of trying to >> debug it, I still don't know quite what's happening. >> >> If anyone could shed any light on this, it would be highly appreciated. > > The main wrinkle is that sge was not written with bash in mind. The default > value for login_shells in sge_conf is "sh,ksh,csh,tcsh", which are the shells > started as "login shells" by default. Since bash is not on that list it is > not started as a login shell. Nor is it an "interactive" shell, which would > read ~/.bashrc. > > So, you can either run "qconf -mconf" and add bash to login_shells and make > sure ~/.bash_profile sources ~/.bashrc, or pass a -v BASH_ENV=~/.bashrc option > to qsub to allow ~/.bashrc to be sourced. > > > -- > Orion Poplawski > Technical Manager 303-415-9701 x222<tel:303-415-9701%20x222> > NWRA/CoRA Division FAX: 303-415-9702<tel:303-415-9702> > 3380 Mitchell Lane or...@co...<mailto:or...@co...> > Boulder, CO 80301 http://www.cora.nwra.com > > ------------------------------------------------------------------------------ > Write once. Port to many. > Get the SDK and tools to simplify cross-platform app development. Create > new or port existing apps to sell to consumers worldwide. Explore the > Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join<http://appdeveloper.intel.com/join> > http://p.sf.net/sfu/intel-appdev > _______________________________________________ > Modules-interest mailing list > Mod...@li...<mailto:Mod...@li...> > https://lists.sourceforge.net/lists/listinfo/modules-interest > > > > -- > J. Alejandro Medina > HPC System Administrator > High Performance Computing Facility > University of Puerto Rico > > **The contents of this email are confidential and for the exclusive use of the intended recipient(s). If you receive this email in error you should not copy it, retransmit it, use it or disclose its contents but should return it to the sender immediately and delete your copy. > > > ------------------------------------------------------------------------------ > Write once. Port to many. > Get the SDK and tools to simplify cross-platform app development. Create > new or port existing apps to sell to consumers worldwide. Explore the > Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join > http://p.sf.net/sfu/intel-appdev > _______________________________________________ > Modules-interest mailing list > Mod...@li... > https://lists.sourceforge.net/lists/listinfo/modules-interest > > ------------------------------------------------------------------------------ > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex > infrastructure or vast IT resources to deliver seamless, secure access to > virtual desktops. With this all-in-one solution, easily deploy virtual > desktops for less than the cost of PCs and save 60% on VDI infrastructure > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox > _______________________________________________ > Modules-interest mailing list > Mod...@li... > https://lists.sourceforge.net/lists/listinfo/modules-interest -- --------------------------------------------------------------------- The views and opinions expressed above are strictly those of the author(s). The content of this message has not been reviewed nor approved by any entity whatsoever. --------------------------------------------------------------------- Paul Markfort Info: http://www.umn.edu/~paulfm --------------------------------------------------------------------- |
