Forum Linux.général Fichier supprimé mais l'espace disque n'est pas liberé

Posté par  (site web personnel) .
Étiquettes : aucune
0
8
déc.
2010
Bonjour,
J'ai une question a propos d'un probleme sur mon serveur linux.

J'avais un fichier log ( kern.log ) qui faisait 600 giga, et je sais pas pourquoi j'ai voulu 'nano kern.log' forcement ca mettait 3 plombe a ouvrir.

Bien sur c'est un serveur distant et j'accede en SSH, voyant ma betise de nano un fichier de 600 giga, j'ai fermé le shell SSH.

Ensuite, j'ai réouvert un autre shell, et j'ai supprimé le fichier log et de suite recrée un nouveau avec touch.

Le probleme c'est qu'il a pas liberé l'espace disque.. je pense que c'est du au faite que nano meme en ayant fermé le shell avait 'bloqué' le fichier.

Enfin bref, je perd 600 giga sur la partition:
/dev/sda2 914G 630G 238G 73% /home

du -ch /home/ | grep total
34G total

  • # C'est un classique

    Posté par  . Évalué à 4.

    Tu as supprimé un fichier qui est encore utilisé par un autre processus. Tant que le processus en question n'aura pas libéré le fichier, l'espace sera toujours pris.

    Ce n'est peut-être pas nano qui pose problème mais le process qui utilise ce fichier log.

    Pour info, si tu veux vider un fichier de logs utilisé par un autre processs, après avoir sauvegardé ce qui t'intéresse il vaut mieux faire :
    > fichier_log.log

    • [^] # Re: C'est un classique

      Posté par  (site web personnel) . Évalué à 1.

      Effectivement c'est pas le nano qui bloque mon log j'ai trouvé le coupable:

      lsof | grep "kern.log"
      syslog-ng 3131 root 11w REG 8,2 638705874152 52314156 /home/log/kern.log (deleted)


      Je me dis que je vais relancer syslog-ng mais il veut pas ..

      /etc/init.d/syslog-ng stop
      * Stopping Asterisk ...
      kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec]
      * Failed to stop Asterisk [ !! ]
      * ERROR: problems stopping dependent services.
      * "syslog-ng" is still up.

      Forcement asterisk tourne pas en service ...

      Si je reboot je casse un uptime de 380 jours ...
      J'ai regardé dans /etc/syslog-ng mais je trouve pas de relation avec asterisk.

      Merci de votre aide.

      • [^] # Re: C'est un classique

        Posté par  (site web personnel) . Évalué à 2.

        Si je reboot je casse un uptime de 380 jours ...

        OSF de l'uptime, franchement, c'est pas un accident.

        Ce qui est certain, c'est que tu n'as pas besoin de rebooter pour régler ton soucis.

        Essaye de régler le problème lié à Asterisk qui tourne pas en tant que service, puis ensuite tu pourras relancer syslog-ng (un restart, ça suffit pas?)

        Bye
        G

        Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

        • [^] # Re: C'est un classique

          Posté par  . Évalué à 4.

          Les uptime c'est comme les grosses voitures ??

          Vous voulez pas la jouer soft ? Je suis pas contraignant... vous voulez la jouer hard ? On va la jouer hard

      • [^] # Re: C'est un classique

        Posté par  (site web personnel) . Évalué à 1.

        Resolu ;)

        Merci !

        Je vais pouvoir garder mon uptime !
        uptime

        10:54:23 up 372 days, 58 min, 2 users, load average: 8.74, 3.07, 1.81

        • [^] # Re: C'est un classique

          Posté par  . Évalué à 1.

          Je ne comprends pas cette manie d'avoir le plus gros uptime, certes c'est un signe de stabilité, mais il ne faut pas non plus oublier qu'en un an il y a pas mal de mises à jour de sécurités pour le kernel, donc là vous avez des kernels remplies de trou... (sauf si vous utilisez des gentoo hardened)

          • [^] # Re: C'est un classique

            Posté par  . Évalué à 2.

            j'ai pas verifié, mais il me semble qu'avec kexec/kdump on peut recharger un nouveau kernel sans redemarrer la machine

            mais je ne sais pas si ca impacte l'uptime

            • [^] # Re: C'est un classique

              Posté par  (site web personnel) . Évalué à 3.

              AFAIK, kexec va remettre l'uptime à 0. Avec ksplice par contre...

              pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

          • [^] # Re: C'est un classique

            Posté par  (site web personnel) . Évalué à 3.

            C'est une gentoo hardened avec grsec

        • [^] # Re: C'est un classique

          Posté par  . Évalué à 3.

          Les chiffres à droite aussi peuvent avoir un intérêt ! :-)

          • [^] # Re: C'est un classique

            Posté par  (site web personnel) . Évalué à 2.

            Et justement, plus important que l'uptime, il y a le taux de disponibilité et l'efficacité du service rendu. Parce que bon, un uptime remontant à plusieurs années c'est bien, mais si la machine est inutilisable 50% du temps parce qu'elle a une charge trop élevée, bof bof...

  • # 600Go

    Posté par  . Évalué à 1.

    Ya qu'à moi que ça fait bizarre un log de 600Go ? Je comprends bien le flux de données généré par certains services mais là, ça a piqué ma curiosité.

  • # > /var/log/kern.log

    Posté par  (site web personnel) . Évalué à 0.

    La prochaine fois, soit tu copies le fichier vers un autre système, soit tu revois le paramétrage de logrotate pour qu'il agisse y compris lorsque le fichier de journalisation dépasse une certaine taille.
    Sinon, pour effacer proprement un tel fichier sans redémarrer ni relancer syslog :
    # > /var/log/kern.log
    Ainsi, le fichier aura été vidé de son contenu sans remettre en cause son utilisation par d'autres processus.

  • # vim

    Posté par  . Évalué à 3.

    La prochaine fois, plutôt que nano, utilise vim, il mmap le fichier au lieu de le charger entièrement en ram, ça mettra pas 3 plombes à l'ouvrir tout en faisant ramer la machine...

Suivre le flux des commentaires

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