Aller au contenu
Gecko64

Souci d'espace disque sur un RPS

Noter ce sujet :

Recommended Posts

Gecko64    0

Bonjour, je ne sais pas si c'est moi qui me trompe dans mon raisonnement ou alors si c'est le RPS que je gère chez OVH qui a un souci avec l'espace disque.

Dites moi si vous voyez quelque chose d'anormale dans ceci :

r25XXX:/# du -hs /
du: cannot access `/proc/32021/task/32021/fd/4': No such file or directory
du: cannot access `/proc/32021/task/32021/fdinfo/4': No such file or directory
du: cannot access `/proc/32021/fd/4': No such file or directory
du: cannot access `/proc/32021/fdinfo/4': No such file or directory
1.2G /
r25XXX:/# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 5.0G 4.7G 0 100% /
tmpfs 242M 0 242M 0% /lib/init/rw
udev 10M 2.7M 7.4M 27% /dev
tmpfs 242M 0 242M 0% /dev/shm
/dev/sda2 15G 422M 14G 3% /home


En fait, la question que je me pose c'est que df -h me dit que j'ai 4.7Gb d'utilisé sur / alors que du -hs me dit que ce répertoire contient 1.2Gb ce qui me semble plus plausible.
Je sais aussi que la machine a 951 jours d'uptime et que la liaison avec le SAN est tombée quelques fois depuis.
Allez savoir si quelque chose n'aurait pas planté à cause de ça...

Merci d'avance

Partager ce message


Lien à poster
Partager sur d’autres sites
Dan    133

L'espace utilisé par mysql pour les tables temporaires n'est pas comptabilisé par un "du".



Tu devrais changer le tempdir dans ta config de mysql et le mettre sur /home/

Partager ce message


Lien à poster
Partager sur d’autres sites
Gecko64    0

Ah ça je ne savais pas...
Je vais aller voir pour changer ça dans la configuration (tmpdir = /tmp)

Merci Dan! smile.gif

EDIT :

r25xxx:/tmp# ls -ilah
total 20K
480001 drwxrwxrwt 4 root root 4.0K 2013-04-03 11:50 .
2 drwxr-xr-x 21 root root 4.0K 2009-06-18 21:59 ..
480011 -rw-r--r-- 1 500 500 1.4K 2013-04-03 11:50 cpu_stats
480003 drwxrwxrwt 2 root root 4.0K 2010-08-25 22:51 .ICE-unix
480002 drwxrwxrwt 2 root root 4.0K 2010-08-25 22:51 .X11-unix
r25xxx:/tmp#


Je n'ai quasi rien dans le /tmp donc ça doit venir d'ailleurs je pense.
C'est quand même étrange qu'une commande qui calcule l'espace disque utilisé ne comptabilise pas tout.

Partager ce message


Lien à poster
Partager sur d’autres sites
jcaron    11

Surtout, du ne peut peut pas compter l'espace pris par des fichiers qui ont été effacés, mais qui sont encore ouverts. Par exemple, si tu as un fichier de logs, que tu le supprimes, mais que tu ne signales pas au processus qui écrit dedans de le fermer et d'en rouvrir un nouveau, le fichier continue à prendre de la place sur le disque, mais n'est pas visible dans l'arbo, et ne peut donc pas être pris en compte par du. Pire encore, le processus qui écrit dedans continue à le faire, donc le fichier continue à grossir!



Jacques.


Partager ce message


Lien à poster
Partager sur d’autres sites
Gecko64    0

J'ai effectivement effacé pas mal de ficiers log mais uniquement ceux qui étaient archivés en .gz
Pour les autres fichiers de log, ils utilisent très très peu de place.
Sinon tu m'en as quand même appris une sur le fait qu'on pouvait encore remplir un fichier effacé de l'arbo, merci :)

Partager ce message


Lien à poster
Partager sur d’autres sites
jcaron    11

Si tu as effacé un log archivé ça ne devrait pas poser de problème. Mais si tu as effacé des fichiers de logs encore actifs, ils continuent à prendre de la place, voire à grandir. Il suffit de signaler aux processus correspondants qu'il y a eu "log rotation" pour qu'ils ferment les fichiers et en rouvrent de nouveaux, et la place correspondante va être libérée. C'est souvent faisable via un kill -HUP sur le process, mais ça varie d'un programme à l'autre. Dans le pire des cas, un restart du process correspondant fait l'affaire.



A l'avenir, outre la méthode ci-dessus, une méthode efficace pour regagner de la place sur des logs en cours d'utilisation c'est de les tronquer (:>nomdufichier) plutôt que les supprimer.



Jacques.


Partager ce message


Lien à poster
Partager sur d’autres sites
Gecko64    0

Ok, merci :)
Je peux dire que j'irai dormir moins ignorant ce soir ;)
Sinon j'ai un peu peur de faire un restart sur cette machine car elle gère l'émission de flux radio et vu son uptime, ça me fait toujours peur de tenter de la relancer, surtout avec si peu d'espace disque.
J'ai même fait un apt-get clean mais là aussi, tout est vidé.

Partager ce message


Lien à poster
Partager sur d’autres sites
jcaron    11

Pas besoin de relancer la machine, juste les processus correspondants. Ce n'est pas Windows :-)



Pour trouver le processus fautif, tu peux essayer avec fstat. Il liste tous les fichiers qui sont ouverts par tous les processus, et il y a une colonne qui contient la date (au moins dans la version FreeBSD, je suppose que c'est pareil sur ta distribution). Par exemple chez moi:


fstat | sort -rn +7

Donne les plus gros fichiers ouverts. En recoupant avec ce qu'il y a effectivement sur disque, tu dois pouvoir trouver le processus qui a un fichier ouvert mais non visible. Il ne reste alors plus qu'à relancer ce processus (ou à lui signaler qu'il doit fermer/rouvrir le fichier correspondant).



Jacques.


Partager ce message


Lien à poster
Partager sur d’autres sites
Gecko64    0

Oui il va falloir que je regarde ça pcq la distrib est toujours en Lenny et le miroir OVH est mort depuis et faire une upgrade la dessus, je ne le sens pas car j'ai un peu peur qu'un truc se passe mal pour le chargement de l'OS par le réseau.
Ce n'est pas le genre de chose avec lequel j'ai l'habitude de jouer.
Du coup, je suis un peu ennuyé pour installer le package tclx qui contient fstat d'autant plus que le disque étant full, même avec un .deb, je n'ai pas la place pour l'installer et ayant déjà vidé tous les logs.
Je pense que je vais essayer de convaincre le gars à qui appartient le RPS qu'il serait mieux de passer sur un petit KIM où VPS pcq les RPS, c'est un peu dépassé comme produit chez OVH :-/

Merci beaucoup :)

Partager ce message


Lien à poster
Partager sur d’autres sites
jcaron    11

Ah ouaip fstat c'est BSD-esque, désolé. Il semblerait que côté Linux ce soit plutôt lsof (ou éventuelle pfile ou pfiles?).



Jacques.


Partager ce message


Lien à poster
Partager sur d’autres sites
Gecko64    0

Voilà, j'ai fait un lsof | grep deleted > lsof-result.txt et effectivement, j'en ai du fichier ouvert !

apache2 1262 www-data 2w REG 8,1 73343 224314 /var/log/apache2/error.log.1 (deleted)
apache2 1262 www-data 7w REG 8,1 29263735 224228 /var/log/apache2/access.log.1 (deleted)
sc_serv 1935 www-data 2w REG 8,1 166850638 224163 /var/log/apache2/error.log.1 (deleted)
sc_serv 1935 www-data 7w REG 8,1 269735285 224083 /var/log/apache2/access.log.1 (deleted)
sc_serv 1935 www-data 10u REG 8,1 233484288 240579 /var/www/logs/sc_1266701649_8060.log (deleted)
apache2 2730 www-data 2w REG 8,1 8270 224227 /var/log/apache2/error.log.1 (deleted)
apache2 2730 www-data 7w REG 8,1 1218879 224193 /var/log/apache2/access.log.1 (deleted)
apache2 2974 www-data 2w REG 8,1 8270 224227 /var/log/apache2/error.log.1 (deleted)
apache2 2974 www-data 7w REG 8,1 1218879 224193 /var/log/apache2/access.log.1 (deleted)
sc_serv 2975 www-data 2w REG 8,1 166850638 224163 /var/log/apache2/error.log.1 (deleted)
sc_serv 2975 www-data 7w REG 8,1 269735285 224083 /var/log/apache2/access.log.1 (deleted)
sc_serv 2975 www-data 10u REG 8,1 76632064 243135 /var/www/logs/sc_1269885479_8014.log (deleted)
apache2 2979 www-data 2w REG 8,1 8270 224227 /var/log/apache2/error.log.1 (deleted)
apache2 2979 www-data 7w REG 8,1 1218879 224193 /var/log/apache2/access.log.1 (deleted)
apache2 2980 www-data 2w REG 8,1 8270 224227 /var/log/apache2/error.log.1 (deleted)
apache2 2980 www-data 7w REG 8,1 1218879 224193 /var/log/apache2/access.log.1 (deleted)
mysqld 4534 mysql 4u REG 8,1 0 480004 /tmp/ibId0Uuq (deleted)
mysqld 4534 mysql 5u REG 8,1 0 480005 /tmp/ibAEmrwL (deleted)
mysqld 4534 mysql 6u REG 8,1 0 480006 /tmp/ibsZdYx6 (deleted)
mysqld 4534 mysql 7u REG 8,1 0 480007 /tmp/ib87FdOr (deleted)
mysqld 4534 mysql 11u REG 8,1 0 480008 /tmp/iboZpClP (deleted)
apache2 4584 www-data 2w REG 8,1 54020 224293 /var/log/apache2/error.log.1 (deleted)
apache2 4584 www-data 7w REG 8,1 28035014 224239 /var/log/apache2/access.log.1 (deleted)
apache2 5904 www-data 2w REG 8,1 73343 224314 /var/log/apache2/error.log.1 (deleted)
apache2 5904 www-data 7w REG 8,1 29263735 224228 /var/log/apache2/access.log.1 (deleted)
apache2 5976 www-data 2w REG 8,1 238124 224351 /var/log/apache2/error.log.1 (deleted)
apache2 5976 www-data 7w REG 8,1 70005642 224350 /var/log/apache2/access.log.1 (deleted)
sc_serv 6043 www-data 2w REG 8,1 563627 224127 /var/log/apache2/error.log.1 (deleted)
sc_serv 6043 www-data 7w REG 8,1 17963435 224004 /var/log/apache2/access.log.1 (deleted)
sc_serv 6913 www-data 2w REG 8,1 166801486 224169 /var/log/apache2/error.log.1 (deleted)
sc_serv 6913 www-data 7w REG 8,1 270590195 224153 /var/log/apache2/access.log.1 (deleted)
sc_serv 6913 www-data 10u REG 8,1 835584 240163 /var/www/logs/sc_1350907523_8046.log (deleted)
sc_serv 7892 www-data 2w REG 8,1 166801486 224169 /var/log/apache2/error.log.1 (deleted)
sc_serv 7892 www-data 7w REG 8,1 270590195 224153 /var/log/apache2/access.log.1 (deleted)
sc_serv 7892 www-data 10u REG 8,1 146149376 243145 /var/www/logs/sc_1269885917_8020.log (deleted)
sc_serv 8633 www-data 2w REG 8,1 166801486 224169 /var/log/apache2/error.log.1 (deleted)
sc_serv 8633 www-data 7w REG 8,1 270590195 224153 /var/log/apache2/access.log.1 (deleted)
sc_serv 8633 www-data 10u REG 8,1 5943296 240216 /var/www/logs/sc_1337386063_8022.log (deleted)
sc_serv 9322 www-data 2w REG 8,1 166850638 224163 /var/log/apache2/error.log.1 (deleted)
sc_serv 9322 www-data 7w REG 8,1 269735285 224083 /var/log/apache2/access.log.1 (deleted)
sc_serv 9322 www-data 10u REG 8,1 276107264 243150 /var/www/logs/sc_1269886354_8016.log (deleted)
apache2 11295 www-data 2w REG 8,1 47285 224276 /var/log/apache2/error.log.1 (deleted)
apache2 11295 www-data 7w REG 8,1 26083079 224274 /var/log/apache2/access.log.1 (deleted)
apache2 13766 www-data 2w REG 8,1 238124 224351 /var/log/apache2/error.log.1 (deleted)
apache2 13766 www-data 7w REG 8,1 70005642 224350 /var/log/apache2/access.log.1 (deleted)
apache2 13769 www-data 2w REG 8,1 4174 224287 /var/log/apache2/error.log.1 (deleted)
apache2 13769 www-data 7w REG 8,1 1218879 224193 /var/log/apache2/access.log.1 (deleted)
sc_serv 14050 www-data 2w REG 8,1 166850638 224163 /var/log/apache2/error.log.1 (deleted)
sc_serv 14050 www-data 7w REG 8,1 269735285 224083 /var/log/apache2/access.log.1 (deleted)
sc_serv 14050 www-data 10u REG 8,1 48164864 240207 /var/www/logs/sc_1336829347_8032.log (deleted)
apache2 14376 www-data 2w REG 8,1 54020 224293 /var/log/apache2/error.log.1 (deleted)
apache2 14376 www-data 7w REG 8,1 28035014 224239 /var/log/apache2/access.log.1 (deleted)
sc_serv 14542 www-data 2w REG 8,1 166850638 224163 /var/log/apache2/error.log.1 (deleted)
sc_serv 14542 www-data 7w REG 8,1 269735285 224083 /var/log/apache2/access.log.1 (deleted)
sc_serv 14542 www-data 10u REG 8,1 292433920 240601 /var/www/logs/sc_1269463685_8004.log (deleted)
apache2 14659 www-data 2w REG 8,1 54020 224293 /var/log/apache2/error.log.1 (deleted)
apache2 14659 www-data 7w REG 8,1 28035014 224239 /var/log/apache2/access.log.1 (deleted)
apache2 14661 www-data 2w REG 8,1 54020 224293 /var/log/apache2/error.log.1 (deleted)
apache2 14661 www-data 7w REG 8,1 28035014 224239 /var/log/apache2/access.log.1 (deleted)
apache2 14662 www-data 2w REG 8,1 54020 224293 /var/log/apache2/error.log.1 (deleted)
apache2 14662 www-data 7w REG 8,1 28035014 224239 /var/log/apache2/access.log.1 (deleted)
apache2 14964 www-data 2w REG 8,1 54020 224293 /var/log/apache2/error.log.1 (deleted)
apache2 14964 www-data 7w REG 8,1 28035014 224239 /var/log/apache2/access.log.1 (deleted)
apache2 15401 www-data 2w REG 8,1 4174 224287 /var/log/apache2/error.log.1 (deleted)
apache2 15401 www-data 7w REG 8,1 1218879 224193 /var/log/apache2/access.log.1 (deleted)
apache2 16019 www-data 2w REG 8,1 238124 224351 /var/log/apache2/error.log.1 (deleted)
apache2 16019 www-data 7w REG 8,1 70005642 224350 /var/log/apache2/access.log.1 (deleted)
sc_serv 17306 www-data 2w REG 8,1 166850638 224163 /var/log/apache2/error.log.1 (deleted)
sc_serv 17306 www-data 7w REG 8,1 269735285 224083 /var/log/apache2/access.log.1 (deleted)
sc_serv 17306 www-data 10u REG 8,1 45060096 240239 /var/www/logs/sc_1268535076_8002.log (deleted)
sc_serv 21580 www-data 2w REG 8,1 166850638 224163 /var/log/apache2/error.log.1 (deleted)
sc_serv 21580 www-data 7w REG 8,1 269735285 224083 /var/log/apache2/access.log.1 (deleted)
sc_serv 21580 www-data 10u REG 8,1 4165632 240178 /var/www/logs/sc_1350553704_8046.log (deleted)
apache2 22671 www-data 2w REG 8,1 129105 224270 /var/log/apache2/error.log.1 (deleted)
apache2 22671 www-data 7w REG 8,1 2184147 224236 /var/log/apache2/access.log.1 (deleted)
apache2 23039 www-data 2w REG 8,1 54020 224293 /var/log/apache2/error.log.1 (deleted)
apache2 23039 www-data 7w REG 8,1 28035014 224239 /var/log/apache2/access.log.1 (deleted)
apache2 23122 www-data 2w REG 8,1 54020 224293 /var/log/apache2/error.log.1 (deleted)
apache2 23122 www-data 7w REG 8,1 28035014 224239 /var/log/apache2/access.log.1 (deleted)
sc_serv 23183 www-data 2w REG 8,1 166850638 224163 /var/log/apache2/error.log.1 (deleted)
sc_serv 23183 www-data 7w REG 8,1 269735285 224083 /var/log/apache2/access.log.1 (deleted)
sc_serv 23183 www-data 10u REG 8,1 640450560 243142 /var/www/logs/sc_1269885641_8010.log (deleted)
sc_serv 24214 www-data 2w REG 8,1 166850638 224163 /var/log/apache2/error.log.1 (deleted)
sc_serv 24214 www-data 7w REG 8,1 269735285 224083 /var/log/apache2/access.log.1 (deleted)
sc_serv 24214 www-data 10u REG 8,1 1900544 243083 /var/www/logs/sc_1266627856_8056.log (deleted)
sc_serv 25920 www-data 2w REG 8,1 166850638 224163 /var/log/apache2/error.log.1 (deleted)
sc_serv 25920 www-data 7w REG 8,1 269735285 224083 /var/log/apache2/access.log.1 (deleted)
sc_serv 25920 www-data 10u REG 8,1 36802560 242975 /var/www/logs/sc_1266545199_8050.log (deleted)
sc_serv 26477 www-data 2w REG 8,1 166850638 224163 /var/log/apache2/error.log.1 (deleted)
sc_serv 26477 www-data 7w REG 8,1 269735285 224083 /var/log/apache2/access.log.1 (deleted)
sc_serv 26477 www-data 10u REG 8,1 107479040 240596 /var/www/logs/sc_1269723368_8006.log (deleted)
apache2 27770 www-data 2w REG 8,1 4174 224287 /var/log/apache2/error.log.1 (deleted)
apache2 27770 www-data 7w REG 8,1 1218879 224193 /var/log/apache2/access.log.1 (deleted)
sc_serv 28952 www-data 2w REG 8,1 166850638 224163 /var/log/apache2/error.log.1 (deleted)
sc_serv 28952 www-data 7w REG 8,1 269735285 224083 /var/log/apache2/access.log.1 (deleted)
sc_serv 28952 www-data 10u REG 8,1 389120 243084 /var/www/logs/sc_1266628158_8058.log (deleted)
apache2 30017 www-data 2w REG 8,1 4174 224287 /var/log/apache2/error.log.1 (deleted)
apache2 30017 www-data 7w REG 8,1 1218879 224193 /var/log/apache2/access.log.1 (deleted)
sc_serv 30201 www-data 2w REG 8,1 166850638 224163 /var/log/apache2/error.log.1 (deleted)
sc_serv 30201 www-data 7w REG 8,1 269735285 224083 /var/log/apache2/access.log.1 (deleted)
sc_serv 30201 www-data 10u REG 8,1 1124671488 243153 /var/www/logs/sc_1269886634_8000.log (deleted)
apache2 30368 www-data 2w REG 8,1 4174 224287 /var/log/apache2/error.log.1 (deleted)
apache2 30368 www-data 7w REG 8,1 1218879 224193 /var/log/apache2/access.log.1 (deleted)
sc_serv 30771 www-data 2w REG 8,1 166850638 224163 /var/log/apache2/error.log.1 (deleted)
sc_serv 30771 www-data 7w REG 8,1 269735285 224083 /var/log/apache2/access.log.1 (deleted)
sc_serv 30771 www-data 10u REG 8,1 98127872 242357 /var/www/logs/sc_1269885136_8012.log (deleted)
sc_serv 30776 www-data 2w REG 8,1 166850638 224163 /var/log/apache2/error.log.1 (deleted)
sc_serv 30776 www-data 7w REG 8,1 269735285 224083 /var/log/apache2/access.log.1 (deleted)
sc_serv 30776 www-data 10u REG 8,1 16670720 240182 /var/www/logs/sc_1336828529_8030.log (deleted)


Pour ceux que j'ai vérifiés, ils ne sont plus sur le disque dur ou alors affichent une taille 0 et sont tous liés au processus du serveur Web qui fait tourner Castcontrol.
Faudrait donc faire un kill -HUP sur chaque process d'apache2 pour éviter le reboot du service web ?
Je ne vois pas en fait le -HUP dans le MAN de la commande kill :-/

Partager ce message


Lien à poster
Partager sur d’autres sites
Dan    133

Tu peux lancer un "apachectl graceful" qui permettrait un redémarrage en douceur d'Apache, sans fermer brutalement aucun processus.

Partager ce message


Lien à poster
Partager sur d’autres sites
Gecko64    0

Le souci c'est que si apache redémarre, les process ./sc_serv vont aussi se couper car ils découlent du serveur apache2.
Ou alors, il faut que le gars qui gère castcontrol soit là pour tout relancer ce qui ferait une micro coupure de quelques secondes, ce qui n'est pas encore la mort...
Quand tu dis "sans fermer brutalement", le process va se relancer quand même ?

Partager ce message


Lien à poster
Partager sur d’autres sites
Dan    133

Il va se relancer, mais sans couper l'affichage des pages en cours. Donc il se relance une fois tout ce qui doit être envoyé l'a été !



Tu ne peux pas relancer les process sc_serv toi même ?


Partager ce message


Lien à poster
Partager sur d’autres sites
Gecko64    0

Ok, ben j'en aurai appris des choses moi aujourd'hui ! :)
Moi je faisais toujours ça à la barbare genre /etc/init.d/apache restart ^^

Partager ce message


Lien à poster
Partager sur d’autres sites
jcaron    11

Evidemment, dans la liste tu as beaucoup de fichiers qui sont listés plusieurs fois (parce qu'ils sont ouverts par plusieurs processus). Mais il y a qui ont été ouverts plusieurs fois par différents processus...



Pour Apache, oui, un apachectl graceful devrait faire l'affaire. Ca va prendre un petit moment parce qu'il ne coupe personne mais attend tranquillement que chaque processus ait fini son boulot, mais à la fin, tu ne devrais plus avoir aucun fichier effacé ouvert.



Kill envoie un signal à un processus. Par défaut c'est SIGTERM, mais tu peux préciser n'importe quel signal soit par son numéro, soit par son nom. Donc kill -HUP pid ça veut dire "envoie SIGHUP à pid".



Tu es sûr que sc_serv est lancé par Apache? D'après la doc, sc_serv est normalement plutôt un processus indépendant. Et d'après la doc, tu peux lui envoyer un SIGHUP pour faire la rotation des fichiers, mais le souci c'est qu'il la fait lui-même, alors qu'il semble être configuré pour utiliser les mêmes fichiers qu'Apache, ce qui va faire des choses pour le moins étranges, avec Apache qui va probablement continuer à écrire dans un fichier qui a été renommé entre temps... Ce serait probablement une bonne idée que de lui faire utiliser des fichiers de logs séparés, mais sans en savoir plus sur le setup complet, difficile de s'avancer plus que ça.



Jacques.


Partager ce message


Lien à poster
Partager sur d’autres sites
Gecko64    0

Oui avec le kill j'ai toujours bossé avec le numéro ou avec le nom complet. Quand j'ai vu -HUP, j'ai pensé a une série de paramètres passés :-/
Maintenant, pour la configuration de castcontrol, ce n'est pas moi qui m'en suis chargé et je ne saurais pas te donner plus d'infos là dessus mais je suis sur que c'est lancé par apache :

www-data 1935 1.7 0.4 29064 2448 ? Sl 2012 4130:27 /var/www/files/1-9-8-linux-glibc6/sc_serv /var/www//temp/8044_530737711507f579607eb5.conf

Le nom d'utilisateur est www-data et seul apache l'utilise ;)
Sinon, Je sais que les process ./sc_serv lancés par castcontrol sont étroitement liés aux process d'apache et que si ceux-ci sont donc relancés, ceux qui en découlent vont aussi se couper.
Je vais planifier une relance complète du service web et des shoutcast, ça sera plus simple je crois.

Partager ce message


Lien à poster
Partager sur d’autres sites
jcaron    11

Ce n'est pas la bonne méthode pour savoir si c'est Apache qui l'a lancé. Il faut regarder qui est le processus père (2448), éventuellement récursivement, pour savoir d'où il vient.



Ceci dit, le fait qu'il ait un fichier de config qui semble créé à la volée est une indication qu'il est peut-être lancé par Apache, mais le fait qu'il semble tourner depuis 2012 et qu'il ait accumulé autant de runtime me paraît très suspect pour un processus lancé par Apache...



Jacques.

Partager ce message


Lien à poster
Partager sur d’autres sites
Gecko64    0

Il semblerait qu'il n'existe plus car il me sort que les process sc_serv contenant bien sûr 2448 en processus père mais aucun process avec le PID du père :

r25xxx:~# ps aux | grep 2448
root 507 0.0 0.1 3560 676 pts/0 S+ 17:40 0:00 grep 2448
www-data 1935 1.7 0.4 29064 2448 ? Sl 2012 4130:53 /var/www/files/1-9-8-linux-glibc6/sc_serv /var/www//temp/8044_530737711507f579607eb5.conf
www-data 21580 1.7 0.4 29064 2448 ? Sl 2012 4127:19 /var/www/files/1-9-8-linux-glibc6/sc_serv /var/www//temp/8040_167501895507fd19cef520.conf
www-data 30776 1.7 0.4 29100 2448 ? Sl 2012 4337:38 /var/www/files/1-9-8-linux-glibc6/sc_serv /var/www//temp/8030_282599470507cb9be3d38a.conf
r25xxx:~#

Il n'aurait pas fait un fork du process ./sc_serv ? Le détacher du processus parent pour qu'il puisse tourner tout seul.

Partager ce message


Lien à poster
Partager sur d’autres sites
jcaron    11

Ce ne sont pas les colonnes que je pensais, ps aux ne donne pas le PPID. ps axl te donnera ça (3e colonne normalement). Et il est possible que chaque processus ait un père différent.



Jacques.


Partager ce message


Lien à poster
Partager sur d’autres sites
Gecko64    0

Oui en effet, j'ai vu 3eme colonne PPID dans le man mais il ne le sortait pas avec ps aux.
En faisant ainsi, j'ai quand même le même résultat :

r25xxx:~# ps axl | grep 2448
0 33 1935 1 40 0 29064 2448 poll_s Sl ? 4131:35 /var/www/files/1-9-8-linux-glibc6/sc_serv /var/www//temp/8044_530737711507f579607eb5.conf
0 0 5066 31159 40 0 3564 684 pipe_w S+ pts/0 0:00 grep 2448
0 33 21580 1 40 0 29064 2448 poll_s Sl ? 4128:00 /var/www/files/1-9-8-linux-glibc6/sc_serv /var/www//temp/8040_167501895507fd19cef520.conf
0 33 30776 1 40 0 29100 2448 poll_s Sl ? 4338:22 /var/www/files/1-9-8-linux-glibc6/sc_serv /var/www//temp/8030_282599470507cb9be3d38a.conf
r25xxx:~#


Sinon certains process tournent sur des pères différents oui :

r25xxx:~# ps axl | grep sc_serv
0 33 1935 1 40 0 29064 2448 poll_s Sl ? 4131:40 /var/www/files/1-9-8-linux-glibc6/sc_serv /var/www//temp/8044_530737711507f579607eb5.conf
0 33 2975 1 40 0 30672 3084 poll_s Sl ? 3923:26 /var/www/files/1-9-8-linux-glibc6/sc_serv /var/www//temp/8014_648496776507f5a1f668dd.conf
0 0 5655 31159 40 0 3564 688 pipe_w S+ pts/0 0:00 grep sc_serv
0 33 6043 1 40 0 30672 2424 poll_s Sl ? 427:41 /var/www/files/1-9-8-linux-glibc6/sc_serv /var/www//temp/8018_2130939221513e8cf15ba4a.conf
0 33 6913 1 40 0 29064 2412 poll_s Sl ? 4130:46 /var/www/files/1-9-8-linux-glibc6/sc_serv /var/www//temp/8046_25096398250853683391da.conf
0 33 7892 1 40 0 32556 3052 poll_s Sl ? 4043:09 /var/www/files/1-9-8-linux-glibc6/sc_serv /var/www//temp/8020_105032901508538d2a3966.conf
0 33 8633 1 40 0 29064 2508 poll_s Sl ? 4414:23 /var/www/files/1-9-8-linux-glibc6/sc_serv /var/www//temp/8022_100601805850853ae9a405e.conf
0 33 9322 1 40 0 30672 3632 poll_s Sl ? 6277:24 /var/www/files/1-9-8-linux-glibc6/sc_serv /var/www//temp/8016_1178821847507e8aa00e9c5.conf
0 33 14050 1 40 0 29064 2412 poll_s Sl ? 4187:32 /var/www/files/1-9-8-linux-glibc6/sc_serv /var/www//temp/8034_366774587507e01b6e0d54.conf
0 33 14542 1 40 0 36148 5364 poll_s Sl ? 6194:41 /var/www/files/1-9-8-linux-glibc6/sc_serv /var/www//temp/8004_1413677038507e02b75734e.conf
0 33 17306 1 40 0 29064 2484 poll_s Sl ? 4043:58 /var/www/files/1-9-8-linux-glibc6/sc_serv /var/www//temp/8002_18007826255080a3f8ac67c.conf
0 33 21580 1 40 0 29064 2448 poll_s Sl ? 4128:05 /var/www/files/1-9-8-linux-glibc6/sc_serv /var/www//temp/8040_167501895507fd19cef520.conf
0 33 23183 1 40 0 32556 5764 poll_s Sl ? 10450:00 /var/www/files/1-9-8-linux-glibc6/sc_serv /var/www//temp/8010_1027336659507fd4eb506a3.conf
0 33 24214 1 40 0 29064 2444 poll_s Sl ? 4282:53 /var/www/files/1-9-8-linux-glibc6/sc_serv /var/www//temp/8038_847521836507eaccc23eb8.conf
0 33 25920 1 40 0 29064 2408 poll_s Sl ? 3689:46 /var/www/files/1-9-8-linux-glibc6/sc_serv /var/www//temp/8036_81680197507caeb613bab.conf
0 33 26477 1 40 0 30672 3928 poll_s Sl ? 3743:23 /var/www/files/1-9-8-linux-glibc6/sc_serv /var/www//temp/8006_665298997507cafe0903d7.conf
0 33 28952 1 40 0 29064 2412 poll_s Sl ? 3568:09 /var/www/files/1-9-8-linux-glibc6/sc_serv /var/www//temp/8042_1422582794507f4cbb7b252.conf
0 33 30201 1 40 0 37944 7416 poll_s Sl ? 11775:14 /var/www/files/1-9-8-linux-glibc6/sc_serv /var/www//temp/8000_1918631885507cb84c2335f.conf
0 33 30771 1 40 0 32556 2844 poll_s Sl ? 3410:36 /var/www/files/1-9-8-linux-glibc6/sc_serv /var/www//temp/8012_1285344967507f500c4ee58.conf
0 33 30776 1 40 0 29100 2448 poll_s Sl ? 4338:28 /var/www/files/1-9-8-linux-glibc6/sc_serv /var/www//temp/8030_282599470507cb9be3d38a.conf
0 33 32712 1 40 0 29132 2408 poll_s Sl ? 184:45 /var/www/files/1-9-8-linux-glibc6/sc_serv /var/www//temp/8032_160335649451538d6c11e93.conf
r25xxx:~#




Partager ce message


Lien à poster
Partager sur d’autres sites
jcaron    11

Ils n'ont plus de père, ils ont été détachés. Ce qui signifie qu'ils ont probablement été lancés par un processus Apache (les FDs ouverts sont une bonne indication), mais qu'ils sont maintenant indépendants, donc tu devrais pouvoir relancer Apache sans te poser de questions.



Le problème, c'est que le processus qui les lance hérite des FDs d'Apache (en particulier access.log et error.log), et les passe à sc_serv, qui les garde ouverts alors qu'au moins access.log il ne s'en sert pas (error.log est lié à STDERR, donc il peut potentiellement envoyer des choses dessus). Comme sc_serv ne les a pas ouverts, il n'a aucune idée de leur existence, et il ne peut pas les fermer, même si tu demandes une rotation des fichiers de logs.



Bref, pour libérer l'espace occupé à l'heure actuelle par ces fichiers, pas d'autre solution que de tuer les sc_serv (et de les relancer je ne sais pas trop comment).



Pour éviter que le problème ne se reproduise à l'avenir, il faudrait modifier le script qui lance sc_serv pour qu'il ferme ces fichiers avant de le lancer.



Jacques.


Partager ce message


Lien à poster
Partager sur d’autres sites
Gecko64    0

Ok je vois oui.
Pour le script c'est un panel complet PHP mais encodé avec un système dont j'ai oublié le nom ce qui rend la chose non éditable :-/
Sinon, je vais planifier un restart d'apache et demander à la personne qui gère les flux de se reconnecter ensuite à castcontrol pour relancer les serveurs shoutcast.
Un grand merci en tout cas; je peux dire que vous m'avez appris pas mal de choses aujourd'hui :)

Partager ce message


Lien à poster
Partager sur d’autres sites
jcaron    11

Le souci, c'est que le problème va se reproduire à la prochaine rotation des logs Apache. Si tu ne peux pas modifier le script qui lance sc_serv, tu as plusieurs options:


1. Tu déplaces sc_serv a un autre endroit. Tu mets à la place un script qui ferme les FDs qui vont bien et qui lance le "vrai" sc_serv en lui passant les mêmes arguments etc.


2. Tu modifies le script qui fait la rotation des logs Apache. Tu ajoutes un -k à gzip (comme ça le fichier n'est pas effacé par gzip), puis tu tronques le fichier avant de l'effacer. Le fichier continuera à être ouvert par sc_serv, mais au moins il n'occupera pas tout plein de place pour rien.



Ceci dit, tu devrais faire remonter le problème aux fournisseurs du script qui lance sc_serv, c'est un vrai bug...



Jacques.

Partager ce message


Lien à poster
Partager sur d’autres sites

Créer un compte ou se connecter pour commenter

Vous devez être membre afin de pouvoir déposer un commentaire

Créer un compte

Créez un compte sur notre communauté. C’est facile !

Créer un nouveau compte

Se connecter

Vous avez déjà un compte ? Connectez-vous ici.

Connectez-vous maintenant

×