Puis-je supprimer des fichiers / var / tmp / mkinitramfs- *?


11

Je remarque que mon /var/tmpdossier a occupé 9,3 Go d'espace sur mon Ubuntu 16.04.2. En particulier, il y a un tas de mkinitramfs_*dossiers occupant la majeure partie de l'espace dans le dossier tmp. Je les ai examinés et ils semblent être les fichiers temporaires pour les noyaux Linux compilés récemment et dans le passé. Puis-je les supprimer en toute sécurité ou ils sont liés à d'autres fichiers importants?

J'ai essayé d'utiliser l' tmpreaperapplication pour automatiser le processus de nettoyage des fichiers temporaires lors des redémarrages. Mais je trouve que je ne peux mettre deux /tmp/et /var/tmp/dossiers ensemble dans les paramètres d'auto-propre et ne mettre en place un âge de fichier maximum pour supprimer les anciens fichiers. Cela peut rendre difficile la configuration TMPREAPER_TIMEcorrecte du paramètre d'âge maximal du fichier . Si je le définis trop court (par défaut, 7 jours), je pourrais supprimer ces fichiers de compilation du noyau récents dans des mkinitramfs_*dossiers qui pourraient être utiles. Si je le fixe trop longtemps, je risque de me retrouver avec beaucoup de fichiers /tmp. J'espère que vous pourrez me signaler quelques références sur le rôle de ces mkinitramfs_*dossiers et comment utiliser l' tmpreaperapplication ou d'autres outils pour supprimer automatiquement les anciens fichiers temporaires.

Merci!


J'ai entendu dire qu'il vaut mieux garder un âge plus long pour les fichiers /var/tmpque dans /tmp. lsofne montre aucun processus utilise ces fichiers. Mais il y a un tas d'avertissements dans le tmpreapermanuel de l' application lorsque j'ai essayé de le configurer pour supprimer automatiquement ces fichiers, c'est là que j'ai eu peur. Donc, vous pensez que la suppression de ces fichiers 7 jours après le dernier accès est sûre?
Xiaodong Qi

J'ai remarqué ce bug dans ma recherche. Premièrement, ces fichiers n'ont pas été générés en raison d'une panne d'installation du noyau. Deuxièmement, le bug a été dit en cours de correction. Existe-t-il un moyen de vérifier s'ils ne sont liés à aucun autre fichier?
Xiaodong Qi

J'ai converti mes commentaires précédents en une réponse correcte. Je vais les nettoyer maintenant.
Andrea Lazzarotto du

Réponses:


16

Généralement, vous pouvez supprimer n'importe quel fichier dans /tmpet /var/tmpsans casser le système. Le pire des cas est qu'il s'agit d'un fichier nécessaire à une application ouverte, mais cela ne semble pas être le cas.

En ce qui concerne les fichiers liés à mkinitramfs, je dirais qu'il est sûr de les tailler. Voir aussi ce bogue Debian: # 818345 - le fichier tmp est laissé sous / var / tmp si mkinitramfs échoue . Fondamentalement, ces fichiers doivent être purgés après la fin du processus qui les a créés, mais pour une raison quelconque, ils ne le sont pas.

Je ne sais pas si vous êtes spécifiquement concerné par ce bogue, mais le fait est que ces fichiers sont nécessaires mkinitramfspendant que le processus est en cours. Une fois le processus terminé, vous n'en avez plus besoin. En outre, comme d'habitude avec les fichiers temporaires, ils seront recréés dans les exécutions suivantes du même processus si nécessaire.

J'espère que vous pourrez me signaler quelques références sur le rôle de ces mkinitramfs_*dossiers et comment utiliser l' tmpreaperapplication ou d'autres outils pour supprimer automatiquement les anciens fichiers temporaires.

Je n'ai pas d'expérience avec tmpreaper, mais vous pouvez utiliser un travail cron pour supprimer ces fichiers périodiquement. Voir:

Supprimer automatiquement les fichiers de plus de 7 jours


Merci d'avoir écrit cette réponse. Après avoir compris les fichiers tmp, j'ai utilisé tmpreaper(voir mes notes pour plus de détails) pour nettoyer automatiquement ces fichiers de plus de 30 jours et m'a économisé 7 Go d'espace. C'est très utile!
Xiaodong Qi

Mettre à jour le lien de mes notes .
Xiaodong Qi
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.