archivos creados y luego eliminados cada segundo en el directorio tmp

Por error, noté que en el directorio / tmp se crean continuamente algunos archivos y luego se eliminan de inmediato. Usando una sucesión de ls -l /tmpLogré atrapar los archivos creados:

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

u otro ejemplo:

-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

Se trata de Ubuntu 18.10 con 4.18.0-16-genérico. Esta es una instalación casi nueva: agregué un software de servidor (nginx, mysql, php7.2-fpm) pero incluso con aquellos cerrados, el problema persiste.

¿Qué son los archivos creados y por qué? ¿Cómo detendría este comportamiento? uno muy indeseable en un SSD

¡Gracias!

ACTUALIZAR

La pregunta es acerca de cuándo no tener / tmp en RAM (no tmpfs ).
El software culpable es x2goserver.service, de lo contrario, debe tener uno.

Sugiero instalar y ejecutar fnotifystat para detectar el proceso que está creando estos archivos:

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

Verá el proceso que está realizando la actividad de abrir / cerrar / leer / escribir algo como lo siguiente:

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 qué programa / proceso está tocando archivos

Puede usar herramientas como lsofpara determinar qué procesos y binarios están tocando / abriendo qué archivos. Esto podría ser problemático si los archivos cambian con frecuencia, por lo que puede configurar un reloj para que le notifique:

$ sudo fnotifystat -i /tmp

A veces, simplemente mirar al usuario o al propietario del grupo le da una buena pista (es decir:) ls -lsha.

Poner /tmpen RAM en lugar de disco

Si lo desea, puede poner su /tmpdirectorio en la RAM. Tendrá que determinar si este es un movimiento inteligente basado en la RAM disponible, así como el tamaño y la frecuencia de las lecturas / escrituras.

$ 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)

Si tiene suficiente RAM, esto puede considerarse algo muy bueno tanto para la longevidad de su SSD como para la velocidad de su sistema. Incluso puede lograr esto con cantidades más pequeñas de RAM si modifica tmpreaper(a veces tmpwatch) para ser más agresivo.

uno muy indeseable en un SSD

Etiquetó su pregunta con tmpfs , por lo que no me queda claro cómo se relaciona esto con SSD. Tmpfs es un sistema de archivos en memoria (o más precisamente, en bloque de caché), por lo que nunca golpeará un disco físico.

Además, incluso si tuviera un almacén de respaldo físico para su /tmpsistema de archivos, a menos que tenga un sistema con solo un par de kilobytes de RAM, esos archivos de corta duración nunca llegarán al disco, todas las operaciones sucederán en la memoria caché.

En otras palabras, no hay nada de qué preocuparse, ya que está utilizando tmpfs, y si no lo fuera, aún no habría nada de qué preocuparse.

La gente se preocupa demasiado por la resistencia de escritura SSD. Suponiendo que al crear y eliminar un archivo vacío se escriben 24 kB por segundo, y al usar las especificaciones de 150 TBW para el popular Samsung 860 EVO 250 GB, ¡el desgaste lleva 193 años!

(150 * 10 ^ 12) / ((2 * 3 * 4 * 1024) * 60 * 60 * 24 * 365.25) = 193

Para los sistemas de archivos ext4, use "tune2fs -l" para buscar escrituras de por vida. O use "smartctl -a" y busque Total_LBAs_Written. Siempre encuentro que al SSD le queda mucha vida.

Estabas usando el /dev/nvme0...nombre incorrecto :

$ sudo tune2fs -l /dev/nvme0n1
tune2fs 1.42.13 (17-May-2015)
tune2fs: Bad magic number in super-block while trying to open /dev/nvme0n1
Couldn't find valid filesystem superblock.

El formato correcto es:

$ sudo tune2fs -l /dev/nvme0n1p6
tune2fs 1.42.13 (17-May-2015)
Filesystem volume name:   New_Ubuntu_16.04
Last mounted on:          /
Filesystem UUID:          b40b3925-70ef-447f-923e-1b05467c00e7
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              2953920
Block count:              11829504
Reserved block count:     534012
Free blocks:              6883701
Free inodes:              2277641
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      1021
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8160
Inode blocks per group:   510
Flex block group size:    16
Filesystem created:       Thu Aug  2 20:14:59 2018
Last mount time:          Thu Apr  4 21:05:29 2019
Last write time:          Thu Feb 14 21:36:27 2019
Mount count:              377
Maximum mount count:      -1
Last checked:             Thu Aug  2 20:14:59 2018
Check interval:           0 (<none>)
Lifetime writes:          4920 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
First orphan inode:       1308352
Default directory hash:   half_md4
Directory Hash Seed:      a179d56c-6c68-468c-8070-ffa5bb7cd973
Journal backup:           inode blocks

En cuanto a la vida útil de NVMe SSD :

$ sudo nvme smart-log /dev/nvme0
Smart Log for NVME device:nvme0 namespace-id:ffffffff
critical_warning                    : 0
temperature                         : 38 C
available_spare                     : 100%
available_spare_threshold           : 10%
percentage_used                     : 0%
data_units_read                     : 22,351,778
data_units_written                  : 14,667,833
host_read_commands                  : 379,349,109
host_write_commands                 : 127,359,479
controller_busy_time                : 952
power_cycles                        : 1,925
power_on_hours                      : 1,016
unsafe_shutdowns                    : 113
media_errors                        : 0
num_err_log_entries                 : 598
Warning Temperature Time            : 0
Critical Composite Temperature Time : 0
Temperature Sensor 1                : 38 C
Temperature Sensor 2                : 49 C
Temperature Sensor 3                : 0 C
Temperature Sensor 4                : 0 C
Temperature Sensor 5                : 0 C
Temperature Sensor 6                : 0 C
Temperature Sensor 7                : 0 C
Temperature Sensor 8                : 0 C

La línea clave aquí es:

percentage_used                     : 0%

Después de 18 meses de uso, el porcentaje de uso de SSD es del 0%. Si después de 3 años de uso alcanza el 1%, entonces sé que el SSD durará 300 años.

Obviamente, esta respuesta no encajaría en la sección de comentarios para responder a otros comentarios.