tmp 디렉토리에서 1 초마다 작성되고 삭제 된 파일

실수로 / tmp 디렉토리에 일부 파일이 지속적으로 생성 된 다음 즉시 삭제되는 것을 알았습니다. 연속해서 사용 ls -l /tmp하여 생성 된 파일을 잡았습니다.

-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

4.18.0-16의 일반적인 Ubuntu 18.10에 관한 것입니다. 이것은 거의 새로 설치되었습니다. 서버 소프트웨어 (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디스크 대신 RAM에 넣 습니다

원하는 경우 /tmp디렉토리를 RAM에 넣을 수 있습니다 . 사용 가능한 RAM과 읽기 / 쓰기의 크기 및 빈도에 따라 스마트 이동인지 확인해야합니다.

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

RAM이 충분하면 SSD의 수명과 시스템 속도 모두에 매우 좋은 방법으로 간주 할 수 있습니다. 더 공격적이되도록 tmpreaper(때로는 tmpwatch) 조정하면 더 적은 양의 RAM으로이 작업을 수행 할 수도 있습니다.

SSD에서 매우 바람직하지 않은 것

귀하의 질문에 tmpfs 태그를 지정 했으므로 이것이 SSD와 어떤 관련이 있는지는 분명하지 않습니다. Tmpfs는 메모리 내 (또는보다 정확하게는 블록 내 캐시) 파일 시스템이므로 실제 디스크에 절대 도달하지 않습니다.

또한 /tmp파일 시스템에 대한 실제 백업 저장소가 있더라도 몇 킬로바이트의 RAM이있는 시스템이없는 한, 수명이 짧은 파일은 디스크에 닿지 않으며 모든 작업은 캐시에서 수행됩니다.

다시 말해서, tmpfs를 사용하고 있기 때문에 걱정할 것이 없습니다. 그렇지 않은 경우에는 걱정할 것이 없습니다.

사람들은 SSD 쓰기 내구성에 대해 너무 걱정합니다. 빈 파일을 생성 및 삭제하면 초당 24kB가 기록되고 인기있는 Samsung 860 EVO 250GB에 대해 150TBW 사양을 사용한다고 가정하면 마모는 193 년이 걸립니다!

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

ext4 파일 시스템의 경우 "tune2fs -l"을 사용하여 수명 쓰기를 찾으십시오. 또는 "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 년 동안 지속될 것이라는 것을 알고 있습니다.

분명히이 답변은 다른 의견에 답하기 위해 의견 섹션에 적합하지 않습니다.