/home à 100% sans raison

Support Debian
#1

voilà, j’ai sur un serveur le /home qui augmente sans raison.
c’est totalement aléatoire.

ci dessous les resultats de commande :
df -h
du -shc /home/*
du -shc /home/serverdeb/* (serveurdeb la session utilisateur qui prend tout)

remarquez qu’entre la 2eme et la 3eme commande, il y 142G qui de différence pour serverdeb.
parfois je redemmarre le serveur et j’ai ~100Go qui se libere…
Je ne comprend pas trop…
et ça deviens de + en + fréquent que le /home se remplisse à 100% et bloque tout sauf le ssh (encore heureux…)

[code]root@server01:/home# df -h
Sys. fich. Taille Util. Dispo Uti% Monté sur
rootfs 78G 4,1G 70G 6% /
udev 10M 0 10M 0% /dev
tmpfs 771M 928K 770M 1% /run
/dev/disk/by-uuid/4ad3846f-95e5-4bc5-bee8-a4b732d5bd3c 78G 4,1G 70G 6% /
tmpfs 5,0M 0 5,0M 0% /run/lock
tmpfs 2,5G 224K 2,5G 1% /run/shm
/dev/sdb1 9,2G 167M 8,6G 2% /boot
/dev/md2 413G 313G 80G 80% /stock
/dev/md1 367G 348G 34M 100% /home

root@server01:/home# du -shc /home/*
3,9G /home/ftpbackup
16K /home/lost+found
344G /home/serverdeb
348G total

root@server01:/home# du -shc /home/serverdeb/*
4,0K /home/serverdeb/backup.sh
4,0K /home/serverdeb/backup.sh~
4,0K /home/serverdeb/Bureau
32G /home/serverdeb/Documents
4,0K /home/serverdeb/fstab
4,5G /home/serverdeb/ftpbackup
248K /home/serverdeb/Images
0 /home/serverdeb/index.html.1
0 /home/serverdeb/index.html.2
0 /home/serverdeb/index.html.2.1
0 /home/serverdeb/index.html.2.2
0 /home/serverdeb/index.html.2.3
0 /home/serverdeb/index.html.2.4
4,0K /home/serverdeb/machine.sh
4,0K /home/serverdeb/machine.sh~
4,0K /home/serverdeb/Modèles
4,0K /home/serverdeb/Musique
4,0K /home/serverdeb/ping.sh
4,0K /home/serverdeb/ping.sh~
4,0K /home/serverdeb/Public
4,0K /home/serverdeb/recur.sh
4,0K /home/serverdeb/startup.sh
4,0K /home/serverdeb/startup.sh~
520M /home/serverdeb/Téléchargements
20K /home/serverdeb/test
4,0K /home/serverdeb/usb-mount.sh
4,0K /home/serverdeb/usb-mount.sh~
4,0K /home/serverdeb/Vidéos
166G /home/serverdeb/VirtualBox VMs
202G total
root@server01:/home#
[/code]

Notez que md1 eet md2 sont des raid1

PS : au cas où
sur ce serveur, j’ai une machine virtuelle sous virtualbox qui fait tourner un serveur2003
( besoin d’un soft windows helas…)

#2

Je viens de rebooter 3 fois de suite,
2 fois il ne restait plus que 34M, et VNC refusait l’accès,

maintenant c’est revenu à la normal, 143Go de libre… (/home à 60%)

et j’ai bien 202Go pour servedeb à :
du -shc /home/*
du -shc /home/serverdeb/*

#3

Quand tu fais un du -sh, penses au fichier cachés:

#4

merci pour l’info.
j’avais essayé

cd /home/serverdeb/
du -shc .*[/code]


mais ça ne me retournait rien de concluant, je vais regardé ça de + près :wink:



EDIT : je colle le resultat du dossier en état "normal" ici en attendant que ça replanete
(on se croirait sur crosoft là ^^)

[code]8,0K    .bash_history
4,0K    .bash_logout
4,0K    .bashrc
56M     .cache
384K    .config
12K     .dbus
4,0K    .disk-manager.conf
88K     .gconf
0       .gksu.lock
20K     .gnash
36K     .gnome2
4,0K    .gnome2_private
896K    .gstreamer-0.10
4,0K    .gtk-bookmarks
4,0K    .gvfs
20K     .ICEauthority
12K     .kchmviewer
7,2M    .local
12K     .mission-control
34M     .mozilla
36K     .pki
4,0K    .profile
40K     .pulse
4,0K    .pulse-cookie
84K     .shotwell
8,0K    .ssh
2,3M    .thumbnails
6,5M    .xsession-errors
280K    .xsession-errors.old
#5

Bon alors, j’ai trouvé le “coupable” du 100% du /home
c’est .xession-errors qui en ce moment meme se tape un joli 493Mo
bon, j’ai regardé vite fait, et deja j’ai bloqué le port VNC que j’avais ouvert temporairement pour une maintenance
le si peu de logs que j’ai vu etaient clair
un nombre enorme d’erreur de login à VNC provnenant de chine.

j’ai fait un backup du xession-error poour y regarder + tard

par contre, y a-t-il un moyen de naviguer dans ces erreurs sans ouvrir le fichier en brute txt ?
je veux dire, extraire les différents type d’erreurs,
car le probleme etait la avant que VNC ne soit ouvert.
il y a un bug quelque part et c’est le log d’erreur qui fait tout crasher,
et je n’ai pas envie de laisser un bug trainer non plus.

quelqu’un a -t-il une idée ?

merci

#6

Commence par changer le port de VNC, ça t’évitera pas mal de chinois :slightly_smiling:

#7

Salut,

C’est un mauvais fonctionnement, ne peux-tu pas mettre en place un dispositif type VPN ou SSH avant la connexion VNC ?
Ainsi les utilisateurs vont devoir se connecter en VPN pour pouvoir établir la connexion VNC.
Je ne sais pas à quel point VNC est sécurisé (ou pas), mais ça me parait très risqué de l’exposer directement sur internet.
J’ai vu des choses similaires avec RDP (Windows Server), les machines deviennent rapidement des plateformes à spam.

Si c’est pas possible, commence par changer le port, comme l’a dit debianhadic.

Eventuellement aussi voir avec fail2ban si tu ne peux pas intégrer VNC dans la liste, ça bloquera les tentatives infructueuses venant de Chine.

#8

en fait, j’avais ouvert le port temporairement.
je ne m’attendait pas à un telle virulence, et surtout à un fichier de log aussi gros en peu de temps…
je pensais m’occuper du port par la suite, l’urgence sur le moment était un accès temporaire.

je souhaite depuis un moment que le serveur vnc ne soit accessible que depuis certaines ip d’un reseau vpn privé.
mais bon, pas encore fait.

et sinon le mot de passe fait 8 caractere avec maj et chiffre sans etre un mot du dictionaire
donc ca allait quand meme niveau securité du passe.

je rappel que le solution etait temporaire, la je suis reparti sur un fichier de log vierge.
j’attends de le voir grossir pour detecter le bug.

pour le moment j’ai une becanne à coté avec win ou je me conect en teamviewer pour prendre le vnc du serveur.
(le tout etant toujours une solution temporaire ^^)

sinon, je suis toujours preneur pour ceux qui connaitrait un truc pour naviguer facilement dans un fichier de log

Merci à vous en tout cas.

je laisse ouvert le temps de trouver pour naviguer dans le fichier de log, ça peut servir à quelqu’un par la suite…

#9

[quote=“yox”]en fait, j’avais ouvert le port temporairement.
je ne m’attendait pas à un telle virulence, et surtout à un fichier de log aussi gros en peu de temps…
je pensais m’occuper du port par la suite, l’urgence sur le moment était un accès temporaire.

je souhaite depuis un moment que le serveur vnc ne soit accessible que depuis certaines ip d’un reseau vpn privé.
mais bon, pas encore fait.

et sinon le mot de passe fait 8 caractere avec maj et chiffre sans etre un mot du dictionaire
donc ca allait quand meme niveau securité du passe.

je rappel que le solution etait temporaire, la je suis reparti sur un fichier de log vierge.
j’attends de le voir grossir pour detecter le bug.

pour le moment j’ai une becanne à coté avec win ou je me conect en teamviewer pour prendre le vnc du serveur.
(le tout etant toujours une solution temporaire ^^)[/quote]

Méfie toi du temporaire qui dure :whistle:

Pour ce qui est de VNC, je préfère largement me contenter de SSH qui remplit merveilleusement bien mes besoins.
Pourquoi as-tu besoin d’un affichage graphique sur un serveur ?

[quote=“yox”]sinon, je suis toujours preneur pour ceux qui connaitrait un truc pour naviguer facilement dans un fichier de log

Merci à vous en tout cas.

je laisse ouvert le temps de trouver pour naviguer dans le fichier de log, ça peut servir à quelqu’un par la suite…[/quote]

Un peut de lecture sinon ce sera à grand coup de less :033
http://linuxfr.org/news/gestion-des-logs-avec-logstash-elasticsearch-kibana

#10

il y a un besoin d’affichage car je virtualise un windows server 2003 car il y a un besoin impératif d’un logiciel spécifique.
et c’est un serveur local qui n’utilise vraiment pas toute la puissance, il y un petit coté + simple lors de la copie de fichiers ou install…

pour mes serveur distants c’est clairs, je ne passe que par ssh c’est clair.
mais là pour ce coup, le choix d’une interface graphique est choisie :wink:

Pour le temporaire qui dure, j’essaie d’eviter sur ce serveur à cause des besoins.
je pourrait par exemple me contenter de supprimer le fichier log à interval regulier, mais je souhaite chercher à corriger le bug originel ^^

Merci pour le lien, je vais regarder ça de + près pour voir si c’est ce qui me convient :smiley:

#11

Pour ouvrir les gros fichiers de log, je préfere utiliser tail! ça écite de bloquer la machine plusieurs minutes le temps qu’il ouvre le fichier complet.
J’ai utilisé logwatcher une fois pour un probléme similaire. ca rajoute de la couleur pour une lecture plus rapide (entre autre fonctionnalités)

#12

[quote=“yox”][quote=“Clochette”]
Pour ce qui est de VNC, je préfère largement me contenter de SSH qui remplit merveilleusement bien mes besoins.
Pourquoi as-tu besoin d’un affichage graphique sur un serveur ?
[/quote]

il y a un besoin d’affichage car je virtualise un windows server 2003 car il y a un besoin impératif d’un logiciel spécifique.
et c’est un serveur local qui n’utilise vraiment pas toute la puissance, il y un petit coté + simple lors de la copie de fichiers ou install…

pour mes serveur distants c’est clairs, je ne passe que par ssh c’est clair.
mais là pour ce coup, le choix d’une interface graphique est choisie :wink:

Pour le temporaire qui dure, j’essaie d’eviter sur ce serveur à cause des besoins.
je pourrait par exemple me contenter de supprimer le fichier log à interval regulier, mais je souhaite chercher à corriger le bug originel ^^

Merci pour le lien, je vais regarder ça de + près pour voir si c’est ce qui me convient :smiley:[/quote]

Pour le lien je dirait que dans ce cas il serait surement plus profitable d’exporter les logs sur une autre machine car ce que je t’ai envoyé c’est tout de même la Rolls Royce en matière de gestion des logs.

et je plussoie tail Piratebab, less étant mon réflexe habituel car si les logs sont énorme ils passent en générale à la moulinette sur un serveur de logs à mon taff ^^

Pour ce qui est du vnc, effectivement avec du win 2003 pas trop le choix :stuck_out_tongue:

#13

[quote=“yox”]
il y a un besoin d’affichage car je virtualise un windows server 2003 car il y a un besoin impératif d’un logiciel spécifique.[/quote]
Alors il faut VPN + RDP :wink:
VNC va vite te pourir la vie (latences, bugs, déconnexions, couleurs dégradées, problèmes de clavier fr/en…) alors que RDP est vraiment fait pour ça.

#14

Salut,

[quote=“yox”]Bon alors, j’ai trouvé le “coupable” du 100% du /home
c’est .xession-errors qui en ce moment meme se tape un joli 493Mo
bon, j’ai regardé vite fait, et deja j’ai bloqué le port VNC que j’avais ouvert temporairement pour une maintenance[/quote]

Dans la section T&A : Désactiver ~/.xsession-errors

Il va s’en dire que ceci ne résolve en rien ton souci initial.

ps : Sympa le lien Clochette :wink:

#15

Merci pour tous vos conseils sur l’analyse de logs.
le serveur m’a refait le coup, j’etais rendu à 95Go de logs et ca montait de 1Go toutes les minutes.
Il fallait impoerativement que je fasse finir une tache en cours lancé depuis un poste client.
J’ai donc lancé la suppression avant que ça ne tape le 100%
Petit probleme apparement il continuait à ecrire dans le fichier, meme etant effacé, car un “df -h” me monotrait la place se reduire…

Question:

  • comment bien supprimer un fichier dans ce cas ?

  • Concernant le renvoi du .xsession-errors vers nul, comment retirer celà le jour où je veux detetcer le bug.
    (cette manip peut servir pour le garder en vie, mais come dit avant, ne pas faire du temporaire qui dure …)

Je suis en train de chercher et je ne trouve pas comment activer le bureau à distancevia le ssh.
Quand on va sur preferences->Pratage de bureau.
On coche et ça active direct…
comment faire celà en ssh, pour pouvoir ainsi activer le l’accès VNC “par defaut” de debian sans se retaper une install VNC standard dessus…

Merci d’avance pour tous vos conseils.

#16

Seul solution pour flinguer un fichier en cours d’écriture, c’est d’essayer le

qui le remet à 0. Sinon lui changer ses attributs (chattr)

#17

Salut,

[mono]# rm -i /etc/X11/Xsession.d/00disable-xsession-errors[/mono] ?

[mono]# rm -i /tmp/UTILISATEUR/.xsession-errors[/mono] ?

[mono]# touch /etc/X11/Xsession.d/00disable-xsession-errors && chmod 600 /etc/X11/Xsession.d/00disable-xsession-errors[/mono] ?

[code][07:21:59] ~ # aptitude show teamviewer
Paquet : teamviewer
Nouveau: oui
État: installé
Automatiquement installé: non
Version : 9.0.24147
Priorité : optionnel
Section : non-free/internet
Responsable : Teamviewer GmbH service@teamviewer.com
Architecture : i386
Taille décompressée : 81,9 M
Dépend: libc6 (>= 2.4), libgcc1, libasound2, libfreetype6, zlib1g, libsm6, libxdamage1, libxext6, libxfixes3, libxrandr2, libxrender1, libxtst6
Recommande: ttf-liberation | fonts-liberation
Casse: teamviewer5, teamviewer6, teamviewer7
Description : TeamViewer (Remote Control Application)
TeamViewer is a remote control application. TeamViewer provides easy, fast and secure remote access to Linux, Windows PCs, and Macs.

TeamViewer is free for personal use. You can use TeamViewer completely free of charge to access your private computers or to help your friends
with their computer problems.

To buy a license for commercial use, please visit http://www.teamviewer.com

[07:22:13] ~ # [/code]

teamviewer.com

[07:30:05] ~ # acp teamviewer teamviewer: Installé : 9.0.24147 Candidat : 9.0.24147 Table de version : *** 9.0.24147 0 100 /var/lib/dpkg/status [07:30:08] ~ #

#18

Concernant Team Viewer, je l’utilise beaucoup sur des clients win,
mais, j’avais une petite becanne virtualisée sur un serveur chez kimsuffi sous VMsphere
et teamviewer n’etait vraiment pas du tout stable, j’avais donc deja rayé de la liste TeamViewer pour un client linux…

Merci pour la commande fran.b je pense que je vais faire un cron dessus pour eviter toute surcharge,
Mais je vais aussi preparer un systeme d’alerte dès que le fichier depasse un certain poids afin d’intervenir lors du bug pour trouver la source.

Sinon, le “Partage de bureau”, c’est quel soft ? VNC ?
Parceque je crois que VNCserer n’est pas installé par defaut sur debian (non libre)

#19

C’est Vino qui est installé par défaut (avec Gnome en tous cas), qui utilise VNC.
Il y a aussi Remina qui permet de prendre en charge de nombreux protocoles, dont VNC via SSH, RDP.
Sinon il y a le protocole NX (NoMachine), plus sûr, utilisant moins de bande passante que VNC.
Remina a un greffon sinon paquet QTNX.

#20

Salut,

[quote=“yox”]j’avais une petite becanne virtualisée sur un serveur chez kimsuffi sous VMsphere
et teamviewer n’etait vraiment pas du tout stable[/quote]

Je te l’accorde, ne serait-ce par les interruptions intempestives des connexions établies.

Je tests depuis près de 72 heures (connexion établit en local) [mono]x2goserver/x2goclient[/mono] basé sur le protocole NX (le digne successeur de freenx (?)).

À cette heure le client (contrairement au serveur) est disponible dans nos dépôts, mais ce dernier pose quelques soucis à savoir :

  • la reconnaissance automatique (défaillance) du clavier distant
  • l’interface est en anglais

[code][09:09:07] ~ # acp x2goclient
x2goclient:
Installé : 4.0.2.0-0x2go1+git20140410.586+wheezy.main.1
Candidat : 4.0.2.0-0x2go1+git20140410.586+wheezy.main.1
Épinglage de paquet : 4.0.2.0-0x2go1+git20140410.586+wheezy.main.1
Table de version :
4.0.2.0-2 1000
97 http://ftp.fr.debian.org/debian/ testing/main i386 Packages
95 http://ftp.fr.debian.org/debian/ unstable/main i386 Packages
*** 4.0.2.0-0x2go1+git20140410.586+wheezy.main.1 1000
500 http://packages.x2go.org/debian/ wheezy/main i386 Packages
100 /var/lib/dpkg/status
4.0.1.1-1~bpo7+1 1000
100 http://ftp.debian.org/debian/ wheezy-backports/main i386 Packages
3.99.2.1-5 1000
990 http://ftp.fr.debian.org/debian/ stable/main i386 Packages
3.99.2.1-5~bpo60+1 1000
100 http://backports.debian.org/debian-backports/ squeeze-backports/main i386 Packages
[09:09:17] ~ #

[09:11:12] ~ # acp x2goserver
x2goserver:
Installé : (aucun)
Candidat : 4.0.1.15-0x2go1+git20140403.847+wheezy.main.1
Table de version :
4.0.1.15-0x2go1+git20140403.847+wheezy.main.1 0
500 http://packages.x2go.org/debian/ wheezy/main i386 Packages
[09:11:16] ~ # [/code]

Plutôt prometteur … :wink:


ps : je testerai prochainement les versions (client) Testing et Unstable.