lndiana

Et s’il n’y avait que les nas... ce processeur équipe des routeurs, switch, box, etc...

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.

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.

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...

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!

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

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..

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

Bonjour, Je cherche une infos depuis ce matin sur le net sans rien trouver. J'ai monté un volume SHR sur mon 415+ avec 2x3To. J'y ai ensuite ajouté 2x4To. Et depuis cet ajout, je constate un ralentissement des accès disques de certaines application docker. J'ai lu que ca pouvait être à cause de la différence de taille des disque de mon SHR. Le syno à créé plus de partitions sur les 4To que sur les 3, pour remplir (ce que j'ai effectivement constaté). Normal, sauf que ca implique plus d'accès sur les 4To, et donc une diminution des perfs. Ma question est : est-ce que le syno va reconstruire les partitions si je remplace un disque de 3To par un 4, avec réparation du volume. puis le dernier dd de 3 par un 4 (et re-réparation). (L'idée étant de ne pas devoir recréer un volume : les applications sont chiantes à déplacer...) Merci :)

Hello, Bon, finalement, ils n'ont rien fait, mais chez eux ca marche (apparemment..) Mais de mon coté, j'ai réglé le problème en n'ouvrant plus le port 2001 sur mon container docker pour jeedom. Je l'ai remplacé par 20001 et VPN refonctionne... Le port 2001 est apparemment utilisé par PPTP, que je n'utilise pas, mais ca empeche le package de s'ouvrir, et de se desinstaller...

Pas autant que moi. Même si ca n'expliquera pas pourquoi ni comment ils ont fait pour planter le nas au point qu'il ne soit plus accessible du tout, même du LAN. Mais que jeedom, même inaccessible, tournait encore.

Hello, Petit retour sur mon probleme. Finalement, après plus d'une semaine d'investigation du support Synology de Taiwan et plus de 5 session d'acces a distance, ils ont fini par corrigé le probleme. Bon, leur explications ne sont pas très clair : je vais essayé d'en savoir plus sur la correction. Mais il y avait clairement un problème entre le package VPNServer et le serveur web (nginx) de jeedom hébergé dans un container Docker o_O Franchements, même si ils ont complètement planté le nas ce matin (et ma domotique avec, mais un soft reboot a tout réglé), ils ont assuré. Et leur persévérance fait plaisir. :)

Rien, malheureusement... :( syslog, messages, auth et dmesg.

Je crois que je progresse : si je demarre sab vers package ou version container docker : ca plante le VPN Si je demarre un autre container avec un acces https (donc avec ssl) : ca plante le VPN du syno Si je desactive tout les containers : ca remarche. Et a la seconde ou un des serveur web (probablement incluant ssl, mais je ne m'en sers qu'en http) d'un des containers "avec privileges elevés" se lance : ca plante le VPN du syno! Et je n'ai pas le choix pour un d'entres eux, j'ai besoin des privileges elevés pour lire les ports usb...

Y'aurait pas un probleme avec OpenSSL? Parce que même quand je lance sab depuis un container docker, ca fout la grouille avec VPNCenter...