shell script - cannot open

[Eric Buckner]

Hi everyone. Got a vague error in quite a few of my scripts that is really starting to bug me. I thought I had the resolution to it but am afraid that it has reared it's ugly head again. Anyway here is the error I get randomly.

<scriptname>[795634018]: /tmp/sh28697.1: cannot open

Now I had assumed this was because I had sticky bit set on /tmp and I wasn't cleaning /tmp have some scripts that are not cleaning up temp files they are creating. And another process eventually would get the same process id and attempt to create the file that was still there. Now keep in mind these are not 'my' temp files but ones that the shell is creating for what ever reason.

So I set a cron job to clean these up if they were over 3 days old.

Short of turning off the sticky bit, is there a way to fix this? Or is this a different error and I am heading down the wrong path?

TIA!
Eric

[Pete Randall]

Eric,

Curious mostly - why do you have the sticky bit set on /tmp?

Pete

[Eric Buckner]

Our developers write scripts that are wrappers to their PL/SQL. And as such they use /tmp quite a bit. The sticky bit was the only way I could guarantee that they wouldn't step on another process.

Eric

[James R. Ferguson]

Hi Eric:

Setting the sticky bit on the /tmp directory simply means that only the owner of a file has permission to remove it.

The best approach to managing (i.e. cleaning-up) temporary files created by a script is to create a directory for all of the temporarary files a script will create and declare a trap which unconditionally removes the directory and files at the script's completion:

#!/usr/bin/sh
TMPDIR=/var/tmp/${0##*/}.${$} #...or /tmp...
...
trap 'rm -rf $TMPDIR' EXIT
...
...

Regards!

...JRF...

[Pete Randall]

Eric,

I guess I would be more inclined to discourage the developers from using /tmp. Give them another playpen to trash that's not going to interfere with your work.

Just a thought,
Pete

[Eric Buckner]

James,
Yes that is exactly why I have the sticky bit turned on for /tmp. We had a rash of issues where developer written scripts were removing files owned by other users because they matched a pattern. And to force some sort of sanity, I had to turn it on.

Pete,
Unfortunately they aren't using /tmp of their own accord. I have an expansive space for temporary stuff that they are supposed to use by application. These are files that the shell is actually creating. I did find a small blurb concerning junk /tmp/sh* files that could possibly be part of the problem.



Below is that blurb. The shells in question are doing << redirection into SQLPLUS and assigning that output to a variable.

***
If << is used to provide standard input to an asynchronous process invoked by &, the shell gets mixed up about naming the input document; a garbage file /tmp/sh* is created and the shell complains about not being able to find that file by another name.
***

[Dietmar Konermann]

Eric,

that temporary files are created by the shell, when you use so-called "here-docs", e.g.:

cat >file << EOI
this
is
a
here-doc
EOI

There are known problems with Posix- and Korn-Shells removing their tmp file too quickly.

What OS revision are you using?

Regards...
Dietmar.

[Eric Buckner]

James,
Sorry I did want to follow up on that cleanup idea. I am thinking that it wouldn't be such a bad idea to have some sort of trap removal but not exactly sure how to do this with files that the shell is creating rather than the developer/user.

[Eric Buckner]

Dietmar,
We are running 11.11. Do you know of a patch or anything that can resolve this?

Eric

[Dietmar Konermann · Accepted solution]

Eric,

I believe that you are hitting:

JAGad98139 N 5 hpux.cmd.iso.shells POSIX sh(1) removes here-doc before RHS of pipe can read it

The 11.11 fix is planned to be included in the next Posix-Shell cumulative patch (PHCO_27017).
Maybe your local repsonse center is able to provide you a pre-release of that patch if you tell the CR number above.

Regards...
Dietmar.