Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 162953 - Bash script looping
Summary: Bash script looping
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: bash
Version: 3
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-07-11 20:13 UTC by Vinicius Mommensohn
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-07-25 11:23:04 UTC


Attachments (Terms of Use)

Description Vinicius Mommensohn 2005-07-11 20:13:27 UTC
My system: kernel 2.6.11.12, bash-3.0-18

Problem:
----------------------------------------

I'm with a problem with a bash script. The same script works on RedHat 8, but 
it produces an weird error in FC3.

The script call's another instance of itself as a son process and, when the 
script tries to copy the file to another directory but the file already had 
been copied, it produces and error of non existing file and, if the script is 
in backgroud, it crashes!!!

The script:

#!/bin/bash

DIR=/usr/local/NoSPAM

while [ 0 = 0 ]; do
   for i in `ls -1 $DIR/queues_tmp/`; do
       NUM=`ps faxww | grep "$i" | grep -v "grep" | wc -l | sed -e "s/ //g"`;
       if [[ NUM = "0" ]]; then
          rm -f $DIR/queues_tmp/$i;
       fi
   done;

   for i in `ls -1 $DIR/queues/`; do
      NUM=`ls -1 $DIR/queues_tmp | wc -l | sed -e "s/ //g"`;
      if [[ $NUM > "9" ]]; then
         break;
      fi;

      if [[ ! -f $DIR/queues_tmp/$i ]]; then
         cp $DIR/queues/$i $DIR/queues_tmp/$i;
         rm -f $DIR/queues/$i;
      fi
   done;

   for i in `ls -1 $DIR/queues_tmp/`; do
       if [[ ! -f $DIR/queues/$i ]]; then
          NUM2=`ps faxww | grep "$i" | grep -v "grep" | wc -l | sed -
e "s/ //g"`;
          if [[ $NUM2 = "0" ]]; then
             $DIR/nospam_sender $i &
          fi;
       fi
   done;

   usleep 20000;
done;



The process that it creates:

15831 pts/0    S      0:04          | \_ -bash
30316 pts/0    S+     0:14          |    \_ /bin/bash ./nospam_doqueue
22199 pts/0    R+     0:00          |       \_ /bin/bash ./nospam_doqueue


Please, i need this working... What could it be?


To reproduce:
--------------------------------------

1. Copy the script to a file with any name in /usr/local/NoSPAM
2. Creates the 
directories: /usr/local/NoSPAM/queues_tmp; /usr/local/NoSPAM/queues;
3. Start the script in background: ./nospam_doqueue &
4. In another shell, do some ps fax to see it creates a son calling itself!

What to expect:
-------------------

A son process starts and died, producing an error in some cases because it 
tries to copy a file from one directory to another, but the parent process 
already had copied that file and deleted it! So, the copy of file in the son 
process produces an error!


How it should work:
-------------------

It shouldn't start a son process of itself...

Comment 1 Tim Waugh 2005-07-25 11:23:04 UTC
This is not an appropriate forum for debugging your script.  If you can point to
a bug in bash, please do.  To me this looks more like a bug in your script.

When a process forks, it will adopt the parent's process name -- this is what
you are seeing.  There are plenty of forks in your program, and so it could be
any one of these.  Your script will of course loop forever, since that is what
you haev told it to do.

Comment 2 Vinicius Mommensohn 2005-07-25 12:11:01 UTC
This is not the problem and i'm not debugging my script. The problem is in a 
Red Hat 8 the new process do not occurs!!!! I know it is looping forever, this 
is what it has to do, but, what i dont know is how a script call itself (it is 
calling itself because he tries to copy a file that parent process already had 
called and the file was removed). And for me, what occurs in one system but not 
in others is a bug!


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