Discussion :

[Tisiph0n3]

Bonjour bonjour, hier matin alors que j'allais me loguer en ssh sur mon dédié pour continuer la sécurisation Ô combien passionnante des vhosts de mon indien j'ai constaté qu'après avoir rentré mon mot de passe rien ne se passait, alors j'ai voulu m'y connecter en ftp, comme ça juste pour voir, serveur joignable mais aucune écoute de la part du serveur ftp sur le port.

Donc j'ai tenté le http en allant sur un de mes vhosts, timeout.

Du coup j'ai du refaire un reboot matériel, je vais jeter un oeil dans le syslog pour connaitre la cause de ce bordel, et je trouve ça:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
Jul 15 18:10:38 ks3002204 kernel: INFO: rcu_sched detected stall on CPU 1 (t=13749425 jiffies)
Jul 15 18:10:38 ks3002204 kernel: Pid: 4027, comm: ps Tainted: G      D      3.2.13-grsec-xxxx-grs-ipv6-64 #1
Jul 15 18:10:38 ks3002204 kernel: Call Trace:
Jul 15 18:10:38 ks3002204 kernel: <IRQ>  [<ffffffff810dc589>] __rcu_pending+0x159/0x410
Jul 15 18:10:38 ks3002204 kernel: [<ffffffff810dc89f>] rcu_check_callbacks+0x5f/0x120
Jul 15 18:10:38 ks3002204 kernel: [<ffffffff810983a1>] update_process_times+0x41/0x80
Jul 15 18:10:38 ks3002204 kernel: [<ffffffff810b93d6>] tick_sched_timer+0x66/0xb0
Jul 15 18:10:38 ks3002204 kernel: [<ffffffff810ad120>] __run_hrtimer+0x40/0xe0
Jul 15 18:10:38 ks3002204 kernel: [<ffffffff810ad3ed>] hrtimer_interrupt+0xcd/0x1f0
Jul 15 18:10:38 ks3002204 kernel: [<ffffffff8105e9f4>] smp_apic_timer_interrupt+0x64/0xa0
Jul 15 18:10:38 ks3002204 kernel: [<ffffffff81b4d088>] apic_timer_interrupt+0x68/0x70
Jul 15 18:10:38 ks3002204 kernel: <EOI>  [<ffffffff81133ed0>] ? put_filp+0x50/0x50
Jul 15 18:10:38 ks3002204 kernel: [<ffffffff81152165>] ? mntput_no_expire+0x45/0x160
Jul 15 18:10:38 ks3002204 kernel: [<ffffffff8114b080>] ? dput+0x40/0x300
Jul 15 18:10:38 ks3002204 kernel: [<ffffffff8115229a>] mntput+0x1a/0x30
Jul 15 18:10:38 ks3002204 kernel: [<ffffffff81134067>] fput+0x157/0x1f0
Jul 15 18:10:38 ks3002204 kernel: [<ffffffff81087e14>] removed_exe_file_vma+0x34/0x50
Jul 15 18:10:38 ks3002204 kernel: [<ffffffff8110cb78>] remove_vma+0x78/0x80
Jul 15 18:10:38 ks3002204 kernel: [<ffffffff8110cc83>] exit_mmap+0x103/0x120
Jul 15 18:10:38 ks3002204 kernel: [<ffffffff81087ecf>] mmput+0x3f/0xe0
Jul 15 18:10:38 ks3002204 kernel: [<ffffffff8108c8c7>] exit_mm+0x117/0x140
Jul 15 18:10:38 ks3002204 kernel: [<ffffffff8108e9cc>] do_exit+0x6fc/0x890
Jul 15 18:10:38 ks3002204 kernel: [<ffffffff810ae8d5>] ? up+0x35/0x50
Jul 15 18:10:38 ks3002204 kernel: [<ffffffff8108eba3>] do_group_exit+0x43/0xb0
Jul 15 18:10:38 ks3002204 kernel: [<ffffffff81044c81>] oops_end+0xe1/0xf0
Jul 15 18:10:38 ks3002204 kernel: [<ffffffff81044da6>] die+0x56/0x90
Jul 15 18:10:38 ks3002204 kernel: [<ffffffff81042a68>] do_general_protection+0x158/0x160
Jul 15 18:10:38 ks3002204 kernel: [<ffffffff81b4c28f>] general_protection+0x1f/0x30
Jul 15 18:10:38 ks3002204 kernel: [<ffffffff8114f501>] ? alloc_fd+0x41/0x140
Jul 15 18:10:38 ks3002204 kernel: [<ffffffff8113e94c>] ? link_path_walk+0x8c/0x920
Jul 15 18:10:38 ks3002204 kernel: [<ffffffff81126469>] ? kmem_cache_alloc+0x69/0xa0
Jul 15 18:10:38 ks3002204 kernel: [<ffffffff8113f5dd>] ? path_init+0x30d/0x3a0
Jul 15 18:10:38 ks3002204 kernel: [<ffffffff81142a35>] path_openat+0xb5/0x450
Jul 15 18:10:38 ks3002204 kernel: [<ffffffff81142ee3>] do_filp_open+0x43/0xa0
Jul 15 18:10:38 ks3002204 kernel: [<ffffffff8114f324>] ? expand_files+0x44/0x1e0
Jul 15 18:10:38 ks3002204 kernel: [<ffffffff8114f50a>] ? alloc_fd+0x4a/0x140
Jul 15 18:10:38 ks3002204 kernel: [<ffffffff81130612>] do_sys_open+0x152/0x1f0
Jul 15 18:10:38 ks3002204 kernel: [<ffffffff81130298>] ? filp_close+0x68/0xa0
Jul 15 18:10:38 ks3002204 kernel: [<ffffffff811306db>] sys_open+0x1b/0x20
Jul 15 18:10:38 ks3002204 kernel: [<ffffffff81b4c6b6>] system_call_fastpath+0x18/0x1d

Le syslog en était rempli à raz bord depuis 6h du mat, toujours les mêmes messages, donc apparemment un cpu stall c'est quand un programme part en latte, qui lui même fait partir le kernel en latte qui lui même bloque le cpu (à ce que j'ai compris), et partout sur l'interwebz je n'ai vu ce terme que dans sur des forums où ça cause virtualisation, c'est là que ça bloque parce que moi je ne virtualise pas sur mon dédé, mais j'ai lu aussi, que ce serait probablement dû à un problème matériel.

Donc ma question première est qu'est ce que c'est? D'où ça vient? (même si je pense le savoir j'aimerais qu'on me le confirme)

La deuxième, comment éviter que mon serveur me poignarde a nouveau lâchement dans le dos pendant mon sommeil?

Merci d'avance

[frp31]

soit ton dédié est une VM chez l’hébergeur soit il merde au niveau virtualisation matériel, (et là il faut désactiver tout ce qui est paramétré pour la virtualisation au niveau bios voire même l'hyperthreading)
certains processeurs VM ready posent problèmes si on virtualise rien ....

[Katyucha]

certains processeurs VM ready posent problèmes si on virtualise rien ....

Ah oui ? jamais vu ca... Tu as eu le souci ? je le note dans un coin

[Tisiph0n3]

soit ton dédié est une VM chez l’hébergeur soit il merde au niveau virtualisation matériel, (et là il faut désactiver tout ce qui est paramétré pour la virtualisation au niveau bios voire même l'hyperthreading)
certains processeurs VM ready posent problèmes si on virtualise rien ....

Merci pour ta réponse, non c'est pas une VM j'espère bien d'ailleurs, j'ai pris un kimsufi 2g chez ovh.

Qu'entends tu par vm ready? Support de la virtualisation matérielle?
Si c'est ça le proc ne la supporte pas.
Quand au BIOS je n'y ai pas accès

J'ai viré l'install actuelle du serveur pour la remplacer par une debian pour plus de stabilité, je verrais bien ce que ça donne.