-1

Reposting the question about deleting a file. We have a script that is used to transfer files between two SCO Unix systems. The script has been rock solid for years. Recently the firewall unit at one location failed and was replaced. We can open a VPN tunnel, FTP works and we can transfer files, but the script is getting stuck at the point where it deletes a file.
The script writes a local file to identify that an FTP transfer is in progress (called a "lockfile"). The file uses the PID in the file name so the script can identify it. Then after the FTP transfer the script deletes the file as a clear indicator that the transfer process is complete. The FTP transfer completes - files are transferred. A message is echoed on the screen to say that the FTP session is closed. But the script stalls at the point where it removes the lockfile.

Also, the script supports deleting "stale" lock files but it cannot do that any more either.

Not sure how the firewall on the target system would impact the local system, but that's the symptom.

We do not currently have a sys admin. I am programmer trying to fill in for now. I don't know anything about "stick bits" - is anything apparent here? Any clues about where to look are appreciated.

Here is the script:

# Usage: storeftpputall machine
set -x
MACHINE=$1          # name of remote machine
USERNAME='ftpstore' 
PASS='ftppassword'      
PUBDIR='/u/ftpstore'        # Transfer directory tree
INDIR='transfer/in'     # Remote system, where files go in
MYNOWPID=$$             # Proc ID of this process.

# Make sure no other storeftpputs are running to that store, 
# else you could get an attempted overwrite, or at least overload
# the modem line.  Use PID lock files. 

# Check for PID file locking ftp to remote store
if [ -f /usr/tmp/$MACHINE.put.* ]
then
    STORELOKPID1=''
    STORELOKPID1=`ls /usr/tmp/$MACHINE.put.* | sed -e "s|$MACHINE\.put\.||g"`
    for j in $STORELOKPID1
    do
    k=`basename $j`
    LIVEPID=`ps -ef | grep $k | grep -v 'grep'`
    if [ -n "$LIVEPID" ]
    then
        echo 'Storeftpput script already in progress. Please wait'
        sleep 2
    else
        echo "Removing stale lockfile $MACHINE.$k"
        rm "/usr/tmp/$MACHINE.put.$k"   # Remove stale lock file
        sleep 2
    fi
    done
fi

# Any stale locks should be gone. Wait for any live
# storeftpput scripts to finish and remove their own lockfiles, 
# then proceed. 
while [ -f /usr/tmp/$MACHINE.put.* ]
do
    echo 'Storeftpput script already in progress. Please wait.'
    echo "Retrying at 45 second intervals."
    sleep 45
done

# Assert own lockfile on line
touch /usr/tmp/$MACHINE\.put\.$MYNOWPID
chmod 664 /usr/tmp/$MACHINE\.put\.$MYNOWPID

# Check for outbound store files. If found, send them. 
cd $PUBDIR/out/$MACHINE
if [ -f *.tar.Z ]
    then

    NUMBER=`ls *.tar.Z|sed -e "s|\.tar\.Z||g"`      # Get tar file numbers
    for j in $NUMBER   # May be more than one
    do
    ftp -i -n -v $MACHINE <<-EndFTP 
        user $USERNAME $PASS
        cd $INDIR
        lcd $PUBDIR/out/$MACHINE
        binary
        hash
        put $j.tar.Z
        chmod 666 $j.tar.Z
        close
        EndFTP
    rm $j.tar.Z
    done
fi

# Remove storeftpput lockfile
rm /usr/tmp/$MACHINE\.put\.$MYNOWPID

echo "Done..."
sleep 1
  • 4
    Please don't post the same question multiple times. Edit the initial question if you want to add details. You should delete the other question otherwise this one will be closed as a duplicate. – don_crissti Mar 15 '16 at 22:32
  • 1
    yes, edit your original question and paste the script into that. Don't forget to use the {} icon in the stackexchange editor to format the script as code. – cas Mar 15 '16 at 23:22
  • 1
    Possible duplicate of Why would a user not be able to delete a file they created? – cas Mar 15 '16 at 23:23
  • Apologies for the re-post. I did try to add the script but could not find a way to respond with the full text - comments are limited characters. I see now that I can edit the original text, and will do so in the future. – Margaret Duddy Mar 15 '16 at 23:28
  • Can you manually run ls -l /usr/tmp/*.put.* and see if any files are not owned by the expected user? One possibility is that someone accidentally ran the script when logged in as the wrong user – Mark Plotnick Mar 16 '16 at 3:57
0

Why do you use PATH like: /usr/tmp/$MACHINE.put.$MYNOWPID,

shouldn't you use /usr/tmp/$MACHINE/.put/.$MYNOWPID

  • The "lock" file created is filename.put.pidvalue. I guess I'm missing why the "/" values would be appropriate. Wouldn't that make the file be just the pid number, placed in sub-directories? – Margaret Duddy Mar 16 '16 at 17:01
0

Nothing obvious... but

The actual message was not stated in the question, but from context, that sounds like the loop after this comment

# Any stale locks should be gone. Wait for any live

The script has a few possible problems:

  • its use of the test-operator. If the wildcards in these expressions match more than one item, the script is likely to break:
    if [ -f /usr/tmp/$MACHINE.put.* ]
    while [ -f /usr/tmp/$MACHINE.put.* ]
    if [ -f *.tar.Z ]
  • use (even quoted) of shell special characters in sed expressions, e.g.,
    NUMBER=`ls *.tar.Z|sed -e "s|\.tar\.Z||g"`      # Get tar file numbers

Depending on the host system, sed may not behave well (other scripts generally use commas or percent signs, to avoid obscure problems).

  • There may be more than one file, but the wild card value for these files is the PID for the process that created the file. I could be wrong but I believe that value is unique to each session. – Margaret Duddy Mar 16 '16 at 19:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.