Forum Linux.général Fichier supprimé mais qui consomme toujours de l'espace disque

Posté par  . Licence CC By‑SA.
1
20
août
2019

Bonjour,

Il y'a quelques semaines , j'ai supprimé un fichier run.log généré par une application , normalement le fichier doit être régénéré parce que l'application tourne toujours , mais ce n'est pas le cas , et l'espace disque se consomme de plus en plus comme si le fichier a été déplacé quelque part ou bien il tourne toujours en arrière plan , je ne sais pas quoi , j'ai remonté ça à l'équipe Linux là où je travaille et l'un d'entre eux a trouvé comment vider le fichier même si il n'apparrait pas avec une commande , mais il n'a pas voulu me donner cette commande , et je dois a chaque fois lui faire la demande pour me faire la manipulation et vider de l'espace , quelqu'un connaît comment résoudre ce problème ?

Merci d'avance

  • # machine de travail?

    Posté par  . Évalué à -1.

    Bonjour,

    Si tu parles d'une machine de travail, il est normal que le technicien ne veuille pas te communiquer la commande :
    - ne maîtrisant pas tous les avenants et les aboutissants, tu risques de faire des dégâts.

    Cependant, tu peux faire une demande pour que ton poste soit boosté …

    Bon courage

    tant va la cruche à l'eau qu'à la fin elle t'explose en pleine tête

  • # Normal

    Posté par  . Évalué à 7.

    Tant qu’un logiciel tourne et maintient un fichier ouvert, il n’est pas supprimé du disque, même s’il est effacé de son répertoire.

    C’est exprès, ça évite de planter des logiciels.

    Arrêter le logiciel suffira pour que le fichier soit finalement réellement supprimé. Et quand on le relancera, il créera un nouveau fichier.

    Je ne vois pas de moyen propre de vider le fichier tant que le logiciel tourne et pas de moyen sale évident non plus (s’il en existe, je serais curieux de le connaître).

    logrotate, qui sert à éviter l’accumulation des logs système, soit compte sur la coopération des logiciels en leur envoyant un signal pour qu’il créent un nouveau fichier (mais ça ne marche qu’avec un logiciel prévu pour), soit les arrête et les relance.

    Il faudrait plutôt essayer de paramétrer le logiciel pour écrire moins de choses dans le log, le mettre ailleurs ou ne pas en créer du tout.

    S’il n’est pas paramétrable, j’essaierais avant de le lancer de faire un lien nommé run.log (à l’endroit où il s’attend à le trouver) vers /dev/null, des fois qu’il suive le lien sans broncher (pas sûr ; il faut déjà qu’il ne crée pas systématiquement un nouveau fichier à chaque lancement).

    « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

    • [^] # Re: Normal

      Posté par  . Évalué à 2.

      $ > le_fichier

      permettra de vider le_fichier, si tu as les droits suffisants.

      • [^] # Re: Normal

        Posté par  . Évalué à 1.

        Bonjour , je vais essayer de redémarrer le processus , comme ça le fichier sera régénéré et je saurais si je le vide ou je fais quoi par la suite

        • [^] # Re: Normal

          Posté par  . Évalué à 4.

          Effectivement, si tu as déjà effacé le fichier (du répertoire), le truc de bat ne peut pas fonctionner, parce que le fichier original n’est plus accessible que par ton logiciel. Il faut donc que tu l’arrêtes au moins une fois.

          « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

      • [^] # Re: Normal

        Posté par  . Évalué à 5.

        permettra de vider le_fichier, si tu as les droits suffisants.

        Ça va créer un fichier vide ayant le même nom.
        Ça ne fera rien pour le fichier non visible mais toujours existant.

    • [^] # Re: Normal

      Posté par  . Évalué à 7.

      logrotate, qui sert à éviter l’accumulation des logs système, soit compte sur la coopération des logiciels en leur envoyant un signal pour qu’il créent un nouveau fichier (mais ça ne marche qu’avec un logiciel prévu pour), soit les arrête et les relance.

      Logrotate peut aussi copier puis vider le fichier, pour faire une rotation, avec l'option copytruncate :

      Truncate the original log file to zero size in place after creating a copy, instead of moving the old log file and optionally creating a new one. It can be used when some program cannot be told to close its logfile and thus might continue writing (appending) to the previous log file forever. Note that there is a very small time slice between copying the file and truncating it, so some logging data might be lost. When this option is used, the create option will have no effect, as the old log file stays in place.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.