file creati quindi eliminati ad ogni secondo nella directory tmp

Per errore ho notato che nella directory / tmp vengono continuamente creati alcuni file che vengono immediatamente eliminati. Utilizzando una successione di ls -l /tmpsono riuscito a catturare i file creati:

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

o un altro esempio:

-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

Si tratta di Ubuntu 18.10 con 4.18.0-16-generico. Questa è un'installazione quasi nuova: ho aggiunto alcuni software server (nginx, mysql, php7.2-fpm) ma anche con quelli chiusi il problema persiste.

Quali sono i file creati e perché? Come smetterei questo comportamento? molto indesiderabile su un SSD

Grazie!

AGGIORNARE

La domanda è quando non si ha / tmp nella RAM (no tmpfs ).
Il software colpevole è x2goserver.service, altrimenti è necessario averne uno.

Suggerisco di installare ed eseguire fnotifystat per rilevare il processo che sta creando questi file:

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

Vedrai il processo che sta svolgendo l'attività apri / chiudi / leggi / scrivi qualcosa come il seguente:

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)

Determina quale programma / processo tocca i file

È possibile utilizzare strumenti come lsofper determinare quali processi e binari toccano / aprono quali file. Questo potrebbe diventare problematico se i file cambiano frequentemente, quindi puoi invece impostare un orologio per avvisarti:

$ sudo fnotifystat -i /tmp

A volte, semplicemente guardando l'utente o il proprietario del gruppo ti dà un buon suggerimento (cioè:) ls -lsha.

Inserito /tmpnella RAM anziché nel disco

Se lo desideri, puoi inserire la tua /tmpdirectory nella RAM. Dovrai determinare se si tratta di una mossa intelligente basata sulla RAM disponibile, nonché sulle dimensioni e sulla frequenza di lettura / scrittura.

$ 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 hai abbastanza RAM, questo può essere considerato un'ottima cosa sia per la longevità del tuo SSD, sia per la velocità del tuo sistema. Puoi persino farlo con quantità minori di RAM se modifichi tmpreaper(a volte tmpwatch) per essere più aggressivo.

molto indesiderabile su un SSD

Hai taggato la tua domanda con tmpfs , quindi non mi è del tutto chiaro come questo si riferisca a SSD. Tmpfs è un filesystem in memoria (o più precisamente, in-block-cache), quindi non colpirà mai un disco fisico.

Inoltre, anche se avevi un archivio di backup fisico per il tuo /tmpfilesystem, a meno che tu non abbia un sistema con solo un paio di kilobyte di RAM, quei file di breve durata non colpiranno mai il disco, tutte le operazioni avverranno nella cache.

Quindi, in altre parole, non c'è nulla di cui preoccuparsi poiché stai usando tmpfs, e se non lo fossi, non ci sarebbe ancora nulla di cui preoccuparti.

Le persone si preoccupano troppo della resistenza di scrittura SSD. Supponendo che la creazione e l'eliminazione di un file vuoto comporti 24 kB al secondo e l'utilizzo delle specifiche da 150 TBW per il popolare Samsung 860 EVO da 250 GB, l'usura richiede 193 anni!

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

Per i filesystem ext4, usa "tune2fs -l" per trovare le scritture Lifetime. In alternativa, usa "smartctl -a" e cerca Total_LBAs_Written. Trovo sempre che all'SSD rimanga molta vita.

Stavi usando il /dev/nvme0...nome sbagliato :

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

Il formato giusto è:

$ 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

Per quanto riguarda la durata di vita di SSM 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

La linea chiave qui è:

percentage_used                     : 0%

Dopo 18 mesi di utilizzo la percentuale di utilizzo SSD è dello 0%. Se dopo 3 anni di utilizzo raggiunge l'1%, so che l'SSD durerà 300 anni.

Ovviamente questa risposta non si adatterebbe alla sezione commenti per rispondere ad altri commenti.