Otdfbt

By mistake I noticed that in /tmp directory are continuously created some files then immediately deleted. Using a succession of ls -l /tmp I managed to catch the created files:

-rw------- 1 root root 0 Apr 2 19:37 YlOmPA069G
-rw------- 1 root root 0 Apr 2 19:37 l74jZzbcs6

or another example:

-rw------- 1 root root 0 Apr 2 19:44 AwVhWakvQ_
-rw------- 1 root root 0 Apr 2 19:44 RpRGl__cIM
-rw------- 1 root root 0 Apr 2 19:44 S0e72nkpBl
-rw------- 1 root root 0 Apr 2 19:44 emxIQQMSy2

It's about Ubuntu 18.10 with 4.18.0-16-generic. This is an almost fresh install: I added some server software (nginx, mysql, php7.2-fpm) but even with those closed the problem persists.

What are the files created and why?
How would I stop this behaviour? a very undesirable one on a SSD

Thank you!

UPDATE

The question is about when not having /tmp in RAM (no tmpfs).

The guilty software is x2goserver.service otherwise a must have one.

I suggest installing and running fnotifystat to detect the process that is creating these files:

sudo apt-get install fnotifystat
sudo fnotifystat -i /tmp

You will see process that is doing the open/close/read/write activity something like the following:

Total Open Close Read Write PID Process Pathname
 3.0 1.0 1.0 0.0 1.0 5748 firefox /tmp/cubeb-shm-5748-input (deleted)
 2.0 0.0 1.0 0.0 1.0 18135 firefox /tmp/cubeb-shm-5748-output (deleted)
 1.0 1.0 0.0 0.0 0.0 5748 firefox /tmp/cubeb-shm-5748-output (deleted)

Determine which program/process is touching files

You can use tools such as lsof to determine which processes and binaries are touching/opening which files. This could become troublesome if the files change frequently, so you can instead set up a watch to notify you:

$ sudo fnotifystat -i /tmp

Sometimes, simply looking at the user or group owner gives you a good hint (ie: ls -lsha).

Put /tmp into RAM instead of disk

If you desire, you can put your /tmp directory into RAM. You will have to determine if this is a smart move based on available RAM, as well as the size and frequency of read/writes.

$ sudo vim /etc/fstab

...
# tmpfs in RAM
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
...

$ sudo mount /tmp
$ mount | grep tmp # Check /tmp is in RAM
tmpfs on /tmp type tmpfs (rw,noatime)

If you have enough RAM, this can be considered a very good thing to do for both the longevity of your SSD, as well as the speed of your system. You can even accomplish this with smaller amounts of RAM if you tweak tmpreaper (sometimes tmpwatch) to be more aggressive.

very undesirable one on a SSD

You tagged your question with tmpfs, so it is not quite clear to me how this relates to SSD at all. Tmpfs is an in-memory (or more precisely, in-block-cache) filesystem, so it will never hit a physical disk.

Furthermore, even if you had a physical backing store for your /tmp filesystem, unless you have a system with only a couple of kilobytes of RAM, those short-lived files will never hit the disk, all operations will happen in the cache.

So, in other words, there is nothing to worry about since you are using tmpfs, and if you weren't, there still would be nothing to worry about.