/tmp directory out of space

[david.lemasters]

Yesterday unknown to us a large file was placed in our /tmp directory using up all available space. Our cozsftp batch jobs began failing with what appeared to be authentication failures. Our passwords are kept as members of a pds. I assume that cozsftp copies the password to a unix file and then invokes ibm's sftp. sftp then tried to connect to a server and failed with authentication/permission denied errors. There was no indication from cozsftp that it was unable to create a unix file. Is there any way for cozsftp to issue a message when it cannot create a unix file? It would have saved us a lot of time in debugging this failure if we knew that at the beginning. A little later, but before we knew of the space problem, we were able to connect but the sftp commands were not being executed even though we were receiving return codes of zero. I think a little space freed up in the /tmp directory which allowed the password fie to be created, but not enough for the command file. Is there anyway to detect this type of error?

[dovetail]

We do not copy passwords to /tmp.

If /tmp filled up, then you should have gotten errors in your failing shell scripts. It is not so much that Co:Z SFTP uses /tmp, but that your shell scripts create little files there or your log files are directed there.

The $TMPDIR environment variable can be used to point to an alternate temp directory.

You should define the space thresholds for /tmp so that console messages are issued, and best to have automated ops processes use these messages to alert operations and/or initiate a job to clean up old files. The IBM supplied "skulker" program can be used to do this

[dovetail]

There is an IBM z/OS Unix APAR that is related to some conditions where /tmp space full does not result in an exit code.

http://www-01.ibm.com/support/docview.w ... sg1OA40087