(Très) mauvaise surprise suite MAJ DSM 6.1-15047

[lndiana]

Bonjour,

 

Après plusieurs jours de recherche, je créé un nouveau sujet ici, n'ayant rien trouvé de probant à mon problème.

J'ai un DS415+ modifié avec 8Go de RAM, et sur lequel je fais tourner, entre autres, le package LMS, et plusieurs containers docker (jeedom sur debian, sab, unifi controller, traccar, etc..)

Ca fait maintenant 10 jours que mon container jeedom (solution domotique php + cron + apache2 et ssh) , qui tourne impac depuis plusieurs mois, freeze au bout de 5 à 10h de fonctionnement (plus accessible via http, ssh ou interface docker).
A ce moment précis, j'ai un grand nombre de process cron et apache2 qui ne font rien mais prennent de la RAM dans le container, et je ne peux ni arrêter le container docker, ni même arrêter le service docker. Le plus étrange, c'est que les autres container (sab, unifi controller, traccar..) fonctionnent encore.

Mais le NAS prend de plus en plus de RAM, sans explication, et quelques minutes plus tard, fini par freezer complètement. Lumière bleue allumée, mais obligé de hard rebooter par appui long sur le bouton d'alim.
J'ai l'impression que c'est depuis la MAJ DSM 6.1-15047, mais je ne suis pas sur...
J'ai allégé au max les traitement dans le container, et j'ai même recréé un container sur une image plus récente : pareil.
J'ai ouvert un ticket chez Syno, testé la mémoire, j'attend qu'ils prennent la main pour voir..
Et depuis hier, je test en ayant arrété le container jeedom et ca à l'air de tenir...
Je penche donc vers un problème dans le container jeddom qui ferait planter docker, et tout le syno..  Mais je n'ai à priori rien changé dans le container depuis la MAJ du DSM..

Le container tourne avec une élévation de privilège (j'ai besoin d'accéder aux ports USB via le package de Jadhal UsbSerial), et j'ai essayer de limiter le ressource, sans succès.
Si des spécialistes auraient une piste, je désespère... :(

Si vous avez besoin de plus d'infos, n'hésitez pas...

Merci d'avance..

Un historique de ce qui s'est passé (avec chaque reboot suite à plantage)

2017/03/18 08:47:07 : System started counting down to reboot. (suite MAJ DSM 6.1-15047)
2017/03/18 08:47:04 : Update was complete.
2017/03/18 08:53:04 : Package Docker successfully repaired
2017/03/18 09:20:53 : Download task DSM 6.1-15047 Update 1 finished
2017/03/18 09:23:59 : UsbSerial Installed
2017/03/18 09:25:39 : Update was complete.
2017/03/18 09:31:00 : System started counting down to reboot.
2017/03/21 07:40:46 : System booted up from an improper shutdown.
2017/03/21 22:27:05 : Erreur arret container jeedomPROD
2017/03/21 23:04:25 : System booted up from an improper shutdown.
2017/03/22 06:18:31 : System booted up from an improper shutdown.
2017/03/22 18:28:34 : System booted up from an improper shutdown.
2017/03/22 : SQL Too Many connections ??
2017/03/23 07:07:51 : System booted up from an improper shutdown.
2017/03/24 08:59:07 : Download task for [DSM 6.1-15047 Update 2] finished.
2017/03/24 09:00:46 : Update was complete.
2017/03/24 09:00:53 : System started counting down to reboot.
2017/03/25 11:17:30 : System booted up from an improper shutdown.
2017/03/25 13:21:05 : System booted up from an improper shutdown.
2017/03/26 21:23:53 : System booted up from an improper shutdown.
2017/03/27 07:17:08 : System booted up from an improper shutdown.

Et des choses pas sympa dans les logs system du syno : 

2017-03-26T19:16:03+02:00 SuperBoite kernel: [104293.927922] BUG: soft lockup - CPU#2 stuck for 41s! [php:12964]
2017-03-26T19:16:03+02:00 SuperBoite kernel: [104294.094593] CPU: 2 PID: 12964 Comm: php Tainted: P           O 3.10.102 #15047
2017-03-26T19:16:03+02:00 SuperBoite kernel: [104294.102784] Hardware name: Insyde MohonPeak/Type2 - Board Product Name1, BIOS M.011 2014/12/23
2017-03-26T19:16:03+02:00 SuperBoite kernel: [104294.112524] task: ffff8801a041b160 ti: ffff88003867c000 task.ti: ffff88003867c000
2017-03-26T19:16:03+02:00 SuperBoite kernel: [104294.120997] RIP: 0010:[<ffffffff81116de8>]  [<ffffffff81116de8>] file_update_time+0x8/0xd0
2017-03-26T19:16:03+02:00 SuperBoite kernel: [104294.130367] RSP: 0018:ffff88003867f880  EFLAGS: 00000246
2017-03-26T19:16:03+02:00 SuperBoite kernel: [104294.136413] RAX: 0000000000000000 RBX: 0000000000000008 RCX: 0000000005733820
2017-03-26T19:16:03+02:00 SuperBoite kernel: [104294.144506] RDX: 7ffffffffa8cc7e7 RSI: ffff88003867f800 RDI: ffff880135f51380
2017-03-26T19:16:03+02:00 SuperBoite kernel: [104294.152589] RBP: ffff88003867f890 R08: 0000000000000008 R09: 0000000000000001
2017-03-26T19:16:03+02:00 SuperBoite kernel: [104294.160681] R10: 0000000000000008 R11: fffffffffffffffc R12: ffff880135f51380
2017-03-26T19:16:03+02:00 SuperBoite kernel: [104294.168773] R13: ffff880135f51380 R14: ffffffff810b0f1f R15: 8000000000000018
2017-03-26T19:16:03+02:00 SuperBoite kernel: [104294.176866] FS:  00007f034d31e740(0000) GS:ffff88027fc80000(0000) knlGS:0000000000000000
2017-03-26T19:16:03+02:00 SuperBoite kernel: [104294.186021] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
2017-03-26T19:16:03+02:00 SuperBoite kernel: [104294.192555] CR2: 00007fb318e0f018 CR3: 0000000135f60000 CR4: 00000000001007e0
2017-03-26T19:16:03+02:00 SuperBoite kernel: [104294.200638] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
2017-03-26T19:16:03+02:00 SuperBoite kernel: [104294.208730] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
2017-03-26T19:16:03+02:00 SuperBoite kernel: [104294.216820] Stack:
2017-03-26T19:16:03+02:00 SuperBoite kernel: [104294.219164]  0000000005733818 ffff88003867f950 ffff880135f51380 ffffffff810b2513
2017-03-26T19:16:03+02:00 SuperBoite kernel: [104294.227569]  0000000000000000 ffff88003867f988 0000000000000008 ffff8801d58cbcf0
2017-03-26T19:16:03+02:00 SuperBoite kernel: [104294.235972]  0000000000000001 0000000000000008 ffff88003867f950 ffff8801d58cbcf0
2017-03-26T19:16:03+02:00 SuperBoite kernel: [104294.244373] Call Trace:
2017-03-26T19:16:03+02:00 SuperBoite kernel: [104294.247202]  [<ffffffff810b2513>] ? __generic_file_aio_write+0x1f3/0x400
2017-03-26T19:16:03+02:00 SuperBoite kernel: [104294.254809]  [<ffffffff810b2775>] ? generic_file_aio_write+0x55/0xc0
2017-03-26T19:16:03+02:00 SuperBoite kernel: [104294.262027]  [<ffffffff810f5ee0>] ? do_sync_read+0xa0/0xa0
2017-03-26T19:16:03+02:00 SuperBoite kernel: [104294.268270]  [<ffffffff810f5f49>] ? do_sync_write+0x69/0xa0
2017-03-26T19:16:03+02:00 SuperBoite kernel: [104294.274619]  [<ffffffffa0d06ec2>] ? do_xino_fwrite+0x52/0x80 [aufs]
2017-03-26T19:16:03+02:00 SuperBoite kernel: [104294.281744]  [<ffffffffa0d0738d>] ? xino_fwrite+0x6d/0x80 [aufs]
2017-03-26T19:16:03+02:00 SuperBoite kernel: [104294.288576]  [<ffffffffa0d073db>] ? au_xino_do_write+0x3b/0x100 [aufs]
2017-03-26T19:16:03+02:00 SuperBoite kernel: [104294.295992]  [<ffffffffa0d07eef>] ? au_xino_write+0x4f/0xe0 [aufs]
2017-03-26T19:16:03+02:00 SuperBoite kernel: [104294.303021]  [<ffffffffa0d18e4d>] ? au_set_h_iptr+0xbd/0x150 [aufs]
2017-03-26T19:16:03+02:00 SuperBoite kernel: [104294.310136]  [<ffffffffa0d19d64>] ? au_new_inode+0x514/0x710 [aufs]
2017-03-26T19:16:03+02:00 SuperBoite kernel: [104294.317259]  [<ffffffff8110a38b>] ? vfs_create+0x25b/0x3e0
2017-03-26T19:16:03+02:00 SuperBoite kernel: [104294.323506]  [<ffffffffa0d1c00d>] ? epilog+0x10d/0x1a0 [aufs]
2017-03-26T19:16:03+02:00 SuperBoite kernel: [104294.330045]  [<ffffffffa0d0bddc>] ? vfsub_create+0x9c/0xd0 [aufs]
2017-03-26T19:16:03+02:00 SuperBoite kernel: [104294.336976]  [<ffffffffa0d1c482>] ? add_simple+0x1d2/0x2e0 [aufs]
2017-03-26T19:16:03+02:00 SuperBoite kernel: [104294.343906]  [<ffffffffa0d1a40b>] ? h_permission.isra.22+0x7b/0x120 [aufs]
2017-03-26T19:16:03+02:00 SuperBoite kernel: [104294.351711]  [<ffffffffa0d1c60f>] ? aufs_create+0x2f/0x40 [aufs]
2017-03-26T19:16:03+02:00 SuperBoite kernel: [104294.358542]  [<ffffffff8110a264>] ? vfs_create+0x134/0x3e0
2017-03-26T19:16:03+02:00 SuperBoite kernel: [104294.364792]  [<ffffffffa0d1a79f>] ? aufs_lookup+0x1af/0x200 [aufs]
2017-03-26T19:16:03+02:00 SuperBoite kernel: [104294.371815]  [<ffffffff8110b861>] ? do_last.isra.44+0x1351/0x1460
2017-03-26T19:16:03+02:00 SuperBoite kernel: [104294.378741]  [<ffffffff81104f6a>] ? link_path_walk+0x51a/0x1590
2017-03-26T19:16:03+02:00 SuperBoite kernel: [104294.385470]  [<ffffffff8110ba1f>] ? path_openat.isra.45+0xaf/0x4f0
2017-03-26T19:16:03+02:00 SuperBoite kernel: [104294.392492]  [<ffffffff8110cbe0>] ? do_filp_open+0x30/0x70
2017-03-26T19:16:03+02:00 SuperBoite kernel: [104294.398741]  [<ffffffffa0d1ad90>] ? aufs_permission+0x1d0/0x310 [aufs]
2017-03-26T19:16:03+02:00 SuperBoite kernel: [104294.406155]  [<ffffffff81111fd7>] ? prepend_path+0x97/0x1e0
2017-03-26T19:16:03+02:00 SuperBoite kernel: [104294.412496]  [<ffffffff81119740>] ? __alloc_fd+0x70/0x110
2017-03-26T19:16:03+02:00 SuperBoite kernel: [104294.418643]  [<ffffffff810f4312>] ? do_sys_open+0xe2/0x1c0
2017-03-26T19:16:03+02:00 SuperBoite kernel: [104294.424887]  [<ffffffff8149b332>] ? system_call_fastpath+0x16/0x1b
2017-03-26T19:16:03+02:00 SuperBoite kernel: [104294.431909] Code: 8c 4e ff ff ff 8b 73 60 39 b3 80 00 00 00 0f 89 3f ff ff ff eb a3 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 41 55 41 54 <53> 48 8d 64 24 f0 48 8b 5f 20 f6 43 0c 80 74 10 31 c0 48 8d 64 
2017-03-26T19:16:51+02:00 SuperBoite kernel: [104341.956235] BUG: soft lockup - CPU#2 stuck for 41s! [php:12964]
2017-03-26T19:16:51+02:00 SuperBoite kernel: [104342.122911] CPU: 2 PID: 12964 Comm: php Tainted: P           O 3.10.102 #15047
2017-03-26T19:16:51+02:00 SuperBoite kernel: [104342.131101] Hardware name: Insyde MohonPeak/Type2 - Board Product Name1, BIOS M.011 2014/12/23
2017-03-26T19:16:51+02:00 SuperBoite kernel: [104342.140841] task: ffff8801a041b160 ti: ffff88003867c000 task.ti: ffff88003867c000
2017-03-26T19:16:51+02:00 SuperBoite kernel: [104342.149324] RIP: 0010:[<ffffffff810f5efb>]  [<ffffffff810f5efb>] do_sync_write+0x1b/0xa0
2017-03-26T19:16:51+02:00 SuperBoite kernel: [104342.158499] RSP: 0018:ffff88003867f940  EFLAGS: 00010246
2017-03-26T19:16:51+02:00 SuperBoite kernel: [104342.164537] RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000014

[firlin]

Bonjour Indiana,

Moi je connais la réponse de synology, ce nas n'est pas prévu de fonctionner avec 8Go de Ram mais avec 2 Go

Modification du nas = perte de garantie, du moins pas de support dans le meilleur des cas.

Après je vois que Jeedoom suite à l maj du nas c'est pas éteint comme il faut,

Il te faut attendre les pros du Linux là

[lndiana]

Bonjour Firlin,

Bah, pour la ram, c'est pas la premiere fois que je dois négocier avec Syno pour leur expliquer que ca n'a rien a voir...

C'etait pareil avec IPKG il y a quelques années, ou les spk de repo divers.. En insistant un peu, et en leur expliquant que ca n'a rien a voir, ils prennent souvent en compte.. En tout cas, ils m'ont souvent écouté.

Si si, le NAS a toujours bien redémarré après chaque update.. Ca n'est que le 21 , soit 3j plus tard, qu'il a crashé la premiere fois.. (C'est d'ailleurs etrange, puisqu'apres, il a pas attendu aussi longtemps..

 

[Einsteinium]

Hum le docker mange trop de ram, et tu dis que la limitation est sans effet ? C'est pas normale, mon plex j'ai mis 4Go, il reste dans les clous, cela doit venir de l'élévation de privilège et à voir comment tu le décris un beau buffer overflow... certainement le résultat d'un update de paquet ou pluggin dans ton docker, et l'update du dsm ne doit non plus y être étranger...

[lndiana]

C'est exactement ce que je pense aussi. Je suis entrain d'essayer de désactiver les plugins au cure et à mesure pour essayer de voir quel plugin fait sauter le truc. Une récréation complete du container n'a rien changé. Je vais essayer une restauration de jeedom d'avant l'update de dsm.

Envoyé de mon Nexus 6P en utilisant Tapatalk

[PiwiLAbruti]

Il y a 21 heures, lndiana a dit :

[...] j'ai un un grand nombre de process cron et apache2 qui ne font rien mais prennent de la RAM dans le container, [...]

Commence déjà par tuer quelques processus parasites pour voir si l'occupation mémoire diminue.

Regarde si les scripts exécutés par cron se terminent bien (en les exécutant manuellement, hors cron). Je soupçonnerait plutôt une erreur à ce niveau qui fait que les script ne se terminent pas et occupent de l'espace en mémoire.

[lndiana]

il y a une heure, PiwiLAbruti a dit :

Commence déjà par tuer quelques processus parasites pour voir si l'occupation mémoire diminue.

Regarde si les scripts exécutés par cron se terminent bien (en les exécutant manuellement, hors cron). Je soupçonnerait plutôt une erreur à ce niveau qui fait que les script ne se terminent pas et occupent de l'espace en mémoire.

Ah oui, pas bête.. j'aime bien l'idée. 

Mais sur une solution domotique comme jeedom qui execute des crons pour chaque scénario (j'en ai 300) et chaque sous-scénario planifié, ca fait beaucoup... Impossible de savoir quel scénario fait planter le cron. 

Et en y réfléchissant, en surveillant les process du container sur une journée, ils n'ont pas augmenté progressivement (je n'ai pas eu un seul cron qui restait ouvert sur la journée), mais tout plein d'un seul coup.. juste après que l'occupation RAM du syno soit descendu d'un coup de 50% à 20. Et c'est la que ca a commencé à grimper (+ tache cron en idle) jusqu'au freeze du NAS.

Et pour ce qui est de tuer des processus parasite : chaque cron prend quelques ko... Il en faut un paquet pour saturer 8Go!

[PiwiLAbruti]

il y a 8 minutes, lndiana a dit :

Et pour ce qui est de tuer des processus parasite : chaque cron prend quelques ko... Il en faut un paquet pour saturer 8Go!

Si l'exécution de chaque script lancé par cron bloque et que les 300 scénarii sont exécutés à des intervalles courts, ça peut aller très vite.

Dans tous les cas, fais des tests individuels pour écarter mon hypothèse.

[lordtaki]

Si ce sont de vrais cronjobs il devrait y avoir une trace dans les logs système.

De plus, un cronjob ne va pas s'éxécuter avec le même environnement que quand on le teste en terminal.

 

Si ce sont des scripts planifiés/ordonnancés par jeedom, n'y a-t-il pas moyen de paramétrer la verbosité de l'application?

[lndiana]

il y a 5 minutes, PiwiLAbruti a dit :

Si l'exécution de chaque script lancé par cron bloque et que les 300 scénarii sont exécutés à des intervalles courts, ça peut aller très vite.

Dans tous les cas, fais des tests individuels pour écarter mon hypothèse.

Oui, c'est justement ce que je voulais dire : ca va tellement vite, que je me retrouve avec plein de process cron.

Comment je fais pour en killer assez, assez vite, pour que ca libère de la RAM?

Et en plus, ca ne s'arrete pas, et en quelques secondes, je n'ai plus de RAM...

Dans l'ordre : Le syno clear la RAM (why?), ca vide le cache de jeedom, ce qui fait merder chaque process cron. Ce qui blinde la RAM et fait planter le syno.

Et je n'ai pas moyen de savoir quel scenario fait merder le truc, mais de toute facon, a la vitesse ou ca va, je dirais que ce sont TOUS les crons qui merdent.. Et il y en a effectivement plusieurs à la minute... :(

 

Mais si on réfléchi, le plantage du syno car plus de mémoire n'est que la concéquence d'autre chose qui a fait merder le container. Mais quoi...

[PiwiLAbruti]

La commande killall permet de tuer un ensemble de processus similaires selon leur nom, statut, ...

Pour le reste je ne connais pas Jeedom.

[lndiana]

Ah ok.. Merci. Mais je kill ceux qui sont deja créé, ca n'empèche pas les suivants de continuer.. 

Et comme dis : ca n'est qu'un conséquence .. l'origine du problème n'est pas la. 

 

Modifié le 30 mars 2017 par Lucien77
Inutile de citer le post précédent

[lndiana]

Petite news : après m'avoir demandé les logs system, voici la réponse du support : 

Nickel donc.. :)

Je vous dirais ce qu'il en est après leur intervention.

Citation

Hi Frank,

The issue should be fixed in DSM 6.1.1 及 6.2 beta.

Meanwhile, you can 

1. change volume for docker package to btrfs

2. wait for the DSM update to DSM 6.1.1

3. offer us remote access so that we can replace aufs kernel module. (we would also restart docker and we would need to reboot the DS so please do not setup any power schedule/reboot/shutdown the DS when remote is open)

If this is an absolute emergency and you cannot wait, provide us with remote access and we will manually apply the fix for you.

 

[Einsteinium]

Hum bah voilà qui règle le problème met on apprend aussi qu'il y aura un 6.2 bêta