Файли, створені потім, видаляються щосекунди в каталозі tmp

По помилці я помітив, що в каталозі / tmp постійно створюються деякі файли, а потім негайно видаляються. За допомогою послідовності ls -l /tmpI вдалося спіймати створені файли:

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

або інший приклад:

-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

Йдеться про Ubuntu 18.10 з загальним 4.18.0-16. Це майже свіжа установка: я додав серверне програмне забезпечення (nginx, mysql, php7.2-fpm), але навіть із закритими проблема не зникає.

Які файли створені і чому? Як би я припинив таку поведінку? дуже небажаний на SSD

Дякую!

ОНОВЛЕННЯ

Питання полягає в тому, коли в RAM немає / tmp (немає tmpfs ).
Програмне забезпечення винного - це x2goserver.service, інакше його необхідно мати .

Я пропоную встановити та запустити fnotifystat для виявлення процесу, який створює ці файли:

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

Ви побачите процес, який виконує діяльність "відкрити / закрити / прочитати / записати" приблизно так:

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)

Визначте, яка програма / процес торкається файлів

Ви можете використовувати такі інструменти, як lsofвизначити, які процеси та двійкові файли торкаються / відкривають, які файли. Це може стати проблемою, якщо файли часто змінюються, тож ви можете замість цього налаштувати годинник, щоб сповістити вас:

$ sudo fnotifystat -i /tmp

Іноді просто перегляд користувача або власника групи дає вам добру підказку (тобто:) ls -lsha.

Помістіть /tmpв оперативну пам’ять замість диска

При бажанні ви можете помістити свій /tmpкаталог в оперативну пам’ять. Вам доведеться визначити, чи це розумний хід на основі наявної оперативної пам’яті, а також розміру та частоти читання / запису.

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

Якщо у вас достатньо оперативної пам’яті, це можна вважати дуже хорошою справою як для довговічності вашого SSD, так і для швидкості роботи вашої системи. Ви можете навіть досягти цього за допомогою меншої кількості оперативної пам’яті, якщо ви налаштовуєте tmpreaper(іноді tmpwatch) на більш агресивний характер.

дуже небажаний на SSD

Ви позначили своє запитання tmpfs , тому мені не зовсім зрозуміло, як це взагалі стосується SSD. Tmpfs - це файлова система в пам'яті (а точніше - блокова кеш-пам'ять), тому ніколи не потраплятиме на фізичний диск.

Крім того, навіть якщо у вас була фізична резервна копія для вашої /tmpфайлової системи, якщо у вас система з лише кількома кілобайтами оперативної пам’яті, ці недовговічні файли ніколи не потраплять на диск, всі операції відбудуться в кеші.

Таким чином, інакше кажучи, нічого страшного, оскільки ви використовуєте tmpfs, а якби цього не було, все одно не було би про що турбуватися.

Люди занадто сильно переживають, як витривалість SSD пише. Якщо припустити, що створення та видалення порожнього файлу пише 24 кБ щосекунди та використання специфікації 150 TBW для популярного Samsung 860 EVO 250 Гб, зношеність займає 193 роки!

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

Для файлових систем ext4 використовуйте "tune2fs -l", щоб знайти записи Lifetime. Або використовуйте "smartctl -a" і шукайте Total_LBAs_Written. Я завжди вважаю, що на SSD залишилось багато життя.

Ви ввели неправильне /dev/nvme0...ім’я:

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

Правильний формат:

$ 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

Що стосується терміну експлуатації 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

Ключовий рядок тут:

percentage_used                     : 0%

Після 18 місяців використання відсоток використання SSD становить 0%. Якщо через 3 роки використання він досягне 1%, то я знаю, що SSD прослужить 300 років.

Очевидно, що ця відповідь не впишеться в розділ коментарів для відповіді на інші коментарі.