bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: exit status issue


From: Bob Proulx
Subject: Re: exit status issue
Date: Tue, 22 Nov 2011 16:49:09 -0700
User-agent: Mutt/1.5.21 (2010-09-15)

Dallas Clement wrote:
> > This doesn't (yet) look like a problem with bash.
> 
> Admittedly bash seems to do the right thing if you go by the set -x
> execution trace.  If you go by that, it would indeed seem that the
> call to touch is failing.

I have a higher level of trust in -x output since I haven't found any
problems with it.  But I have found a lot of programs that do not
handle file errors correctly.  Those are way too common.  Therefore I
am much more suspicous of them.  For example:

  $ perl -le 'print "hello";' >/dev/full
  $ echo $?
  0

Perl ate that error and never said anything about it.  One of a very
many programs with this problem.  BTW...  Bash gets it right.

  $ echo "hello" >/dev/full
  bash: echo: write error: No space left on device
  $ echo $?
  1

> But the strace output tells a different story.  According to it, the
> system calls that touch makes are succeeding.

Your test case is still too complex to be passed on to others.

> In fact, I created my own 'touch' and 'stat' programs, both of which
> log any errors.

That's excellent!

> I never see any errors logged, so I'm pretty sure they are getting
> executed which jives with what I'm seeing in the strace output.

Since it is your own code you would want to see that they logged the
successful result of the operation and also logged that they were
calling exit(0) and at that time show that bash logged them as a
non-zero exit.

For that test you could use 'false' to simulate the unsuccessful program.

> Is this a lower level scheduling problem?  It certainly could be.  I'm
> testing on Linux 2.6.39.4.   I'll rollback to an older kernel, libc,
> and libpthread and see if that makes any difference.

Scheduling?  Now you are scaring me.  I think you are going off into
the weeds with that idea.  I can't imagine how this can be anything
other than simple inline flow of control through your script.  Your
script as you have shown to us does not have any background
asynchronous processing.  Therefore it will be executing all of the
commands in order.  There isn't any out-of-order execution magically
happening.

I see by this that you are grasping at straws.  You are "just trying
things".  I have empathy for you and your troubles.  But that isn't
the scientific method.

  http://en.wikipedia.org/wiki/Scientific_method#Elements_of_scientific_method

> Not doing anything with NFS mounting thankfully.  It's a RAID array on
> a NAS device which is typically used for SMB / CIFS network mount.

Your system is mounting it using an SMB mount?  Then perhaps your
network protocol layer is causing trouble.  I think a bug in the SMB
layer is much more likely.

Bob



reply via email to

[Prev in Thread] Current Thread [Next in Thread]