-1

If I deleted /tmp folder completely, what will happen ?

will it make any side effects or it will be re-created by os ( if so at re-start or if something needs to be stored in /tmp ) ?

In docker will it make any difference ? or it will behave same as Linux or Unix ?

Jeyanthinath
  • 373
  • 1
  • 5
  • 14
  • Really related -- https://unix.stackexchange.com/q/149920/117549 -- but selinux may also come into play. – Jeff Schaller Dec 20 '17 at 20:58
  • @JeffSchaller My question was around docker, not on linux directly ( i was trying to understand how docker behaves in regards to linux ) . Its not a perfect duplicate I feel – Jeyanthinath May 02 '18 at 09:31

2 Answers2

2

This depends wildly on the version of unix, and what exact software is running on that unix. Kerberos for example may place ticket files under /tmp, so removing that directory may then cause all user logins to fail (hopefully root has a local password, or...). You could use sysdig or similar tracing software

$ sudo sysdig "fd.name contains /tmp"
...

and let that run for a while to learn what software uses /tmp in what way. (The "chaos monkey" approach would be to rm -rf /tmp and then see what fails and how, which may or may not be a good idea in production...) Meanwhile, let's see what sysdig collected.

5311 20:43:52.918062202 0 postgres (24503) > close fd=6(<u>/tmp/.s.PGSQL.5432)
202619 20:45:08.252631819 0 rpm (24540) < open fd=4(<f>/tmp) name=/tmp flags=1(O_RDONLY) mode=0
202620 20:45:08.252633087 0 rpm (24540) > read fd=4(<f>/tmp) size=8192
202621 20:45:08.252633848 0 rpm (24540) < read res=-21(EISDIR) data=
202622 20:45:08.252634580 0 rpm (24540) > close fd=4(<f>/tmp)
202623 20:45:08.252635375 0 rpm (24540) < close res=0
202627 20:45:08.252650259 0 rpm (24540) < open fd=4(<f>/var/tmp) name=/var/tmp flags=1(O_RDONLY) mode=0

Looks like I installed postgres at some point on this test virt (a database no longer working because /tmp is gone might be a problem?) and rpm is doing something strange with the tmp dirs, no idea why...

The OS generally does not recreate things it expects to exist; if this is a problem you could setup a configuration management policy to create /tmp and fix its permissions (Ansible would be bad at that, while configuration management with local agents like CFEngine better at noticing and correcting such errors on the fly) but the configuration management software would also need to run correctly if /tmp is missing, which may or may not be the case. (But there's only so much that can be fixed if someone or something is blowing away random operating system directories...)

thrig
  • 34,333
  • 3
  • 63
  • 84
0

Do a "ls -l /tmp". The odds are there are files in /tmp that you didn't create. This is because many services and programs expect /tmp to exist and are often configured to write their temporary files to /tmp. If you remove /tmp altogether you will likely break these processes, and they are not likely to recreate it for you. Don't remove it.

L.Ray
  • 469
  • 2
  • 11