fichiers créés puis supprimés à chaque seconde dans le répertoire tmp

13

Par erreur, j'ai remarqué que dans le répertoire / tmp sont créés en continu certains fichiers puis immédiatement supprimés. En utilisant une succession de ls -l /tmpj'ai réussi à attraper les fichiers créés:

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

ou un autre exemple:

-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

Il s'agit d'Ubuntu 18.10 avec 4.18.0-16-générique. Il s'agit d'une installation presque récente: j'ai ajouté des logiciels serveur (nginx, mysql, php7.2-fpm) mais même avec ceux fermés, le problème persiste.

Quels sont les fichiers créés et pourquoi? Comment pourrais-je arrêter ce comportement? un très indésirable sur un SSD

Je vous remercie!

MISE À JOUR

La question concerne le fait de ne pas avoir / tmp en RAM (pas de tmpfs ).
Le logiciel coupable est x2goserver.service, sinon il doit en avoir un.

adrhc
la source
2
"un élément très indésirable sur un SSD" expliquez cela s'il vous plaît? Vous n'avez pas / tmp comme tmpfs? pourquoi pas? pourquoi les fichiers en mémoire endommageraient-ils un ssd?
Rinzwind
2
/ tmp n'est pas nécessairement tmpfs, c'est donc une question valable
Colin Ian King
2
Oui, ce ne serait pas souhaitable sur un SSD, au moins si les métadonnées du répertoire étaient effectivement réécrites sur le disque au lieu de rester simplement en cache. C'est pourquoi /tmpest normalement sur tmpfs (un système de fichiers ramdisk qui utilise le pagecache comme magasin de sauvegarde); vous avez marqué votre question avec les tmpfs , donc vos commentaires sur les SSD semblent hors de propos.
Peter Cordes
1
super - c'est un must have
adrhc
2
@PeterCordes Je ne suis pas sûr que la déclaration " /tmpest normalement sur tmpfs" est valide pour un utilisateur Ubuntu normal - Il suffit d'utiliser l'installation par défaut d'Ubuntu, /tmpest sur le disque et l'OP devra créer les entrées fstab appropriées pour le mettre dans un tmpfs
Charles Green

Réponses:

17

Je suggère d'installer et d'exécuter fnotifystat pour détecter le processus qui crée ces fichiers:

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

Vous verrez un processus qui fait l'activité d'ouverture / fermeture / lecture / écriture quelque chose comme ceci:

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)
Colin Ian King
la source
3
Postscript: je suis l'auteur de cet outil: kernel.ubuntu.com/~cking/fnotifystat
Colin Ian King
1
Et vous êtes également le premier à avoir répondu à la question (bien que cela ne soit plus visible). C'est un bon outil d'ailleurs.
adrhc
+1 pour un utilitaire très pratique. En temps opportun aussi, car je peux l'utiliser pour surveiller mon prochain projet de création de /tmp/...fichiers pour IPC entre le démon et l'espace utilisateur au lieu de DBUS plus compliqué.
WinEunuuchs2Unix
8

Déterminer quel programme / processus touche des fichiers

Vous pouvez utiliser des outils tels que lsofpour déterminer quels processus et binaires touchent / ouvrent quels fichiers. Cela peut devenir gênant si les fichiers changent fréquemment, vous pouvez donc configurer une montre pour vous informer:

$ sudo fnotifystat -i /tmp

Parfois, le simple fait de regarder l'utilisateur ou le propriétaire du groupe vous donne un bon indice (par exemple:) ls -lsha.


Mettez /tmpdans la RAM au lieu du disque

Si vous le souhaitez, vous pouvez mettre votre /tmprépertoire en RAM. Vous devrez déterminer s'il s'agit d'un mouvement intelligent basé sur la RAM disponible, ainsi que sur la taille et la fréquence des lectures / écritures.

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

Si vous avez suffisamment de RAM, cela peut être considéré comme une très bonne chose à faire pour la longévité de votre SSD, ainsi que pour la vitesse de votre système. Vous pouvez même accomplir cela avec de plus petites quantités de RAM si vous ajustez tmpreaper(parfois tmpwatch) pour être plus agressif.

EarthmeLon
la source
6

très indésirable sur un SSD

Vous avez tagué votre question avec , donc je ne sais pas du tout comment cela se rapporte au SSD. Tmpfs est un système de fichiers en mémoire (ou plus précisément, en cache de bloc), il ne touchera donc jamais un disque physique.

De plus, même si vous aviez un magasin de sauvegarde physique pour votre /tmpsystème de fichiers, à moins que vous n'ayez un système avec seulement quelques kilo-octets de RAM, ces fichiers éphémères ne toucheront jamais le disque, toutes les opérations se produiront dans le cache.

Donc, en d'autres termes, il n'y a rien à craindre puisque vous utilisez tmpfs, et si ce n'était pas le cas, il n'y aurait toujours rien à craindre.

Jörg W Mittag
la source
Je garde le / tmp dans la RAM donc par erreur j'ai tagué aussi avec mon type de fs actuel (tmpfs). Je l'ai supprimé maintenant, mais je trouve que votre réponse est utile aussi, donc 1 de moi.
adrhc
@adrhc: Si vous êtes /tmpdans la RAM, cela n'a rien à voir avec votre SSD, donc ce n'est ni souhaitable ni indésirable mais en fait complètement indépendant.
Jörg W Mittag
Je suis d'accord mais la question porte sur le fait de ne pas avoir / tmp dans la RAM. Il se trouve que j'avais / tmp en RAM; encore, le problème m'a intrigué.
adrhc
0

Les gens s'inquiètent trop de l'endurance en écriture SSD. En supposant que la création et la suppression d'un fichier vide écrivent 24 ko chaque seconde, et en utilisant la spécification de 150 TBW pour le populaire Samsung 860 EVO 250 Go, l'usure prend 193 ans!

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

Pour les systèmes de fichiers ext4, utilisez "tune2fs -l" pour trouver les écritures à vie. Ou, utilisez "smartctl -a" et recherchez Total_LBAs_Written. Je trouve toujours que le SSD a encore beaucoup de vie.

Fraser Gunn
la source
La question est "Quels sont les fichiers créés et pourquoi? Comment arrêter ce comportement?", Comment votre "réponse" correspond-elle à la question?
bummi
Bien que ne répondant pas directement à la question, je trouve que ces informations sont également utiles mais pas très précises quant à la façon d'utiliser ces commandes. Par exemple avec tune2fs je reçois tune2fs: Bad magic number in super-block while trying to open /dev/nvme0n1 Found a gpt partition table in /dev/nvme0n1.
adrhc
0

Vous utilisiez un mauvais /dev/nvme0...nom:

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

Le bon format est:

$ 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

En ce qui concerne la durée de vie du 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

La ligne clé ici est:

percentage_used                     : 0%

Après 18 mois d'utilisation, le pourcentage d'utilisation du SSD est de 0%. Si après 3 ans d'utilisation, il atteint 1%, je sais que le SSD durera 300 ans.

Évidemment, cette réponse ne rentrerait pas dans la section des commentaires pour répondre à d'autres commentaires.

WinEunuuchs2Unix
la source
Quelle partie de la sortie tune2fs se rapporte à la durée de vie du SSD?
adrhc
@adrhc Je montrais la bonne façon d'appeler tune2fsen réponse à votre commentaire sur la réponse de Fraser Gunn montrant un message d'erreur.
WinEunuuchs2Unix