View Full Version : Unexplained bash error

15th November 2007, 07:01 AM
Hi All-

I don't know what happened to cause this, but everytime I bring up a terminal window now, I get this error message:

bash: --no-exec-shield: command not found
[paulm@speedie ~]$

Everything works as normal, and the error message only appears at first startup of the terminal. It is also not dependent on which terminal as it occurs in gnome-terminal or eterm and this happens whether I log in as a regular user or root. I have looked in ~/.bashrc and /etc/bashrc and find nothing suspicious.

This began to happen sometime either during or after I had been installing a couple of rpm files (the game pysol and generic for i686 arch) and a few dependencies that they needed, and then uninstalling them when the program wouldn't run. I found another rpm file specific to fc6 for the game which I installed and which worked out fine. My only known mis-step during all that was to type: sudo -e pysol , leaving out the rpm cmd, which instantly brought me into the VIM editor and I fail to see any connection there.

Any clues to eliminate this annomaly would be appreciated.


15th November 2007, 08:00 AM

You might want to check this (http://forums.fedoraforum.org/archive/index.php/t-116017.html) out.

15th November 2007, 03:15 PM
Hello pobbz-

Thank you for the link. My Google search for this problem turned up nothing. I explored all the avenues suggested in that link and came up without a solution. Checking the contents of /proc/sys/kernel/exec-shield revealed a value of 1 (link info states it should be 0). Changing the value to 0 with the following command made no difference.

$ sudo echo '0' > /proc/sys/kernel/exec-shield
Reading the man page for sysclt left me without a clue as to how to use it to change this behavior using that command. My next step will be to run the prelink command to see if that "fixes" anything.

$ sudo prelink --all --force fixes nothing.

Thank you again,

15th November 2007, 10:00 PM
After installing from rpms or from source, it can be difficult to determine who stepped on what.

You could change to some expendable directory like MY_JUNK.

Then you can possibly extract files in suspect_rpm with
rpm2cpio suspect_rpm | cpio -idm

and, if all goes according to plan, it should (hopefully) extract into subdirs of the current directory which should be something like MY_JUNK

Then, seek out the culprit with
grep -r "no-exec-shield" *

If you cannot find the culprit, then live with it (like we always did with windows after a spyware or virus), or restore from a backup that was made prior to the foul-up.

If you can determine what got stepped on, it may be possible to reinstall with yum, the package that had somebody step in something.

15th November 2007, 10:52 PM
Also check .bash_profile and /etc/profile

16th November 2007, 01:10 AM
imo, thanks for your suggestion. I had already used rpm to uninstall the programs, then deleted the rpm files, though I kept the dependency files I had to chase down with yum in order to install them. I strongly suspect it was the pysol-4.81-something.i686.rpm, along with a companion pysol-cardset-classic-<version.i686.rpm that I grabbed from rpmfind that caused the problem, most likely when attempting to run the program, rather than from the install itself. After all the digging I've done trying to resolve this, I've come to the conclusion I just may well have to "live with it". It does no harm, but it will haunt me like a ghost until I track it down, if ever.

JEO, I've checked all those and many many more config files trying to root this one out.

I would add, that the bash error message appears at the begining of every spawn or respawn of a terminal window, including booting directly into init 3.

Thanks again to all-

16th November 2007, 04:25 AM
The Hail Mary pass ...

sudo find / -type f -exec grep -H "no-exec-shield" {} \; | tee H_M_LOG

... could take some time, and stands the slightest chance of success ...

While waiting for it to finish, you can go to another terminal and watch what it is being grepped at the moment with
ps -efw

Weeding through H_M_LOG may show all the web caches of searches for this string and other bizarre things ... and may possibly identify the schmo.

16th November 2007, 02:52 PM
Imo, you really know your stuff. I had been thinking of perhaps asking for a command string that would do just that, search all files on the whole danged drive for that particular text string and log any hits to a file. I'm running that command as I type this..... report to follow.


16th November 2007, 03:17 PM
Yes, it was a lengthy run, but it never got a chance to finish. It was working just swell until it got into the /proc directory, where it began spitting out various warning messages. When it got to /proc/kcore, it locked up the run and I had to halt it with CTRL-C. I'll browse through some man pages to figure out how to exclude the /proc dir from that system wide search and try again.

bash: --no-exec-shield: command not found
[paulm@speedie ~]$ sudo find / -type f -exec grep -H "no-exec-shield" {} \; | tee H_M_LOG
Binary file /usr/sbin/prelink matches
/home/paulm/.mozilla/firefox/fbn9h2wf.default/history.dat: =http://www.google.com/search?q=bash%3A+--no-exec-shield%3A+command+not+fo\
/home/paulm/.mozilla/firefox/fbn9h2wf.default/history.dat: =http://www.google.com/search?q=--no-exec-shield+command+not+found&ie=utf-\
/home/paulm/.mozilla/firefox/fbn9h2wf.default/history.dat: =http://www.google.com/search?q=bash%3A+--no-exec-shield&ie=utf-8&oe=utf-8\
/home/paulm/.mozilla/firefox/fbn9h2wf.default/history.dat: =http://www.google.com/search?q=kernel+--no-exec-shield&ie=utf-8&oe=utf-8&\
Binary file /home/paulm/.mozilla/firefox/fbn9h2wf.default/Cache/_CACHE_001_ matches
/home/paulm/.bash_history:locate --no-exec-shield
/home/paulm/.bash_history:locate no-exec-shield
/home/paulm/.bash_history:sudo prelink -a -m --no-exec-shield
/home/paulm/.xsession-errors:/etc/sysconfig/prelink: line 14: --no-exec-shield: command not found
/etc/sysconfig/prelink:PRELINK_OPTS=-m --no-exec-shield
grep: /proc/acpi/event: Device or resource busy
grep: /proc/sys/net/ipv4/route/flush: Permission denied
grep: /proc/sys/fs/binfmt_misc/register: Invalid argument
grep: /proc/sysrq-trigger: Invalid argument
grep: /proc/kcore: Operation not permitted

16th November 2007, 03:24 PM
Your find found the problem:

/etc/sysconfig/prelink:PRELINK_OPTS=-m --no-exec-shield

So the PRELINK_OPTS line in /etc/sysconfig/prelink is the problem, from the prelink file:

# Options to pass to prelink
# -m Try to conserve virtual memory by allowing overlapping
# assigned virtual memory slots for libraries which
# never appear together in one binary
# -R Randomize virtual memory slot assignments for libraries.
# This makes it slightly harder for various buffer overflow
# attacks, since library addresses will be different on each
# host using -R.

--no-exec-shield is not an option there! FYI: my line reads:


16th November 2007, 03:55 PM
HaydnH, you nailed it. Removing the --no-exec-shield option from the /etc/sysconfig/prelink file solved the problem. Thanks for the quick spot.

And as a followup, I ran the search command string imo provided logged in as root instead of using sudo from my regular user account (sans the "sudo") in order to avoid the sudo/redirection/permissions problem and the run still halted before completion. There were no messages in the terminal from grep as before so I don't know exactly what it choked on but I suspect the same /proc/kcore thing.

Thanks to all....life is good again.


16th November 2007, 04:00 PM
np :D


16th November 2007, 04:02 PM

You can tell find to only look in only one file system (excluding /proc and others) with -xdev switch
sudo find / -xdev -type f -exec grep -H "no-exec-shield" {} \; | tee H_M_LOG

... I've been working on this find / grep command for over 10 years ... getting there

16th November 2007, 04:18 PM
Or you could just use a "grep -R" instead of a "find -exec"... as always there's more than one way to skin a cat in *nix... but anyway...

17th November 2007, 03:41 PM
Re: "grep -R", lmo tried that and still running after 3 hours ... top shows no cpu being used by grep.

"Beware cat with thick skin ..."