Erreur sur certaine tables mysql

[moser22]

Bonjour,

Je viens de changer de serveur dedié chez ovh. et j'ai un soucis avec l'interepretation de certaines requete mysql.

J'ai l'erreur suivate

Can't create/write to file '/tmp/#sqla05_50189_0.MYI' (Errcode: 28)

Quand je lance:

SELECT code

FROM bouton

ORDER BY RAND( )

LIMIT 8

Alors que de phpmyadmin, je n'ai aucun problème pour lire ou écrire la table. Sauf quand je fais executer sql.

Modifié 4 Décembre 2005 par moser22

[moser22]

je viens de découvrir que c'est la commande rand() qui pose problème

il s'agit certainement de problème de place sur les disques.

dans webmin, j'ai cette erreur dans certains modules: Failed to open /etc/webmin/firewall/config for writing : No space left on device

Comment savoir ce qui me prend cette place et comment corrigé?

Merci

Modifié 4 Décembre 2005 par moser22

[AvenueDuWeb]

Salut,

Regarde si ton répertoire tmp n'est pas protégé en écriture, et sinon regarde si ton disque n'est pas plein. J'ai déjà eu le problème avec mod_gzip qui à cause d'une erreur de script remplissait le disque à coup de fichiers .wrk dans le répertoire tmp (d'où l'utilité de créer le répertoire tmp sur une autre partition). @+

[moser22]

Merci, mais mon répertoire temp est quasiment vide. 2ou 3 fichier wrk mais c'est tout.

Voila le résultat de la commande df, si ça peut orienter quelqu'un:

/dev/sda1 2016016 1658956 254648 87% /

/dev/sda2 67891252 1224772 63217728 2% /home

none 2067196 0 2067196 0% /dev/shm

Merci de m'aider

[moser22]

C'est de pire en pire. J'ai redemarrer le serveur mais il est desormais impossible de lancer mysql. L'accèes a webmin est impossible. Mon site ne tourne plus non plus.

[AvenueDuWeb]

Alors ça veut dire que ta partition principale montée sur / est utilisée à 87 % et qu'il ne reste donc que 254 Mo (ce qui fait peu). Et tu as 60 Go disponible sur la partition home. C'est le partitionnement d'origine chez OVH ? Mais sinon je ne sais pas quoi te dire, ton disque semble en effet plein, donc soit tu as des fichiers inutiles quelque part qui remplissent le disque, soit il faut revoir le partitionnement je pense. @+

[moser22]

Oui, je n'ai pas touché au partitionement. Décidément j'ai beaucoup de problème chez ovh ces temps.

[AvenueDuWeb]

Oui, je n'ai pas touché au partitionement. Décidément j'ai beaucoup de problème chez ovh ces temps.

<{POST_SNAPBACK}>

Ce n'est pas lié à OVH là, car si c'est le partitionnement d'origine tous les serveurs ont le même. C'est l'utilisation que tu en fais. Le serveur dédié si tu as accès au ssh et qu'il ping correctement, le reste dépend de toi et non de ton fournisseur. Après si tu ne te sens pas capable de l'administrer (car cela est relativement complexe d'administrer un serveur dédié) tu peux faire appel à un quelqu'un qui te l'infogère. Dan le webmaster de webmaster-hub propose l'infogérance de serveurs dédiés OVH pour 200 par an (bientôt 250 il me semble). Perso la première fois que j'ai eu le problème avec mod-gzip j'ai mis du temps à comprendre que c'était ça qui était en cause, donc ton problème est sans doute du même type. Regarde du côté des logs peut-être car si tu ne vides pas les logs régulièrement (avec une tâche cron) c'est sûr qu'ils vont vite remplir ton disque. Donc connecte toi en ssh et regarde le répertoire log (sans doute /var/log) et fais un "du -sh" pour avoir la taille du répertoire. Pour t'aider un peu au niveau ssh, voici un petit lien très pratique, qui me sert un peu de pense-bête quand je me rappelle plus de certaines commandes :

http://lea-linux.org/cached/index/Admin-admin_env-shell.html

@+

[moser22]

Merci beaucoup pour ton aide, je vais regarder ça

[Dan]

L'utilisation du répertoire principal n'est pas normale... sur un disque de cette taille tu ne devrais pas dépasser 50%.

Si tu les dépasse, il faut regarder dans /tmp et/ou /var/tmp si tu n'as pas trop de fichiers.

Donnes-nous le résultat d'un "du -s /*" ...

Dan

[moser22]

Alors,

du -s /* donne ça:

5556 /bin

6408 /boot

276 /dev

5596 /etc

4 /home

0 /httpd.conf

4 /initrd

1044 /install.log

44496 /lib

du: cannot change to directory `/proc/376/fd': No such file or directory

du: `/proc/29574/fd/4': No such file or directory

16 /lost+found

4 /mnt

4 /opt

919319 /proc

1832 /root

6664 /sbin

24 /tmp

807652 /usr

746544 /var

/tmp et /var/tmp sont vides.

Je viens de voir que mon repertoire /home est vide alors que je n'ai rien effacé.

...et pas de réponse de la part d'ovh.

Merci pour votre aide

Modifié 5 Décembre 2005 par moser22

[moser22]

Je crois que j'ai identifier le problème

Grâce à la commande du -s, que je ne connaissais pas, j'ai pu découvrir que c'était le repertoire /var/qmail/queue qui faisais presque 1G.

J'ai vidé le repertoire à la main et je redemarrer. Visiblement tout les services tournent normalement maintenant.

Je ne sais pas si c'est une bonne idée d'avoir vidé ce repertoire manuellement. Cela ne va-t-il pas poser des problèmes lors de l'envoi de mails?

Merci à tous pour l'aide que vous m'avez fournie, je suis soulager d'un poid.

[AvenueDuWeb]

Non cela ne va pas poser problème, mais c'était les mails en attente. Tu devrais configurer qmail pour qu'ils ne gardent les mails qu'un certains temps (3 jours par ex) avant de notifier l'expéditeur que le mail ne peut être envoyé. Je ne connais pas bien qmail donc je ne vais pas t'aider sur ce point, mais je suppose que c'est gérable dans webmin ce type d'opérations. @+

[Dan]

Ca ne va pas poser problème ... pas si sûr

Si tu as viré l'intégralité du contenu du répertoire /var/qmail/queue ... tu n'as plus la structure logique de celui-ci, ni les sous répertoires nécessaires à qmail.

Vas voir cette page pour pouvoir recréer la queueu qmail sans risque:

http://guides.ovh.com/QueueQmailFull/contenu.html

De plus, /home quasi vide me semble anormal. Tu devrais avoir un répertoire ovh ainsi que tes sites.

Fais ceci:

cd /home
du -s *

et donnes-nous le résultat.

[moser22]

pas de problème maintenant au niveau du repertoire /home.

je suppose qu'il n'arrivait pas à monter la partition quand / était full.

merci, je vais essayer de refaire cette queue.