arquivos criados e excluídos a cada segundo no diretório tmp

Por engano, notei que no diretório / tmp são criados continuamente alguns arquivos e imediatamente excluídos. Usando uma sucessão de ls -l /tmpeu consegui pegar os arquivos criados:

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

ou outro exemplo:

-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

É sobre o Ubuntu 18.10 com o 4.18.0-16-generic. Esta é uma instalação quase recente: eu adicionei algum software de servidor (nginx, mysql, php7.2-fpm), mas mesmo com aqueles fechados o problema persiste.

Quais são os arquivos criados e por quê? Como eu pararia esse comportamento? muito indesejável em um SSD

Obrigado!

ATUALIZAR

A questão é sobre quando não há / tmp na RAM (sem tmpfs ).
O software culpado é x2goserver.service, caso contrário, é necessário ter um.

Sugiro instalar e executar o fnotifystat para detectar o processo que está criando esses arquivos:

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

Você verá o processo que está executando a atividade de abrir / fechar / ler / gravar algo como o seguinte:

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)

Determinar qual programa / processo está tocando nos arquivos

Você pode usar ferramentas como lsofpara determinar quais processos e binários estão tocando / abrindo quais arquivos. Isso pode se tornar problemático se os arquivos forem alterados com frequência, para que você possa configurar um relógio para notificá-lo:

$ sudo fnotifystat -i /tmp

Às vezes, simplesmente olhar para o usuário ou o proprietário do grupo fornece uma boa dica (por exemplo:) ls -lsha.

Coloque /tmpna RAM em vez do disco

Se desejar, você pode colocar seu /tmpdiretório na RAM. Você precisará determinar se essa é uma jogada inteligente com base na RAM disponível, bem como no tamanho e na frequência de leitura / gravação.

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

Se você tiver RAM suficiente, isso pode ser considerado uma coisa muito boa a ser feita tanto pela longevidade do seu SSD quanto pela velocidade do seu sistema. Você pode até fazer isso com quantidades menores de RAM se ajustar tmpreaper(às vezes tmpwatch) para ser mais agressivo.

muito indesejável em um SSD

Você marcou sua pergunta com tmpfs ; portanto, não está claro para mim como isso se relaciona com o SSD. O tmpfs é um sistema de arquivos na memória (ou mais precisamente, no cache do bloco), portanto nunca atingirá um disco físico.

Além disso, mesmo que você tenha um armazenamento físico de backup para o seu /tmpsistema de arquivos, a menos que você tenha um sistema com apenas alguns kilobytes de RAM, esses arquivos de vida curta nunca atingirão o disco, todas as operações ocorrerão no cache.

Portanto, em outras palavras, não há com o que se preocupar, pois você está usando o tmpfs e, se não estivesse, ainda não haveria o que se preocupar.

As pessoas se preocupam demais com a resistência de gravação do SSD. Supondo que a criação e a exclusão de um arquivo vazio gravem 24 kB por segundo, e usando a especificação de 150 TBW para o popular Samsung 860 EVO 250 GB, o desgaste leva 193 anos!

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

Para sistemas de arquivos ext4, use "tune2fs -l" para encontrar gravações ao longo da vida. Ou use "smartctl -a" e procure Total_LBAs_Written. Eu sempre acho que o SSD tem muita vida restante.

Você estava usando o /dev/nvme0...nome errado :

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

O formato correto é:

$ 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

Até a vida útil do SSD NVMe :

$ 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

A linha principal aqui é:

percentage_used                     : 0%

Após 18 meses de uso, o percentual de SSD é de 0%. Se após 3 anos de uso atingir 1%, sei que o SSD durará 300 anos.

Obviamente, essa resposta não caberia na seção de comentários para responder a outros comentários.