Bug 181646 - executables shared over NFS crash with SIGBUS when new executables are released.
executables shared over NFS crash with SIGBUS when new executables are released.
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: nfs-utils (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Steve Dickson
Ben Levenson
Depends On:
  Show dependency treegraph
Reported: 2006-02-15 13:17 EST by Sev Binello
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-21 14:30:59 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Sev Binello 2006-02-15 13:17:55 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050921 Red Hat/1.7.12-

Description of problem:
We have had a consistent problem of executables shared over NFS crashing with a SIGBUS when new executables are released.

   Before a new executable replaces an older one with a cp,
   we mv the executable to a fallback dir and rename it.
   We have 2 renaming schemes,
   either .old, .older, .oldest or  append a date to the old executable.
     This used to work fine when the nfs sever was solaris,
   however since we migrated it to redhat linux WS,
   we find that the executables crash with a SIGBUS.
     The executables don't necessarily crash right away,
   as a matter of fact we can't intentionally reproduce the crash.
   Which leads me to believe it is cache related.

   Has anyone experienced a similar problem,
    and come up with a solution ?

Version-Release number of selected component (if applicable):

How reproducible:
Couldn't Reproduce

Steps to Reproduce:

Additional info:

I cant intentionally reproduce it,
but it does happen often.
Usually users will leave applications up and idle over an extended period
and when they go back to reuse it, the application will crash
with a SIGBUS. The problem is not restricted to any one application.

We are running Red Hat Enterprise Linux WS release 3 (Taroon Update 6)
Comment 1 Sev Binello 2006-02-21 14:30:59 EST
This was not a bug. 
Here's some mail from Trond Mykelbust explaining the problem ...

    It isn't. It is a consequence of using the (admittedly _very_ stupid)
     default server setting of "subtree_check", and then renaming into a
     different directory (man 5 exports).

    You have one of 2 possible solutions:

    1) Edit your /etc/exports, and add no_subtree_check options to the
       entries for your exported filesystem.
    2) rename the executables into the same directory.


Note You need to log in before you can comment on or make changes to this bug.