Problème jeedom sur debian 9 proxmox en kvm : bloqué et utilisation cpu constante anormale

[dgonneau]

Bonjour,

Migré depuis peu de ma raspberry pi3 sur une VM debian 9 en kvm sur proxmox 5.1, j'ai eut à deux reprises un jeedom dans les choux, qui ne répondait plus.
L'utilisation cpu de la machine virtuelle était à chaque fois dans les 50% (56 dernière fois) et seul un reset de la vm permet de récupérer jeedom.
J'essai de trouver ce qui pourrait se passer, mais si quelqu'un à déjà eut le souci ou si on pouvait m'aider au diag du problème je serais reconnaissant



Si je ne trouve pas, j'envisage de rétrograder sur une debian 8 ou de réutiliser mon conteneur lxc (ce qui me forcerait à déporter mon antenne bluetooth, sur un raspberry ou éventuellement sur une vm kvm dédiée uniquement à cela ...).

[Nibb31]

J'ai eu le même problème en Debian 9 sur Proxmox. J'ai plein d'autres VM Debian 9 qui marchent parfaitement, il n'y a que pour Jeedom que ça fait ça.

Ca fonctionne parfaitement en Debian 8, alors j'y reste.

[Bosquetia]

Hello,

Je suis en Debian 9.2.1 en VM sur ESXi 6.5 last update, Jeedom 3.1.7 et je n'ai aucun souci...

Pouvez-vous nous donner la version précise de Debian car 9 est vague il y a peut être un bug mis en évidence juste avec debian + promoxx + jeedom

Donc il nous faudrait un maximum de détails sur les versions et peut être aussi les plugins installés !

[Anonyme]

Contenu supprimé à la demande de son auteur

[dgonneau]

Hello,
Je suis en Debian 9.2.1 en VM sur ESXi 6.5 last update, Jeedom 3.1.7 et je n'ai aucun souci...
Pouvez-vous nous donner la version précise de Debian car 9 est vague il y a peut être un bug mis en évidence juste avec debian + promoxx + jeedom
Donc il nous faudrait un maximum de détails sur les versions et peut être aussi les plugins installés !

J'ai envisagé de passer sur ESXi justement, mon aventure proxmox est assez récente
Comme c'est tout frais, je suis en 9.2.1 aussi, proxmox toute dernière version (5.1-722cc488-1).
Version jeedom 3.1.7.
Liste des plugins :

Code : Tout sélectionner

default / core : jeedom	3.1.7
market / plugin : alarm	2017-11-18 01:04:24
market / plugin : blea	2017-09-26 11:51:07
market / plugin : broadlink	2017-10-12 01:02:10
market / plugin : camera	2017-10-05 01:04:18
market / plugin : clink	2017-09-29 13:42:50
market / plugin : dashbutton	2017-10-04 01:02:22
market / plugin : dayinfo	2017-11-18 01:03:13
market / plugin : espeasy	2017-09-28 01:04:10
market / plugin : geoloc	2017-09-29 13:41:56
market / plugin : geotrav	2017-11-17 01:02:45
market / plugin : groupe	2017-09-27 20:44:03
market / plugin : heliotrope	2017-11-15 01:01:32
market / plugin : jeelink	2017-10-04 01:00:25
market / plugin : JeeOrangeTv	2017-10-01 14:55:20
market / plugin : JPI	2017-11-04 01:02:22
market / plugin : mail	2017-09-30 10:43:35
market / plugin : mode	2017-11-21 01:03:30
market / plugin : Monitoring	2017-10-03 01:01:59
market / plugin : netatmoThermostat	2017-10-20 01:00:55
market / plugin : networks	2017-09-26 11:46:41
market / plugin : openzwave	2017-09-26 11:52:12
market / plugin : phonemarket	2017-09-29 13:35:36
market / plugin : ping	2017-11-02 21:47:12
market / plugin : playtts	2017-09-28 01:02:27
market / plugin : rflink	2017-11-10 01:03:38
market / plugin : rosee	2017-09-17 01:01:41
market / plugin : RTSP	2017-10-12 10:07:12
market / plugin : salat	2017-09-28 01:03:36
market / plugin : script	2017-10-04 01:03:18
market / plugin : sms	2017-09-26 11:47:07
market / plugin : speedtest	2017-09-15 15:02:44
market / plugin : squeezeboxcontrol	2017-09-26 11:49:27
market / plugin : sshcommander	2017-09-28 01:03:55
market / plugin : telegram	2017-10-18 01:00:44
market / plugin : ttsWebServer	2017-08-13 17:18:56
market / plugin : vigilancemeteo	2017-11-15 01:01:42
market / plugin : virtual	2017-09-26 16:08:26
market / plugin : weather	2017-09-26 11:48:48
market / plugin : widget	2017-10-17 01:02:53
market / plugin : xiaomihome	2017-11-21 01:04:36

Ce n’est pas Jeedom le souci, mais plutôt un paquet système utilisé par Jeedom (et pas sur tes autres VMs).

Comment j'identifie le coupable ?

J'ai eu le même problème en Debian 9 sur Proxmox. J'ai plein d'autres VM Debian 9 qui marchent parfaitement, il n'y a que pour Jeedom que ça fait ça.
Ca fonctionne parfaitement en Debian 8, alors j'y reste.

Ok, bon à savoir, mais d'un autre côté pour la communauté je pense que ca serait bien de trouver ce qui cloche.

[Nibb31]

Je suis en Debian 9.2.1 en VM sur ESXi 6.5 last update, Jeedom 3.1.7 et je n'ai aucun souci...

Pouvez-vous nous donner la version précise de Debian car 9 est vague il y a peut être un bug mis en évidence juste avec debian + promoxx + jeedom

Je pense que c'est un problème spécifique à KVM/Proxmox. C'était une install propre de la dernière version de Debian 9, avec dist-upgrade et dernier kernel et dernier Jeedom.

Ce n’est pas Jeedom le souci, mais plutôt un paquet système utilisé par Jeedom (et pas sur tes autres VMs).

Probablement, mais alors lequel ? J'ai plein d'autres VMs Debian 9 avec du PHP et du MySQL, alors peut-être que c'est du coté des dépendances Zwave, BLEA, ou autres. Ca peut aussi être un problème entre Debian 9 et le passthrough USB de KVM.

C'était difficile à diagnostiquer, parce que la VM ne répondait plus quand ça arrivait, et il n'y avait rien de particulier dans les logs Jeedom, Proxmox ou système. C'est pour ça que j'ai abandonné et que je suis revenu à Debian 8.

[Anonyme]

Contenu supprimé à la demande de son auteur

[Nibb31]

Toutes mes autres VM Debian 9 lisent et écrivent sur des partages SMB, alors ça ne doit pas être ça.

Bien sûr, toutes les VM étaient à jour avec dist-upgrade et dernier kernel.

[bbreton]

Que dit un htop pendant ce pique de charge ?

As tu une clé bluetooth connecté a cette VM ?

[dgonneau]

Que dit un htop pendant ce pique de charge ?
As tu une clé bluetooth connecté a cette VM ?

htop en ssh sur proxmox ou sur la VM ? parceque lorsqu'il y a le pic de cpu, la VM ne répond plus à quoique ce soit. ssh, ping ... zero, nada (enfin faudrait que je vérifie pour le ping)

J'ai bien une clé bluetooth, c'est pour cela que j'avais utilisé une VM au lieu d'un conteneur.

[bbreton]

Ok donc déjà pour tester peux tu déconnecter ta clé bluetooth quelque temps et me dire si c'est stable ?
J'ai eu le meme cas et ca venais de la clé. Problème de pilote entre Debian 9/Bluetooth et virtualisation (Crash sur ESXi et Proxomox) par contre je n'ayant pas d'autre modèle de clé j'ai simplement déporté le bluetooth sur un PI.

[Nibb31]

.

[Nibb31]

Que dit un htop pendant ce pique de charge ?

Chez moi, le pic de charge rendait la machine non-responsive. Impossible de se logguer ou faire quoi que ce soit. On voyait juste le CPU de la VM qui grimpait en flèche.

Oui, clé BT avec le plugin BLEA et toutes les dépendances (bluez etc...). C'était mon premier suspect, mais à l'époque j'ai préféré repasser Debian 8 plutôt que de chercher plus loin.

[dgonneau]

Ok donc déjà pour tester peux tu déconnecter ta clé bluetooth quelque temps et me dire si c'est stable ?
J'ai eu le meme cas et ca venais de la clé. Problème de pilote entre Debian 9/Bluetooth et virtualisation (Crash sur ESXi et Proxmox) par contre je n'ayant pas d'autre modèle de clé j'ai simplement déporté le bluetooth sur un PI.

Je vais essayer en effet sans la clé bluetooth.
Si c'est cela, je fais un nouveau jeedom avec QUE la clé bluetooth. Si ca plante je serais fixé
Après faudrait investiguer s'il y a un bug connu de passthrough bluetooth sur proxmox debian 9.

[fwehrle]

J’ai eu exactement les mêmes symptômes sur proxmox 5 avec une debian 9.0 en kvm upgradée en 9.2. Avec 3 passtrhough usb (ble, rfx et zwave).
Elle tournait depuis des semaines, et s’est mise à friser toutes les 24h juste après que j’y ai installé et restauré mon jeedom.
J’ai recréé une vm avec la dernière iso de debian 9.1 ou 2 (je sais plus, mais même version que la 9.0 upgradee), réinstalle jeedom. Et depuis, tout roule.
Je n’ai jamais trouvé d’où ça venait.

[fwehrle]

J’ai utilisé l’iso suivante, si ça peut aider : debian-9.2.1-amd64-netinst.iso

[dgonneau]

J’ai utilisé l’iso suivante, si ça peut aider : debian-9.2.1-amd64-netinst.iso

C'est l'iso que j'ai utilisé sur toutes mes VM.

Hier soir j'ai scindé ma config en 2 VMs :

• une VM sans blutooth
• une VM avec que bluetooth

Bingo, la VM qui n'a que le plugin bluetooth est plantée (elle répond au ping, mais impossible de s'y connecter en ssh), l'autre tourne nickel (pour le moment) :

jeedom sur debian9 avec bluetooth uniquement :


jeedom sur debian9 avec TOUT sauf bluetooth :

[dgonneau]

Que dit un htop pendant ce pique de charge ?
As tu une clé bluetooth connecté a cette VM ?

htop en ssh sur proxmox ou sur la VM ? parceque lorsqu'il y a le pic de cpu, la VM ne répond plus à quoique ce soit. ssh, ping ... zero, nada (enfin faudrait que je vérifie pour le ping)

J'ai bien une clé bluetooth, c'est pour cela que j'avais utilisé une VM au lieu d'un conteneur.

htop sur le serveur proxmox pendant que la vm 104 est plantée :



On voit clairement qu'un des core est à 100%

[dgonneau]

un essai de récupérer des infos avec gdb sur le process de la kvm plantée :

Code : Tout sélectionner

root@proxmox:~# gdb
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) attach 9565
Attaching to process 9565
[New LWP 9566]
[New LWP 9599]
[New LWP 9600]
[New LWP 9601]
[New LWP 9602]
[New LWP 9604]
[New LWP 9605]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x00007fef4fe57771 in __GI_ppoll (fds=0x7feefb6d6a00, nfds=13, timeout=<optimized out>, sigmask=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:39
39      ../sysdeps/unix/sysv/linux/ppoll.c: No such file or directory.
(gdb) info threads
  Id   Target Id         Frame
* 1    Thread 0x7fef68287fc0 (LWP 9565) "kvm" 0x00007fef4fe57771 in __GI_ppoll (fds=0x7feefb6d6a00, nfds=13, timeout=<optimized out>, sigmask=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:39
  2    Thread 0x7fef443ff700 (LWP 9566) "kvm" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  3    Thread 0x7fef433fd700 (LWP 9599) "kvm" 0x00007fef4fe58e07 in ioctl () at ../sysdeps/unix/syscall-template.S:84
  4    Thread 0x7fef423ff700 (LWP 9600) "kvm" 0x00007fef4fe58e07 in ioctl () at ../sysdeps/unix/syscall-template.S:84
  5    Thread 0x7fef413ff700 (LWP 9601) "kvm" 0x00007fef4fe58e07 in ioctl () at ../sysdeps/unix/syscall-template.S:84
  6    Thread 0x7fef403ff700 (LWP 9602) "kvm" 0x00007fef4fe58e07 in ioctl () at ../sysdeps/unix/syscall-template.S:84
  7    Thread 0x7feefb3ff700 (LWP 9604) "kvm" 0x00007fef4fe576ad in poll () at ../sysdeps/unix/syscall-template.S:84
  8    Thread 0x7feef97ff700 (LWP 9605) "kvm" pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
(gdb)

ca me parle pas ... et je me demande si c'est gdb qui plante ou qui m'indique un plantage
je vois des personnes parler d'un backtrace pour investiguer sur un crash...
Ma VM s'est arrêtée toute seule suite aux tests que je lui soumettais , donc pour l'instant c'est reparti tout frais. Je retente au prochain plantage...

[fwehrle]

Oh mince. Tu viens de me rappeler que lors de mes tests, j'ai effectivement désactivé le plugin blea. Et je ne l'ai pas réactivé depuis. Peut-être une piste.

Edit : et j'ai un pote qui vient de me remonter exactement le même problème, et il en est arrivé à la même conclusion.
C'est le bluetooth le coupable... Mais seulement quand le plugin BLEA est actif.
Reste à comprendre pourquoi et comment...