Re: deleting IFS files

Hello Jack,

some comments and expansions for the interested reader…


Am 26.10.2023 um 01:59 schrieb Jack Woehr via MIDRANGE-L <midrange-l@xxxxxxxxxxxxxxxxxx>:

If your system actually uses open source for business processes, be aware that many open source programs write pid files and stuff like that in /tmp.

Programs which write their PID files in /tmp have been badly ported. They do not adhere to the FHS 3.0 which is in place since 2015. And common sense. :-)

https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

PID files have to go to /var/run (or /run, for FHS 3).

Not sure if IBM i PASE is meant to adhere to FHS, though.

So you do need to do some cleanup. But you should learn to recognize things that may be artifacts of active processes.

For a well designed chain of applications handling data, /tmp has be considered volatile, not unlike QTEMP (which is even more restrictive because it hasn't a global scope like /tmp).

Also, if an IFS file is deleted (unlinked), while some process has that file opened, the process won't fail, because only the *link* to a file name is deleted. There is no implicit file locking. As long as the file is kept open, the allocated space linked by said name is not freed and the program using that file can continue without issue. This is consistent on OS/400 V4R5, Linux, and current macOS, and probably many more historic and current UNIX implementations. And this is very different to Windows where file locks are implicit.

Thus, cleaning /tmp completely (if desired at all) might be a good idea at these points in time:

- After going to restricted mode for Save 21 (no processes are using files in /tmp),
- through QSTRUPPGM prior or after STRCLNUP is called to automate this at IPL time, making PASE /tmp more consistent with other UNIX systems: Empty after IPL.

Just my $.02.

:wq! PoC