Serveur HS

Support Debian
#1

Bonjour

J’ai un serveur qui tournait depuis près de 2 ans chez OVH qui ne reboot plus. Le hardware réussit tous les tests et je ne détecte rien de clairement suspect dans les logs.

Ayant fait un upgrade squeeze->wheezy il y a quelques mois je me demande si ce n’est pas le pb.

Je suis très ennuyé car j’ai épuisé toutes les pistes que je connais (et j’en connais assez peu) et ce serveur est en panne depuis maintenant 2 jours. J’en viens à me demander si le passage en wheezy n’est pas le pb.

Merci pour votre aide

#2

[quote]Dec 5 00:33:26 ns1 kernel: Out of memory: Kill process 29161 (php-cgi) score 438 or sacrifice child
Dec 5 00:33:26 ns1 kernel: Killed process 29161 (php-cgi) total-vm:1347384kB, anon-rss:1122368kB, file-rss:8kB[/quote]
Ça, c’est suspect. Epuisement de la mémoire au point de devoir tuer des processus.
Je tenterais de désactiver le maximum de services non indispensables (serveur web, mail, antispam…) au démarrage.

Les logs datés de deux jours correspondent-ils à la dernière tentative de démarrage ou bien au moment où le serveur fonctionnait encore ?

#3

Justement je me demandais comment rebooter en niveau 1 (single user) sans tous les services plutôt que de les désactiver tous un par un

Les logs datent du crash, le 5/12, sauf le dmesg qui date de la dernière tentative de reboot.
Ca ne vous choque pas qu’il s’arrête à la mise en place du swap ?

#4

Et il y a un fichier dmesg.log.* pour chaque tentative de démarrage antérieure ?
C’est déjà un bon signe que ce fichier soit créé, cela signifie que le processus d’initialisation arrive jusqu’au script [mono]bootlogs[/mono] qui s’exécute vers la fin d’un runlevel standard.

Il ne se passe pas forcément grand-chose dans les logs du noyau après l’activation du swap, et si le crash est brutal il se peut que les derniers messages n’aient pas le temps d’être effectivement écrits sur le disque (d’où les réparations de filesystem qu’on voit). Mais si tu as un doute, tu peux commenter la ligne du swap dans /etc/fstab.

En console de réparation, il pourrait être intéressante de faire une vérification forcée de tous les systèmes de fichiers avec fsck.

Je ne vois pas trop l’intérêt de démarrer en single user car le service SSH ne serait pas démarré. Ça permettrait juste de vérifier si la machine répond au ping.

#5

J’ai déjà fait les fsck sur les 2 disques sans trouver d’erreur.

L’upgrade à Wheezy ne pourrait pas engendrer un système non bootable ?

#6

Salut,

As-tu ouvert un ticket d’incident ?
Si ce n’est fait, je t’invite à prendre les devants au plus vite …

Il y a un peu plus de deux ans je me suis retrouvé avec un gros boxon sur l’un de mes serveurs.
Je me retrouvais systématiquement en mode rescue.
J’ai balancé des restaurations (antérieur à plus de trois mois) à tout-va.
J’ai bataillé avec eux pendant plus d’une semaine.
J’ai eu le droit à l’invocation de problème logiciel, chose qui est de ton ressort ou celui de leur service technique payant (selon l’offre).
La panoplie de test disque et ram.

Des échanges très chaud.

Au final, un samaritain c’est aperçu (a convenu) qu’il s’agissait d’un défaut de la carte mère.

Ceci fait, j’ai réinstallé selon leur mode opératoire, je suis passé en mode rescue et j’ai envoyé ma dernière sauvegarde, depuis … RAS !

Sois patient et convaincant à la fois, appuies toi sur tes logs et tests.

À la réception du premier message, tarabustes (x fois par jour) les, sans répits … :wink:

PS :

[quote=“kmchen”]

L’upgrade à Wheezy ne pourrait pas engendrer un système non bootable ?[/quote]

Nullement !

#7

Il semble y avoir un souci avec clamav, est ce que ton serveur de mails est particulièrement sollicité? Si tu gères un domaine, n’y a-t-il pas eu des retours de mails du à un abruti envoyant des spams semblant provenir de ton domaine (ça m’est arrivé 3-4 fois et ça te met un machine à genou si tu ne l’as pas dimensionné pour recevoir 100000 courriels en quelques heures, par exemple en testant tous les mails avec clamav)

#8

On ne fait pas un fsck sur un disque mais un système de fichiers.

D’après dmesg.log le système va assez loin dans le démarrage, il est donc bootable.
Tu n’avais jamais redémarré le serveur depuis sa mise à niveau il y a quelques mois ? Il y a pourtant eu au moins une mise à jour de sécurité du noyau fin octobre.

#9

J’ai fait un smartctl du sda qui n’a rien donné:

[code]# smartctl -t long /dev/sda
//suivi 172mn plus tard de :

smartctl -l selftest /dev/sda

smartctl 5.41 2011-06-09 r3365 [x86_64-linux-3.10.23-xxxx-std-ipv6-64-rescue] (local build)
Copyright © 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error

1 Extended offline Completed without error 00% 31241 -

2 Short offline Completed without error 00% 5527 -

3 Short offline Completed without error 00% 5519 -

4 Short offline Completed without error 00% 5519 -

5 Short offline Completed without error 00% 5517 -

6 Short offline Completed without error 00% 5497 -

7 Short offline Completed without error 00% 5496 -

8 Short offline Completed without error 00% 8 -

9 Short offline Completed without error 00% 8 -

#10 Short offline Completed without error 00% 2 -[/code]

J’ai inhibé les services principaux et rebooté HDD:

root@rescue:/mnt/disc1/etc/init.d# mv apache2 apache2.orig
root@rescue:/mnt/disc1/etc/init.d# mv clamav-daemon clamav-daemon.orig
root@rescue:/mnt/disc1/etc/init.d# mv clamav-freshclam clamav-freshclam.orig
root@rescue:/mnt/disc1/etc/init.d# mv amavis amavis.orig
root@rescue:/mnt/disc1/etc/init.d# mv dovecot dovecot.orig
root@rescue:/mnt/disc1/etc/init.d# mv postfix postfix.orig
root@rescue:/mnt/disc1/etc/init.d# mv spamassassin spamassassin.orig
root@rescue:/mnt/disc1/etc/init.d# mv dkim-filter dkim-filter.orig
root@rescue:/mnt/disc1/etc/init.d# mv fail2ban fail2ban.orig
root@rescue:/mnt/disc1/etc/init.d# mv mysql mysql.orig
root@rescue:/mnt/disc1/etc/init.d# mv postfix-policyd postfix-policyd.orig
root@rescue:/mnt/disc1/etc/init.d# mv pure-ftpd-mysql pure-ftpd-mysql.orig[/code]

Le serveur ne boot toujours pas. 

L'offre que j'ai kimsufi.com ne procure aucun support technique s'il n'y a pas de panne matérielle démontrée. Mais comment être sûr du matériel ?
Je commence à être dans de très sales draps...

3 jours que ce serveur est en panne. Je n'ai pu mettre en évidence une panne matérielle mais il n'y a rien dans les logs qui montre un problème de config logicielle.
Le message dans les logs de CLAMD tendrait à montrer un pb matériel récurrent:
[code]kmc@kmcs:~/crash_5dec$ grep "Too many retries" syslog
Dec 5 00:08:21 ns1 amavis[25328]: (25328-13) (!)ClamAV-clamd av-scanner FAILED: run_av error: Too many retries to talk to /var/run/clamav/clamd.ctl (All attempts (1) failed connecting to /var/run/clamav/clamd.ctl) at (eval 118) line 603.\n
Dec 5 00:20:38 ns1 amavis[4159]: (04159-13) (!)ClamAV-clamd av-scanner FAILED: run_av error: Too many retries to talk to /var/run/clamav/clamd.ctl (All attempts (1) failed connecting to /var/run/clamav/clamd.ctl) at (eval 118) line 603.\n
Dec 5 00:29:13 ns1 amavis[25328]: (25328-14) (!)ClamAV-clamd av-scanner FAILED: run_av error: Too many retries to talk to /var/run/clamav/clamd.ctl (All attempts (1) failed connecting to /var/run/clamav/clamd.ctl) at (eval 118) line 603.\n
Dec 5 00:33:03 ns1 amavis[4159]: (04159-14) (!)ClamAV-clamd av-scanner FAILED: run_av error: Too many retries to talk to /var/run/clamav/clamd.ctl (All attempts (1) failed connecting to /var/run/clamav/clamd.ctl) at (eval 118) line 603.\n
Dec 5 00:38:05 ns1 amavis[25328]: (25328-15) (!)ClamAV-clamd av-scanner FAILED: run_av error: Too many retries to talk to /var/run/clamav/clamd.ctl (All attempts (1) failed connecting to /var/run/clamav/clamd.ctl) at (eval 118) line 603.\n

Le reboot sans les services principaux n’a rien donné. Donc les principaux services HTTP, SMTP ne sont pas en cause.

Comment sortir de cette impasse ?

#10

Voici la réponse du service technique d’ovh:

[quote]Bonjour,

j’ai vérifier vos logs récents et je constate que le
kernel tue les processus car trop gourmand en mémoire
vive:

root@rescue:/mnt/var/log# grep oom-killer *.log
kern.log:Dec 3 19:14:26 ns1 kernel: php-cgi invoked
oom-killer: gfp_mask=0x201da, order=0, oom_adj=0,
oom_score_adj=0
kern.log:Dec 3 19:14:27 ns1 kernel: pop3-login invoked
oom-killer: gfp_mask=0x84d0, order=0, oom_adj=0,
oom_score_adj=0
kern.log:Dec 4 23:52:01 ns1 kernel: pop3-login invoked
oom-killer: gfp_mask=0x84d0, order=0, oom_adj=0,
oom_score_adj=0
kern.log:Dec 4 23:52:24 ns1 kernel: spamd invoked
oom-killer: gfp_mask=0x84d0, order=0, oom_adj=0,
oom_score_adj=0
kern.log:Dec 4 23:52:24 ns1 kernel: mysqld invoked
oom-killer: gfp_mask=0x84d0, order=0, oom_adj=0,
oom_score_adj=0
kern.log:Dec 5 00:30:21 ns1 kernel: pop3-login invoked
oom-killer: gfp_mask=0x201da, order=0, oom_adj=0,
oom_score_adj=0
kern.log:Dec 5 00:30:59 ns1 kernel: spamd invoked
oom-killer: gfp_mask=0x201da, order=0, oom_adj=0,
oom_score_adj=0
kern.log:Dec 5 00:30:59 ns1 kernel: spamd invoked
oom-killer: gfp_mask=0x201da, order=0, oom_adj=0,
oom_score_adj=0
kern.log:Dec 5 00:33:26 ns1 kernel: fail2ban-server
invoked oom-killer: gfp_mask=0x84d0, order=0, oom_adj=0,
oom_score_adj=0
root@rescue:/mnt/var/log#
root@rescue:/mnt/var/log# free -m
total used free shared
buffers cached
Mem: 1977 383 1594 0
0 262
-/+ buffers/cache: 119 1857
Swap: 0 0 0
root@rescue:/mnt/var/log#

ce qui explique l’instabilité du serveur, celui ci ne
disposant pas d’assez de RAM pour faire fonctionner
correctement tous les services.
Je vous invite à opter pour une machine d’une gamme
supérieure disposant de plus de RAM.

Noter qu’on assure que la partie matériel et on
n’intervient pas pour des souci logiciel.

Pour d’autre information vous pouvez poser vos questions
sur le forum: forum.kimsufi.com/

Cordialement,
Naoufel.[/quote]

Pas de pb pour booster la machine…
Mais par ailleurs ceci n’explique pas que le serveur n’arrive pas à booter à froid avec la moitié des services arrêtés…
Qu’en pensez vous ?

#11

Des processus tués par manque de mémoire, rien qu’on ne savait déjà. A noter que la consommation excessive de mémoire n’est pas forcément causée par les processus tués, simplement c’est le seul moyen pour noyau de libérer de la mémoire. Ainsi si un système de fichiers temporaire de type tmfps (par exemple pour /tmp) occupe beaucoup de mémoire, la seule façon de la libérer est de supprimer les fichiers qu’il contient, et le noyau ne le fera jamais de lui-même. Le swap devrait aider, mais je trouve qu’il est un peu petit (512 Mio) par rapport à la RAM (2 Gio). Il y a aussi certaines opérations lors du montage d’un système de fichiers comme XFS qui peuvent consommer beaucoup de mémoire.

Le serveur répond-il au ping, au moins pendant le démarrage avant de planter ? Si le réseau est configuré par /etc/network/interfaces, il devrait être actif avant l’exécution du script qui enregistre /var/log/dmesg, et on a vu que l’initialisation arrive au moins jusque là puisque le fichier est créé à chaque tentative démarrage.

Tu l’avais déjà dit dans ton premier message. Et ce n’est pas la même chose que fsck. smartctl vérifie un disque, fsck vérifie un systèmes de fichiers. As-tu vérifié l’espace libre sur les différents systèmes de fichiers ?

Je ne vois pas en quoi ces messages montrent un problème matériel.

#12

le df ne montre aucune partition saturée. Par contre je n’avais pas pensé au /tmp.

root@rescue:~# du -sm /mnt/sda1/tmp/ 202 /mnt/sda1/tmp/ root@rescue:~# ls -l /mnt/sda1/tmp/ total 13584 drwx------ 2 root root 4096 Nov 4 20:06 aptitude-root.12044:dKKrzs drwx------ 2 root root 4096 Nov 4 12:02 aptitude-root.12860:CFrtOA drwx------ 2 root root 4096 Nov 4 12:03 aptitude-root.12968:QCl6X1 drwx------ 2 root root 4096 Nov 4 12:14 aptitude-root.13831:ScTLuO drwx------ 2 root root 4096 Nov 4 12:25 aptitude-root.15368:N4MUlQ drwx------ 2 root root 4096 Nov 5 09:38 aptitude-root.1741:YX7bgP drwx------ 2 root root 4096 Nov 3 19:38 aptitude-root.1917:Px8BjJ drwx------ 2 root root 4096 Nov 4 12:51 aptitude-root.31720:JXZb0e drwx------ 2 root root 4096 Nov 5 09:51 aptitude-root.3849:uRcMS4 drwx------ 2 root root 4096 Nov 4 10:29 aptitude-root.4565:r8Xc34 drwx------ 2 root root 4096 Nov 4 10:31 aptitude-root.4704:0v80Io drwx------ 2 root root 4096 Nov 4 10:33 aptitude-root.4843:M6HX2j -rw-r--r-- 1 500 500 1819 Dec 5 00:38 cpu_stats -rw-r--r-- 1 root root 318460 Mar 1 2014 cuba_contents-falang.sql -rw-r--r-- 1 root root 14009 Mar 1 2014 cuba_modules.sql -rw-rw-rw- 1 5031 5005 83792 Dec 3 22:52 ggfr_bed+and+breakfast+cuba_0_10.cache -rw-rw-rw- 1 5031 5005 82677 Dec 3 22:52 ggfr_bed+and+breakfast+cuba_10_10.cache -rw-rw-rw- 1 5031 5005 79594 Dec 3 22:52 ggfr_bed+and+breakfast+cuba_20_10.cache -rw-rw-rw- 1 5031 5005 82872 Dec 3 22:52 ggfr_bed+and+breakfast+cuba_30_10.cache -rw-rw-rw- 1 5031 5005 80436 Dec 3 22:52 ggfr_bed+and+breakfast+cuba_40_10.cache -rw-rw-rw- 1 5031 5005 81853 Dec 3 22:52 ggfr_bed+and+breakfast+cuba_50_10.cache -rw-rw-rw- 1 5031 5005 81731 Dec 3 22:52 ggfr_bed+and+breakfast+cuba_60_10.cache -rw-rw-rw- 1 5031 5005 82452 Dec 3 22:52 ggfr_bed+and+breakfast+cuba_70_10.cache -rw-rw-rw- 1 5031 5005 81507 Dec 3 22:52 ggfr_bed+and+breakfast+cuba_80_10.cache -rw-rw-rw- 1 5031 5005 83427 Dec 3 22:52 ggfr_bed+and+breakfast+cuba_90_10.cache -rw-rw-rw- 1 5031 5005 79733 Dec 3 22:52 ggfr_casa+particular+habana_0_10.cache -rw-rw-rw- 1 5031 5005 79406 Dec 3 22:52 ggfr_casa+particular+habana_10_10.cache -rw-rw-rw- 1 5031 5005 78611 Dec 3 22:52 ggfr_casa+particular+habana_20_10.cache -rw-rw-rw- 1 5031 5005 79136 Dec 3 22:52 ggfr_casa+particular+habana_30_10.cache -rw-rw-rw- 1 5031 5005 79509 Dec 3 22:52 ggfr_casa+particular+habana_40_10.cache -rw-rw-rw- 1 5031 5005 79851 Dec 3 22:52 ggfr_casa+particular+habana_50_10.cache -rw-rw-rw- 1 5031 5005 79358 Dec 3 22:52 ggfr_casa+particular+habana_60_10.cache -rw-rw-rw- 1 5031 5005 80212 Dec 3 22:52 ggfr_casa+particular+habana_70_10.cache -rw-rw-rw- 1 5031 5005 78923 Dec 3 22:52 ggfr_casa+particular+habana_80_10.cache -rw-rw-rw- 1 5031 5005 80181 Dec 3 22:52 ggfr_casa+particular+habana_90_10.cache -rw-rw-rw- 1 5031 5005 86207 Dec 3 22:52 ggfr_casa+particulares+cuba_0_10.cache -rw-rw-rw- 1 5031 5005 83752 Dec 3 22:52 ggfr_casa+particulares+cuba_10_10.cache -rw-rw-rw- 1 5031 5005 84794 Dec 3 22:52 ggfr_casa+particulares+cuba_20_10.cache -rw-rw-rw- 1 5031 5005 88758 Dec 3 22:52 ggfr_chambre+chez+habitant+cuba_0_10.cache -rw-rw-rw- 1 5031 5005 82857 Dec 3 22:52 ggfr_chambre+chez+habitant+cuba_10_10.cache -rw-rw-rw- 1 5031 5005 81764 Dec 3 22:52 ggfr_chambre+cuba_0_10.cache -rw-rw-rw- 1 5031 5005 83089 Dec 3 22:52 ggfr_chambre+cuba_10_10.cache -rw-rw-rw- 1 5031 5005 81737 Dec 3 22:52 ggfr_chambre+d%27h%F4tes+cuba_0_10.cache -rw-rw-rw- 1 5031 5005 80596 Dec 3 22:52 ggfr_chambre+d%27h%F4tes+cuba_10_10.cache -rw-rw-rw- 1 5031 5005 81515 Dec 3 22:52 ggfr_chambre+d%27h%F4tes+cuba_20_10.cache -rw-rw-rw- 1 5031 5005 79472 Dec 3 22:52 ggfr_chambre+d%27h%F4tes+cuba_30_10.cache -rw-rw-rw- 1 5031 5005 83940 Nov 10 17:57 ggfr_chambre+d%27h%F4tes+cuba_40_10.cache -rw-rw-rw- 1 5031 5005 84427 Dec 3 22:52 ggfr_chambre+d+hotes+cuba_0_10.cache -rw-rw-rw- 1 5031 5005 82757 Dec 3 22:52 ggfr_chambre+d+hotes+cuba_10_10.cache -rw-rw-rw- 1 5031 5005 83262 Dec 3 22:52 ggfr_chambre+d+hotes+cuba_20_10.cache -rw-rw-rw- 1 5031 5005 81072 Dec 3 22:52 ggfr_chambre+d+hotes+cuba_30_10.cache -rw-rw-rw- 1 5031 5005 82294 Nov 24 01:05 ggfr_chambre+d+hotes+cuba_40_10.cache -rw-rw-rw- 1 5031 5005 77970 Dec 3 22:52 ggfr_cuba+casa_0_10.cache -rw-rw-rw- 1 5031 5005 79572 Nov 24 01:06 ggfr_cuba+casa_10_10.cache -rw-rw-rw- 1 5031 5005 80389 Dec 3 22:52 ggfr_cuba+chez+l+habitant_0_10.cache -rw-rw-rw- 1 5031 5005 80779 Dec 3 22:52 ggfr_cuba+chez+l+habitant_10_10.cache -rw-rw-rw- 1 5031 5005 80461 Dec 3 22:52 ggfr_cuba+chez+l+habitant_20_10.cache -rw-rw-rw- 1 5031 5005 89812 Dec 3 22:52 ggfr_hebergement+habitant+Cuba_0_10.cache -rw-rw-rw- 1 5031 5005 85317 Dec 3 22:52 ggfr_hebergement+habitant+Cuba_10_10.cache -rw-rw-rw- 1 5031 5005 83849 Dec 3 22:52 ggfr_hebergement+habitant+Cuba_20_10.cache -rw-rw-rw- 1 5031 5005 88628 Dec 3 22:52 ggfr_location+chez+l%27habitant+cuba_0_10.cache -rw-rw-rw- 1 5031 5005 82887 Dec 3 22:52 ggfr_location+chez+l%27habitant+cuba_10_10.cache -rw-rw-rw- 1 5031 5005 81159 Dec 3 22:52 ggfr_location+chez+l%27habitant+cuba_20_10.cache -rw-rw-rw- 1 5031 5005 87512 Dec 3 22:52 ggfr_logement+chez+l+habitant+cuba_0_10.cache -rw-rw-rw- 1 5031 5005 84435 Dec 3 22:52 ggfr_logement+chez+l+habitant+cuba_10_10.cache -rw-rw-rw- 1 5031 5005 81555 Dec 3 22:52 ggfr_loger+chez+l+habitant+cuba_0_10.cache -rw-rw-rw- 1 5031 5005 81220 Dec 3 22:52 ggfr_loger+chez+l+habitant+cuba_10_10.cache -rw-rw-rw- 1 5031 5005 85627 Dec 3 22:52 ggfr_louer+chambre+Cuba_0_10.cache -rw-rw-rw- 1 5031 5005 82815 Dec 3 22:52 ggfr_louer+chambre+Cuba_10_10.cache -rw-rw-rw- 1 5031 5005 80772 Dec 3 22:52 ggfr_louer+chambre+Cuba_20_10.cache -rw-rw-rw- 1 5031 5005 89229 Dec 3 22:52 ggfr_louer+maison+cuba_0_10.cache -rw-rw-rw- 1 5031 5005 85473 Dec 3 22:52 ggfr_louer+maison+cuba_10_10.cache -rw-rw-rw- 1 5031 5005 84837 Dec 3 22:52 ggfr_louer+maison+cuba_20_10.cache -rw-rw-rw- 1 5031 5005 86318 Dec 3 22:52 ggfr_louer+maison+cuba_30_10.cache -rw-rw-rw- 1 5031 5005 83549 Dec 3 22:52 ggfr_louer+maison+cuba_40_10.cache -rw-rw-rw- 1 5031 5005 82402 Nov 10 17:57 ggfr_louer+maison+cuba_50_10.cache -rw-rw-rw- 1 5031 5005 81466 Dec 3 22:52 ggfr_maison+d+hote+cuba_0_10.cache -rw-rw-rw- 1 5031 5005 82741 Dec 3 22:52 ggfr_maison+d+hote+cuba_10_10.cache -rw-rw-rw- 1 5031 5005 78641 Dec 3 22:52 ggfr_maison+d+hote+cuba_20_10.cache -rw-rw-rw- 1 5031 5005 83466 Dec 3 22:52 ggfr_maison+d+hote+cuba_30_10.cache -rw-rw-rw- 1 5031 5005 83783 Nov 12 10:58 ggfr_maison+d+hote+cuba_40_10.cache -rw-rw-rw- 1 5031 5005 92723 Dec 3 22:52 ggfr_r%E9server+chambre+cuba_0_10.cache -rw-rw-rw- 1 5031 5005 84679 Dec 3 22:52 ggfr_r%E9server+chambre+cuba_10_10.cache -rw-rw-rw- 1 5031 5005 76888 Dec 3 22:52 ggfr_se+loger+%E0+cuba_0_10.cache -rw-rw-rw- 1 5031 5005 93432 Dec 3 22:52 ggfr_tourisme+cuba_0_10.cache -rw-rw-rw- 1 5031 5005 85998 Dec 3 22:52 ggfr_tourisme+cuba_10_10.cache -rw-rw-rw- 1 5031 5005 85754 Dec 3 22:52 ggfr_tourisme+cuba_20_10.cache -rw-rw-rw- 1 5031 5005 83828 Dec 3 22:52 ggfr_tourisme+cuba_30_10.cache -rw-rw-rw- 1 5031 5005 83604 Dec 3 22:52 ggfr_tourisme+cuba_40_10.cache -rw-rw-rw- 1 5031 5005 84303 Dec 3 22:52 ggfr_tourisme+cuba_50_10.cache -rw-rw-rw- 1 5031 5005 83813 Dec 3 22:52 ggfr_tourisme+cuba_60_10.cache -rw-rw-rw- 1 5031 5005 84617 Dec 3 22:52 ggfr_tourisme+cuba_70_10.cache -rw-rw-rw- 1 5031 5005 85317 Dec 3 22:52 ggfr_tourisme+cuba_80_10.cache -rw-rw-rw- 1 5031 5005 85226 Dec 3 22:53 ggfr_tourisme+cuba_90_10.cache -rw-rw-rw- 1 5031 5005 92472 Dec 3 22:53 ggfr_voyage+cuba_0_10.cache -rw-rw-rw- 1 5031 5005 91506 Dec 3 22:53 ggfr_voyage+cuba_10_10.cache -rw-rw-rw- 1 5031 5005 92871 Dec 3 22:53 ggfr_voyage+cuba_20_10.cache -rw-rw-rw- 1 5031 5005 91520 Dec 3 22:53 ggfr_voyage+cuba_30_10.cache -rw-rw-rw- 1 5031 5005 71809 Dec 3 22:52 http%3A%2F%2Fwww.google.fr%2Fsearch%3Fgl%3DFR%26pws%3D0%26hl%3Dfr%26meta%3Dlr%253Dlang_fr%26q%3Dsite%253Awww.mon-voyage-a-cuba.com.cache srwxrwxr-x 1 root root 0 Nov 16 2013 local -rw-r--r-- 1 root root 207 Sep 11 10:10 mailing.log -rw-r--r-- 1 root root 2606658 Oct 10 2013 mailing.report -rw-r--r-- 1 root root 0 Oct 16 2013 mailq -rw-r--r-- 1 root root 957052 Jul 16 2013 pfqueue_spam drwxr-xr-x 3 root root 4096 Jan 3 2012 php5-build -rw-r--r-- 1 root root 891 Dec 4 01:37 putftp -rw-r--r-- 1 root root 11749 Feb 27 2014 script_backup.tar.gz -rwxrwxrwx 1 root root 2401179 Nov 30 04:17 sent ---------- 1 root mail 0 Jul 22 10:09 sent.ns1.19660 ---------- 1 root mail 0 Jul 22 10:58 sent.ns1.24864 ---------- 1 root mail 0 Jul 22 10:58 sent.ns1.24877 ---------- 1 root mail 0 Jul 22 10:58 sent.ns1.24889 ---------- 1 root mail 0 Jul 22 11:00 sent.ns1.25118 ---------- 1 root mail 0 Jul 22 11:00 sent.ns1.25130 ---------- 1 root mail 0 Jul 22 11:00 sent.ns1.25143 ---------- 1 root mail 0 Jul 22 11:00 sent.ns1.25155 ---------- 1 root mail 0 Jul 22 11:00 sent.ns1.25167 -rw-r--r-- 1 root root 96 Oct 7 2013 undelivered -rw-r--r-- 1 root root 0 Oct 31 19:15 upgrade-wheezyetape.script -rw-r--r-- 1 root root 12 Oct 31 19:15 upgrade-wheezyetape.time -rw-r--r-- 1 root root 358 Oct 26 11:44 wroot_surveil.msg root@rescue:~# rm -r /mnt/sda1/tmp/* root@rescue:~#

Oui le serveur répond au ping un moment.

Par contre le /var/log/boot qui me permtrait de savoir quels services sont lancés est vide.
Comment puis-je l’activer ?

Comment installer sysv-rc-conf en mode rescue chez OVH. J’ai tenté un chroot sur le disque contenant la racine mais aptitude se plaint de ne pouvoir accéder à /var/run qui est sur l’autre disque monté depuis le système de rescue

#13

Re,

Inclus ce périphérique dans ton chroot, tu adaptes selon ton mode opératoire.

#14

Comprends pas

[code]root@rescue:~# ls -l /mnt/sda3
total 96
-rw------- 1 root root 9216 Dec 9 19:01 aquota.group
-rw------- 1 root root 12288 Dec 9 19:01 aquota.user
drwxr-x— 3 root root 4096 Dec 8 14:10 backup
drwxr-xr-x 2 root root 4096 Nov 17 01:25 backups
drwxr-xr-x 14 root root 4096 Nov 4 17:51 cache
drwxr-xr-x 53 root root 4096 Nov 16 12:01 lib
drwxrwsr-x 2 root staff 4096 Nov 13 2010 local
lrwxrwxrwx 1 root root 9 Dec 9 18:54 lock -> /run/lock
drwxr-xr-x 15 root root 4096 Dec 9 20:42 log
drwx------ 2 root root 16384 Jan 3 2012 lost+found
drwxrwsr-x 2 root mail 4096 Dec 3 04:12 mail
drwxr-xr-x 2 root root 4096 Dec 30 2010 opt
-rw------- 1 root root 0 Jan 3 2012 quota.group
-rw------- 1 root root 0 Jan 3 2012 quota.user
drwxr-xr-x 2 root root 4096 Dec 7 01:13 root
lrwxrwxrwx 1 root root 4 Nov 1 12:19 run -> /run
drwxr-xr-x 5 root root 4096 Nov 5 11:02 spool
drwxr-xr-x 13 ovh users 4096 Oct 31 18:26 svg
drwxrwxrwt 2 root root 4096 Dec 4 01:30 tmp
drwxr-xr-x 9 5000 5000 4096 Nov 21 16:55 vmail
drwxr-xr-x 11 root root 4096 Nov 1 01:10 www
root@rescue:~# ls -l /mnt/sda1
total 1860
-rw------- 1 root root 10240 Dec 5 00:39 aquota.group
-rw------- 1 root root 9216 Dec 5 00:39 aquota.user
drwxr-xr-x 2 root root 4096 Oct 31 20:07 bin
drwxr-xr-x 3 root root 4096 Jan 3 2012 boot
drwxr-xr-x 5 root root 4096 Dec 30 2010 dev
drwxr-xr-x 125 root root 12288 Nov 22 01:08 etc
drwxr-xr-x 125 root root 12288 Nov 5 09:18 etc.wheezy
drwxr-xr-x 4 root root 4096 Nov 12 2013 home
drwxr-xr-x 14 root root 12288 Nov 5 09:13 lib
drwxr-xr-x 2 root root 4096 Oct 31 19:55 lib32
drwxr-xr-x 2 root root 4096 Oct 31 19:55 lib64
drwx------ 2 root root 16384 Jan 3 2012 lost+found
drwxr-xr-x 3 root root 4096 Dec 30 2010 media
drwxr-xr-x 2 root root 4096 Nov 13 2010 mnt
drwxr-xr-x 6 root root 4096 Nov 3 17:14 opt
drwxr-xr-x 2 root root 4096 Jan 3 2012 proc
drwx------ 6 root root 1630208 Dec 9 18:04 root
drwxr-xr-x 3 root root 4096 Dec 9 17:38 run
drwxr-xr-x 2 root root 12288 Nov 5 09:13 sbin
drwxr-xr-x 2 root root 4096 Jul 21 2010 selinux
drwxr-xr-x 2 root root 4096 Dec 30 2010 srv
drwxr-xr-x 2 root root 4096 Nov 15 2010 sys
drwxrwxrwx 4 root root 106496 Dec 9 18:50 tmp
drwxr-xr-x 11 root root 4096 Oct 31 19:55 usr
drwxr-xr-x 4 root root 4096 May 2 2012 var
-rw-r–r-- 1 root root 53 Dec 2 23:17 wroot_surveil.msg

root@rescue:~# chroot /mnt/sda1

root@rescue:/# aptitude install sysv-rc-conf
E: Impossible d’ouvrir le fichier verrou /var/lib/dpkg/lock - open (2: Aucun fichier ou dossier de ce type)
E: Impossible de verrouiller le répertoire d’administration (/var/lib/dpkg/). Avez-vous les privilèges du superutilisateur ?
[ ERR] Lecture des listes de paquets
E: Impossible d’ouvrir le fichier /var/lib/dpkg/status - open (2: Aucun fichier ou dossier de ce type)
E: Les listes de paquets ou le fichier d’état ne peuvent pas être ouverts, ou sont incompréhensibles.

[/code]

#15

Les retours de [mono]mount[/mono] et [mono]parted/fdisk[/mono] seraient plus appropriés.

#16

Si /tmp est un tmpfs volatil par nature, ce n’est pas en regardant dans /tmp depuis le système de dépannage que tu verras s’il était plein. Par contre on voit qu’il contient des fichiers récents, donc on peut supposer qu’il est utilisé comme répertoire réel et non comme simple point de montage pour un tmpfs. L’utilisation de tmpfs est définie dans /etc/default/tmpfs et/ou dans /etc/fstab.

Combien de temps ? Si suffisamment (> 10 secondes), est-ce qu’il répond en SSH ?

[quote=“kmchen”]Par contre le /var/log/boot qui me permtrait de savoir quels services sont lancés est vide.
Comment puis-je l’activer ?[/quote]
Il faut installer le paquet bootlogd.

Dans le chroot, il faut monter la partition correspondante sur /var (ou [mono]mount -a[/mono] pour monter tout ce qui est défini dans /etc/fstab)

Ça ne sert à rien, c’est /var/run qui manque, pas /run.

#17

[code]root@rescue:~# chroot /mnt/sda1
root@rescue:/# mount -a
warning: failed to read mtab
:049
root@rescue:/# dpkg -l bootlog*
Souhait=inconnU/Installé/suppRimé/Purgé/H=à garder
| État=Non/Installé/fichier-Config/dépaqUeté/échec-conFig/H=semi-installé/W=attend-traitement-déclenchements
|/ Err?=(aucune)/besoin Réinstallation (État,Err: majuscule=mauvais)
||/ Nom Version Architecture Description
++±=========================-=================-=================-=======================================================
un bootlogd (aucune description n’est disponible)
root@rescue:/# aptitude install bootlogd
[ ERR] Lecture des informations d’état
E: Impossible d’ouvrir le fichier verrou /var/lock/aptitude - open (2: Aucun fichier ou dossier de ce type)
Les NOUVEAUX paquets suivants vont être installés :
bootlogd
0 paquets mis à jour, 1 nouvellement installés, 0 à enlever et 168 non mis à jour.
Il est nécessaire de télécharger 55,0 ko d’archives. Après dépaquetage, 152 ko seront utilisés.
W: Impossible de verrouiller le fichier cache : cela est en général dû à une installation simultanée de paquets avec dpkg ou un autre outil comme APT. Ouverture en mode lecture seule : AUCUNE des modifications de l’état des paquets que vous pourrez faire ne sera conservée.
Prendre : 1 http://ftp.fr.debian.org/debian/ wheezy/main bootlogd amd64 2.88dsf-41+deb7u1 [55,0 kB]
55,0 ko téléchargés en 0s (192 ko/s)
Impossible d’écrire le journal, échec d’openpty()
(/dev/pts est-il monté ?)
Sélection du paquet bootlogd précédemment désélectionné.
(Lecture de la base de données… 63553 fichiers et répertoires déjà installés.)
Dépaquetage de bootlogd (à partir de …/bootlogd_2.88dsf-41+deb7u1_amd64.deb) …
Traitement des actions différées (« triggers ») pour « debian-security-support »…
Traitement des actions différées (« triggers ») pour « man-db »…
Impossible d’écrire le journal, échec d’openpty()
(/dev/pts est-il monté ?)
Paramétrage de bootlogd (2.88dsf-41+deb7u1) …
Installation de la nouvelle version du fichier de configuration /etc/init.d/bootlogd …
[ ERR] Lecture des informations d’état
E: Impossible d’ouvrir le fichier verrou /var/lock/aptitude - open (2: Aucun fichier ou dossier de ce type)

W: Impossible de verrouiller le fichier cache : cela est en général dû à une installation simultanée de paquets avec dpkg ou un autre outil comme APT. Ouverture en mode lecture seule : AUCUNE des modifications de l’état des paquets que vous pourrez faire ne sera conservée.
root@rescue:/# dpkg -l bootlog*
Souhait=inconnU/Installé/suppRimé/Purgé/H=à garder
| État=Non/Installé/fichier-Config/dépaqUeté/échec-conFig/H=semi-installé/W=attend-traitement-déclenchements
|/ Err?=(aucune)/besoin Réinstallation (État,Err: majuscule=mauvais)
||/ Nom Version Architecture Description
++±=========================-=================-=================-=======================================================
ii bootlogd 2.88dsf-41+deb7u1 amd64 daemon to log boot messages
[/code]
Apparemment le fait de ne pouvoir verrouiller le cache n’empêche pas l’install

Autre soucis:

[code]root@rescue:/# aptitude install sysv-rc-conf
[ ERR] Lecture des informations d’état
E: Impossible d’ouvrir le fichier verrou /var/lock/aptitude - open (2: Aucun fichier ou dossier de ce type)
Les NOUVEAUX paquets suivants vont être installés :
libcurses-perl{a} libcurses-ui-perl{a} libterm-readkey-perl{a} sysv-rc-conf
Les paquets suivants seront mis à jour :
libcompress-raw-zlib-perl perl perl-base{b} perl-modules{b}
4 paquets mis à jour, 4 nouvellement installés, 0 à enlever et 164 non mis à jour.
Il est nécessaire de télécharger 414 ko/9 843 ko d’archives. Après dépaquetage, 2 959 ko seront libérés.
Les paquets suivants ont des dépendances non satisfaites :
libtext-charwidth-perl : Dépend: perlapi-5.10.0 qui est un paquet virtuel
libnet-ssleay-perl : Dépend: perlapi-5.10.1 qui est un paquet virtuel
libcrypt-openssl-rsa-perl : Dépend: perlapi-5.10.0 qui est un paquet virtuel
libperl-dev : Dépend: perl (= 5.10.1-17squeeze6) mais 5.14.2-21+deb7u2 doit être installé.
libdigest-sha1-perl : Dépend: perlapi-5.10.1 qui est un paquet virtuel
libnet-dns-perl : Dépend: perlapi-5.10.1 qui est un paquet virtuel
libhtml-parser-perl : Dépend: perlapi-5.10.1 qui est un paquet virtuel
libdbi-perl : Dépend: perlapi-5.10.1 qui est un paquet virtuel
liblocale-gettext-perl : Pré-Dépend: perlapi-5.10.0 qui est un paquet virtuel
libalgorithm-diff-xs-perl : Dépend: perlapi-5.10.1 qui est un paquet virtuel
perl-base : Est en conflit avec: defoma (< 0.11.12) mais 0.11.11 est installé.
libsnmp-perl : Dépend: perlapi-5.10.1 qui est un paquet virtuel
perl-modules : Est en conflit avec: defoma (< 0.11.12) mais 0.11.11 est installé.
librrds-perl : Dépend: perlapi-5.10.1 qui est un paquet virtuel
libbsd-resource-perl : Dépend: perlapi-5.10.1 qui est un paquet virtuel
libdbd-mysql-perl : Dépend: perlapi-5.10.1 qui est un paquet virtuel
libapache2-mod-perl2 : Dépend: perlapi-5.10.1 qui est un paquet virtuel
libfont-freetype-perl : Dépend: perlapi-5.10.0 qui est un paquet virtuel
libperl5.10 : Dépend: perl-base (= 5.10.1-17squeeze6) mais 5.14.2-21+deb7u2 doit être installé.
libsocket6-perl : Dépend: perlapi-5.10.1 qui est un paquet virtuel
libtext-iconv-perl : Dépend: perlapi-5.10.0 qui est un paquet virtuel
libconvert-uulib-perl : Dépend: perlapi-5.10.0 qui est un paquet virtuel
libberkeleydb-perl : Dépend: perlapi-5.10.1 qui est un paquet virtuel
libnetaddr-ip-perl : Dépend: perlapi-5.10.1 qui est un paquet virtuel
libnet-libidn-perl : Dépend: perlapi-5.10.1 qui est un paquet virtuel
libunix-syslog-perl : Dépend: perlapi-5.10.0 qui est un paquet virtuel
libcrypt-openssl-bignum-perl : Dépend: perlapi-5.10.0 qui est un paquet virtuel
libbit-vector-perl : Dépend: perlapi-5.10.1 qui est un paquet virtuel
ouverts : 514 ; fermés : 760 ; reportés : 22 ; en conflit : 27 OLes actions suivantes permettront de résoudre ces dépendances :

 Supprimer les paquets suivants :                           

  1. libcompress-raw-zlib-perl

    Conserver les paquets suivants dans leur version actuelle :

  2. libcurses-perl [Non installé]                            

  3. libcurses-ui-perl [Non installé]                         

  4. libterm-readkey-perl [Non installé]                      

  5. perl [5.10.1-17squeeze6 (now, oldstable)]                

  6. perl-base [5.10.1-17squeeze6 (now, oldstable)]           

  7. perl-modules [5.10.1-17squeeze6 (now, oldstable)]        

  8. sysv-rc-conf [Non installé]

[/code]

#18

/etc/mtab est désormais un lien symbolique qui pointe vers /proc/mounts.

/var/lock est un lien symbolique qui pointe vers /run/lock, qui est un tmpfs. /run est aussi un tmpfs.
Pour avoir un chroot fonctionnel, il faut (re)monter en bind plusieurs répertoires virtuels spéciaux :
/proc
/dev
/sys
/run

[quote=“kmchen”]5) perl [5.10.1-17squeeze6 (now, oldstable)]
6) perl-base [5.10.1-17squeeze6 (now, oldstable)]
7) perl-modules [5.10.1-17squeeze6 (now, oldstable)][/quote]
Apparemment la mise à niveau vers Wheezy n’est pas complète, il reste des paquets de Squeeze. As-tu fait un dist-upgrade ou full-upgrade ?

#19

C’est bien ce que je disais.

Tes partitions montées, la suite …

[code]# mount -B /dev /mnt/dev

mount -B /dev/shm /mnt/dev/shm

mount -B /dev/pts /mnt/dev/pts

mount -B /sys /mnt/sys

mount -B /run /mnt/run

mount -t proc /proc /mnt/proc

chroot /mnt/[/code]

#20

Pour le souci de /var, tu as eu quelques soucis de ce genre qui me font penser que /var est sur une partition séparée et non montée, est ce le cas?