rm ne libère pas d'espace disque
J'ai rm 'édité un fichier journal de 2,5 Go - mais il ne semble pas avoir libéré d'espace.
J'ai fait:
rm /opt/Tomcat/logs/catalina.out
ensuite ceci:
df -hT
et df ont signalé mon /opt montage toujours à 100% utilisé.
Aucune suggestion?
Redémarrez Tomcat, si le fichier est en cours d'utilisation et que vous le supprimez, l'espace devient disponible lorsque ce processus se termine.
Comme d'autres l'ont suggéré, le fichier est probablement encore ouvert par d'autres processus. Pour savoir par lesquels, vous pouvez faire
lsof /opt/Tomcat/logs/catalina.out
qui vous répertorie les processus. Vous trouverez probablement Tomcat dans cette liste.
Ton problème:
Il est possible qu'un programme en cours d'exécution conserve le fichier.
Votre solution:
Selon les autres réponses ici, vous pouvez simplement arrêter Tomcat pour l'empêcher de conserver le fichier.
Si ce n'est pas une option, ou si vous voulez simplement plus de détails, consultez cette question: Recherchez et supprimez les fichiers volumineux qui sont ouverts mais qui ont été supprimés - il suggère des façons plus dures de le traiter qui peut être plus utile à votre situation.
Plus de détails:
Le système de fichiers linux/unix considère les fichiers "ouverts" comme un autre nom pour eux. rm supprime le "nom" du fichier tel qu'il apparaît dans l'arborescence des répertoires. Jusqu'à ce que les poignées soient fermées, les fichiers ont toujours plus de "noms" et le fichier existe donc toujours. Le système de fichiers ne récupère pas les fichiers tant qu'ils ne sont pas complètement sans nom.
Cela peut sembler un peu étrange, mais le faire de cette façon permet des choses utiles comme l'activation des liens symboliques. Les liens symboliques peuvent essentiellement être traités comme un autre nom pour le même fichier.
C'est pourquoi il est important d'appeler toujours vos langues équivalentes à close () sur un descripteur de fichier si vous en avez terminé. Cela informe le système d'exploitation que le fichier n'est plus utilisé. Bien que parfois cela ne puisse pas être aidé - ce qui est probablement le cas avec Tomcat. Reportez-vous à Bill Karwin's Answer pour savoir pourquoi.
Selon le système de fichiers, cela est généralement implémenté comme une sorte de compte de référence, donc il peut ne pas y avoir de vrais noms impliqués. Cela peut aussi devenir bizarre si des choses comme stdin et stderr sont redirigées vers un fichier ou un autre bytestream (le plus souvent fait avec des services).
Cette idée est étroitement liée au concept de ' inodes ', donc si vous êtes du type curieux, je vous recommande de vérifier cela en premier.
Discussion
Cela ne fonctionne plus si bien, mais vous pouviez auparavant mettre à jour l'intégralité du système d'exploitation, démarrer un nouveau démon http en utilisant les nouvelles bibliothèques, et enfin fermer l'ancienne quand plus aucun client n'est entretenu avec elle (libération les anciennes poignées). Les clients http ne manqueraient même pas un battement.
Fondamentalement, vous pouvez effacer complètement le noyau et toutes les bibliothèques "des programmes en cours d'exécution". Mais comme le "nom" existe toujours pour les anciennes copies, le fichier existe toujours en mémoire/disque pour ce programme particulier. Il s'agirait alors de redémarrer tous les services, etc. Bien qu'il s'agisse d'un scénario d'utilisation avancée, c'est la raison pour laquelle certains systèmes Unix ont des années de disponibilité.
Le redémarrage de Tomcat libère tout blocage de Tomcat sur le fichier. Cependant, pour éviter de redémarrer Tomcat (par exemple, s'il s'agit d'un environnement de production et que vous ne souhaitez pas interrompre les services inutilement), vous pouvez généralement simplement remplacer le fichier:
cp /dev/null /opt/Tomcat/logs/catalina.out
Ou encore plus court et plus direct:
> /opt/Tomcat/logs/catalina.out
J'utilise ces méthodes tout le temps pour effacer les fichiers journaux des processus serveur en cours d'exécution au cours du dépannage ou de l'effacement du disque. Cela laisse l'inode seul mais efface les données réelles du fichier, alors qu'essayer de supprimer le fichier ne fonctionne souvent pas ou confond tout au moins l'écrivain du journal du processus en cours.
Comme FerranB et Paul Tomblin l'ont noté sur ce fil, le fichier est en cours d'utilisation et l'espace disque ne sera pas libéré avant la fermeture du fichier.
Le problème est que vous ne pouvez pas signaler la fermeture du processus Catalina catalina.out, car le descripteur de fichier n'est pas sous le contrôle du processus Java. Il a été ouvert par la redirection d'E/S Shell dans catalina.sh lorsque vous avez démarré Tomcat. Ce n'est qu'en mettant fin au processus Catalina que ce descripteur de fichier peut être fermé.
Il existe deux solutions pour éviter cela à l'avenir:
Ne laissez pas la sortie des applications Tomcat entrer dans
catalina.out. Utilisez plutôt la propriétéswallowOutputet configurez les canaux de journal pour la sortie. Les journaux gérés par log4j peuvent être tournés sans redémarrer le processus Catalina.Modifiez catalina.sh pour diriger la sortie vers cronolog au lieu de simplement rediriger vers
catalina.out. De cette façon, cronolog fera tourner les journaux pour vous.
la meilleure solution est d'utiliser 'echo' (comme la suggestion de @ejoncas):
$ echo '' > huge_file.log
Cette opération est assez sûre et rapide (supprimez environ 1 G de données par seconde), surtout lorsque vous travaillez sur votre serveur de production.
Ne supprimez pas simplement ce fichier en utilisant 'rm' car vous devez d'abord arrêter le processus de l'écriture, sinon le disque ne sera pas libéré.
voir: http://siwei.me/blog/posts/how-to-deal-with-huge-log-file-in-production
Si quelque chose l'ouvre encore, le fichier ne disparaîtra pas. Vous devrez probablement signaler à catalina d'une manière ou d'une autre de fermer et de rouvrir ses fichiers journaux.
S'il existe un deuxième lien dur vers le fichier, il ne sera pas supprimé tant qu'il ne sera pas supprimé.
Entrez la commande pour vérifier quels fichiers supprimés ont occupé la mémoire
$ Sudo lsof | grep deleted
Il montrera le fichier supprimé qui contient encore de la mémoire.
Ensuite, tuez le processus avec pid ou nom
$ Sudo kill <pid>
$ df -h
vérifiez maintenant que vous aurez la même mémoire
Sinon tapez la commande ci-dessous pour voir quel fichier occupe la mémoire
# cd /
# du --threshold=(SIZE)
mentionner toute taille, il montrera quels fichiers occupent au-dessus de la taille de seuil et supprimer le fichier