Open codezfire opened 6 months ago
Does the number of open files under /tmp need to be 0?? What's an acceptable amount or frequency?
The number is not the point here. The system engineer needs to have control about the location of the files. If we set environment variables for tmp files we also expect the program to follow it.
Having 4594 open files in the global temp, not able to put them in another location and which we can't see with ls command but only with zlsof is not acceptable.
Since the export of TMPDIR did not redirect all temp files to a new folder this may be fundamental limitation of the shell program. ZOS USS now supports the 'zsh' shell. Maybe it is better behaved.
I was able to reproduce seeing many /tmp operations, but the activity disappeared when setting TMPDIR to elsewhere.
I did TMPDIR=/u/myuser ./zwe init mvs -c /my/zowe.yaml
My default shell is Rocket's port of bash though.
I tried forcing /bin/sh
by just typing in /bin/sh
and retrying the operation.
But even then, setting TMPDIR
did result in no activity seen on zlsof
.
Tested on both z/OS 3.1 and 2.5
Perhaps a different command execution or execution context results in TMPDIR being ignored?
In our situation we're starting traditionally with the start command to the proclib. Support told me to set 3 variables both in proclib and zowe.yaml proc.txt
Proclib see above, in the zowe.yaml I have: `
environments:
TMPDIR: /u/IBM/zowe/tmp_shell_files
TEMP_DIR: /u/IBM/zowe/tmp_shell_files
CATALINA_TMPDIR: /u/IBM/zowe/tmp_shell_files
`
I've included the output of the zlsof command showing the open files in the global LPAR tmp (/tmp). zlsof_out.txt
I don't know if you're working in a sysplex, but I have to logon to the lpar to give the command on the specific system to investigate, going shared file system does not give the expected results, still have to check if that is documented by IBM
Do we have the same components enabled?
We are using the default z/OS shell /bin/sh delivered with our base MVS installation
If the standard shell program is directing /tmp file creation to different places on @couckearthur system than @1000TurquoisePogs system, then there are probably additional environmental factors that are in play. And aside from TMPDIR, I don't know what those could be w/o research.
Do not want to open a new defect, but I my case I have small /tmp so I used zowe.environments.TMPFOLDER to set to custom location. It worked on start
, but when I've decided to stop it -it does not:
# bin/zwe stop -c zowe.yaml
/SYSTEM/etc/zowe2/bin/libs/sys.sh 150: .: /SYSTEM/etc/zowe2/bin/libs/index.sh 44: .: bin/zwe 31: FSUMF316 Cannot open temporary file
/tmp/shaffhBgdeA: EDC5133I No space left on device. (errno2=0xE300000F)
#
As far as we can tell the TMPFOLDER is not being used for all files and this bug remains unsolved. Does anyone know any utility like 'lsof' on Linux to help find which programs are opening which temp files?
@JoeNemo Does anyone know any utility like 'lsof' on Linux to help find which programs are opening which temp files?
Do you mean the z/OS USS equivalent of lsof? it is zlsof you can see the userid and/or processes holding the files
If there are any programs or ZOS facilities that are not respecting the temp file config, can anyone out there who sees this behavior add in some "zlsof" info here?
Describe the bug Zowe performs extensive use of USS/shell script and zowe components hold the system's temporary directory during the run. This impedes customers from installing Zowe on production systems. Using a different temporary folder by exporting TMPDIR= does not resolve the problem, as half of the files remain in the /tmp directory despite this diversion.
To Reproduce Steps to reproduce the behavior: During zowe run execute command : zlsof -u zwesvusr
Expected behavior Following a successful Zowe start, the temporary directory should not be utilized.