[Starlingx-discuss] [temp files] Be careful when using /tmp directory

[Ning, Antai (Andy)]

Hi All,

This is a piece of information I hope can help trouble-shooting and avoid coding mistakes:

In stx system, there is a /tmp dir which is the system default temporary file location. System command mktemp and mkstemp() in python for example will create a temp file in there if temp dir is not explicitly set by either environment variable or in the function call. We see some programs in the system are doing that.

But the /tmp dir is considered as "temporary" files holder. CentOS has systemd-tmpfiles-clean.timer enabled, and it will wake systemd-tmpfiles-clean.service every day, to cleanup files in /tmp that are older than 10 days (configured in /etc/tmpfiles.d/tmp.conf). The consequence is that some programs start failing or generate errors as they assume their temp files are still there. This is the root cause for [1].

In [1], sysinv-conductor uses kubernetes python client to access k8s services. The kubernetes client caches credentials in /tmp files. If the code to access k8s services are not triggered for more than 10 days, the /tmp files are removed as part of the systemd tmpfiles cleanup. Then the client used by sysinv-conductor stops working, complaining its temp files are not found. This is a known issue with kubernetes python client as in [2].

So the conclusion are:

  *   don't assume files in /tmp will be "permanent", be careful when use it for long lasting processes.
  *   as kubernetes python client caches info in /tmp by default, either release the client after each use of it, or change its default temp dir by setting environment variable such as TMPDIR.

[1] https://bugs.launchpad.net/starlingx/+bug/1883599
[2] https://github.com/kubernetes-client/python/issues/765

Hope this help,
Andy



/tmp is cleaned up every 10 days and point to the LP and explain the issue we had in this particular case. This impacts any StarlingX component that (mistakenly) assumes that the /tmp dir is an OK place to anything but very short-lived files.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.starlingx.io/pipermail/starlingx-discuss/attachments/20200619/6a9875dc/attachment.html>