Bug 1146958

Summary: after new bash-4.1.2-15.el6_5.2.x86_64 and environment-modules-3.2.10-1.el6_5.x86_64 installed results with at jobs stopped working
Product: Red Hat Enterprise Linux 6 Reporter: Rikard <rikard.oberg>
Component: atAssignee: Tomas Mraz <tmraz>
Status: CLOSED DUPLICATE QA Contact: qe-baseos-daemons
Severity: high Docs Contact:
Priority: unspecified    
Version: 6.5CC: dirk.gfroerer, fweimer, koen.schram, ooprala, poulacou2, uncoolbob
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-10-04 07:16:18 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Rikard 2014-09-26 12:34:59 UTC
Description of problem:
After updating to new bash-4.1.2-15.el6_5.2.x86_64 and having environment-modules-3.2.10-1.el6_5.x86_64 installed "at jobs" stopped working

Version-Release number of selected component (if applicable):
bash-4.1.2-15.el6_5.2.x86_64
environment-modules-3.2.10-1.el6_5.x86_64

How reproducible:
install bash-4.1.2-15.el6_5.2.x86_64 and environment-modules-3.2.10-1.el6_5.x86_64
log on/off 
[user@testburk ~]$ at now
at> echo hej
at> <EOT>
job 9 at 2014-09-26 14:26
[user@testburk ~]$

output from at job (sent as email via .forward file):
sh: line 31: syntax error near unexpected token `=\(\)\ {\ \ eval\ \`/usr/bin/modulecmd\ bash\ \$\*\`"
"}'
sh: line 31: `"}; export BASH_FUNC_module()'


Steps to Reproduce:
1. install bash-4.1.2-15.el6_5.2.x86_64 & environment-modules-3.2.10-1.el6_5.x86_64
2. log on / off
3. run at job
4. yum remove environment-modules-3.2.10-1.el6_5.x86_64 and logon/off and at jobs can be run again

Actual results:


Expected results:


Additional info:
We need to have environment-modules-3.2.10-1.el6_5.x86_64 installed because of dependency's to  mpich2  mpich2-devel openmpi  openmpi-devel

Comment 2 Jan Synacek 2014-09-29 10:24:18 UTC
Easily reproducible with just running "at" and then checking email. I'm not sure where the piece of code you're seeing is coming from. I'll investigate further.

Comment 3 Jan Synacek 2014-09-29 11:14:25 UTC
Currently, this is a problem with "at" generating output from the environment and passing everything as is. Until bash was fixed, this worked well, because functions were simply output as functions. With the bash fix, though, functions are output with a special "BASH_FUNC_" prefix and that breaks when one attempts to source the output back to the shell.

Before shellshock fix, "at" generated (taken from /var/spool/at/):
...
module=\(\)\ {\ \ eval\ \`/usr/bin/modulecmd\ bash\ \$\*\`"
"}; export module
...

After the fix:
...
BASH_FUNC_module()=\(\)\ {\ \ eval\ \`/usr/bin/modulecmd\ bash\ \$\*\`"
"}; export BASH_FUNC_module()
...

The module() function gets sourced from /etc/profile.d/modules.sh, which in turn sources /usr/share/Modules/init/$shell, where shell == "bash" in this case. The corresponding definition and export looks like this:

module() { eval `/usr/bin/modulecmd bash $*`; }
export -f module

I suggest a workaround in "at" that will check for the "BASH_FUNC_" prefix and strip it if present. It would be better if bash didn't prefix the function exports with anything, though.

Comment 4 Jan Synacek 2014-09-29 11:17:21 UTC
Reassigning to "at" and CCing bash maintainer.

Ondrej, could you please share your thoughts on comment 3?

Comment 5 Rikard 2014-09-29 11:35:11 UTC
Hi again

Just trying to help I saw bugzilla created after this one about the same issue:
https://bugzilla.redhat.com/show_bug.cgi?id=1147043#c8

There Florian Weimer suggests a "limited workaround" by editing "/etc/profile.d/modules.sh" but he is not sure about functionality impact on environment-modules, so it needs more testing.

Comment 6 Ondrej Oprala 2014-09-29 11:48:25 UTC
Thanks Rikard.
Florian is currently discussing this with at's upstream, so I think it's best to wait for some statement from them.

Comment 7 Tomas Mraz 2014-10-04 07:16:18 UTC

*** This bug has been marked as a duplicate of bug 1147043 ***