file yang dibuat kemudian dihapus pada setiap detik di direktori tmp

Secara tidak sengaja saya perhatikan bahwa dalam direktori / tmp secara terus menerus dibuat beberapa file kemudian segera dihapus. Menggunakan suksesi ls -l /tmpsaya berhasil menangkap file yang dibuat:

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

atau contoh lain:

-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

Ini tentang Ubuntu 18.10 dengan 4.18.0-16-generik. Ini adalah instalasi yang hampir segar: Saya menambahkan beberapa perangkat lunak server (nginx, mysql, php7.2-fpm) tetapi bahkan dengan mereka yang ditutup masalah tetap ada.

Apa file yang dibuat dan mengapa? Bagaimana saya menghentikan perilaku ini? yang sangat tidak diinginkan pada SSD

Terima kasih!

MEMPERBARUI

Pertanyaannya adalah kapan tidak memiliki / tmp dalam RAM (tidak ada tmpfs ).
Perangkat lunak yang bersalah adalah x2goserver.service kalau tidak harus memilikinya .

Saya sarankan menginstal dan menjalankan fnotifystat untuk mendeteksi proses pembuatan file-file ini:

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

Anda akan melihat proses yang melakukan kegiatan buka / tutup / baca / tulis sesuatu seperti berikut ini:

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)

Tentukan program / proses mana yang menyentuh file

Anda dapat menggunakan alat seperti lsofuntuk menentukan proses dan binari mana yang menyentuh / membuka file mana. Ini bisa menjadi masalah jika file sering berubah, jadi Anda dapat mengatur jam tangan untuk memberi tahu Anda:

$ sudo fnotifystat -i /tmp

Terkadang, hanya dengan melihat pengguna atau pemilik grup memberi Anda petunjuk yang baik (yaitu:) ls -lsha.

Masukkan /tmpke dalam RAM, bukan disk

Jika diinginkan, Anda dapat memasukkan /tmpdirektori Anda ke dalam RAM. Anda harus menentukan apakah ini langkah cerdas berdasarkan RAM yang tersedia, serta ukuran dan frekuensi baca / tulis.

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

Jika Anda memiliki RAM yang cukup, ini dapat dianggap sebagai hal yang sangat baik untuk dilakukan baik untuk umur panjang SSD Anda, maupun kecepatan sistem Anda. Anda bahkan dapat melakukan ini dengan jumlah RAM yang lebih kecil jika Anda men-tweak tmpreaper(kadang-kadang tmpwatch) menjadi lebih agresif.

yang sangat tidak diinginkan pada SSD

Anda menandai pertanyaan Anda dengan tmpfs , jadi tidak cukup jelas bagi saya bagaimana ini terkait dengan SSD sama sekali. Tmpfs adalah sistem file dalam-memori (atau lebih tepatnya, dalam-blok-cache), sehingga tidak akan pernah mengenai disk fisik.

Terlebih lagi, bahkan jika Anda memiliki backing store fisik untuk /tmpsistem file Anda , kecuali jika Anda memiliki sistem dengan hanya beberapa kilobyte RAM, file-file yang berumur pendek tidak akan pernah mengenai disk, semua operasi akan terjadi dalam cache.

Jadi, dengan kata lain, tidak ada yang perlu dikhawatirkan karena Anda menggunakan tmpfs, dan jika tidak, masih tidak ada yang perlu dikhawatirkan.

Orang-orang terlalu khawatir tentang ketahanan penulisan SSD. Dengan asumsi bahwa membuat dan menghapus file kosong menulis 24 kB setiap detik, dan menggunakan spesifikasi 150 TBW untuk Samsung 860 EVO 250 GB yang populer, aus membutuhkan waktu 193 tahun!

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

Untuk sistem file ext4, gunakan "tune2fs -l" untuk menemukan menulis Seumur Hidup. Atau, gunakan "smartctl -a" dan cari Total_LBAs_Written. Saya selalu menemukan SSD memiliki banyak kehidupan yang tersisa.

Anda menggunakan /dev/nvme0...nama yang salah :

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

Format yang tepat adalah:

$ 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

Sejauh masa pakai 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

Kuncinya di sini adalah:

percentage_used                     : 0%

Setelah 18 bulan penggunaan, persentase penggunaan SSD adalah 0%. Jika setelah 3 tahun menggunakannya mencapai 1% maka saya tahu SSD akan bertahan 300 tahun.

Jelas jawaban ini tidak cocok dengan bagian komentar untuk membalas komentar lain.