[R

[CrashOver1D]

Bonsoir,

Je viens vers vous car je suis plutôt coincé sur un problème touchant mon Syno depuis peu.

J'ai un Syno DS1513+ depuis plusieurs mois avec les paquets suivants :

COPS

CrashPlan

DarkStat

Download Station

Git

iTunes Server

JAVA SE for Embedded 6

NZBGet

Photo Station

pyLoad

Python

Serveur Multimédia

SickBeard Custom

En me connectant a distance du taf ce matin pour jeter un oeil au gestionnaire de fichier afin de répondre à un collègue sur la dispo d'un fichier, je me rends compte que ma conso CPU est à 99%, ce qui sur mon DS1513+ ne m'étais juste jamais arrivé même avec une indexation en cours ... Je fleure donc le soucis...

Je n'ai rien touché à la config depuis des semaines et me suis connecté à de nombreuses reprises pendant les fêtes, tout allait bien.

J'ai tenté un A/R du Syno, ça résouds le problème pendant quelques dixaines de minutes et ca revient ...

J'en ai profité pour faire les mises à jour de l'ensemble des paquets et du Syno (4.2 -> 4.3)

A/R du Syno puis Arrêt de l'ensemble des Paquets et relance un a un, CPU OK ... mais le problème réapparaît genre 2 heures après ...

Au niveau de la vue Syno on a donc ça :

C'est pas glorieux ^^

Du point de vue du gestionnaire de taches on a ça :

Les 4 process fautifs sont clairement défini, il s'agit du https_x86_64 (A noter avant l'update en 4.3 il s'appelait https tout court)

Je suis passé en SSH sur la bête pour y voir plus clair et voici le top :

Ces process correspondent donc à syslog-ng mais c'est là que j'ai un problème, je n'utilise pas le serveur syslog sur le Syno (désactivé dans le panneau de config)

Je suppose donc qu'il est lié à un packet mais je n'arrive pas à trouver lequel ?!

Une idée de la manière dont je pourrais m'y prendre ?

Modifié le 16 janvier 2014 par CrashOver1D

[CoolRaoul]

(Note: je ne connais pas tous tes packages supplémentaires)

A ta place, je désactiverai *un par un* chaque package tout en gardant simultanément un oeil sur la conso CPU avec "top".

Il y a des chances que ça permette d'isoler le coupable et ainsi simplifier les investigations suivantes.

PS: c'est sur syslog-ng que s'appuie le mécanisme syslog interne de DSM, même si le package syslog n'est pas installé (qui va utiliser sa propre instance distincte)

La surconsommation CPU de syslog semblerait indiquer qu'un process émet des messages syslog à très haute fréquence, reste à trouver lequel et pourquoi.

[CrashOver1D]

Merci pour ton retour !

La désactivation un par un, j'ai tenté mais en surveillant le gestionnaire de tache et non le top (j'étais à distance d'ou je n'ai pas accès au SSH)

Je suis arrivé a avoir désactivé l'ensemble des packets sans aucune diminution de l'utilisation de la CPU

(Je testerais ce soir la même manœuvre en surveillant le top)

Vu la charge que cela génère, je ne vois que des packets sérieux qui pouraient être à l'origine de ce dysfonctionnement, je penche soit pour Sickbeard soit pour CrashPlan, mais je n'arrive pas confirmer mes pistes

J'ai vérifié les logs de DSM, y'a rien, les logs interne de Sickbeard, pas d'activité suspecte, CrashPlan il faut que je voie si je trouve quelque chose

j'avais esperer trouver le package qui appèle syslog-ng via un PS mais même comme ça je ne retrouve que les process de syslog-ng, rien n'y faisant appel

Je suis familier d'UNIX (AIX) mais beaucoup moins de Linux du coup je suis un peu perdu sur ce petit Linux Syno ...

Modifié le 14 janvier 2014 par CrashOver1D

[CoolRaoul]

j'avais esperer trouver le package qui appèle syslog-ng via un PS mais même comme ça je ne retrouve que les process de syslog-ng, rien n'y faisant appel

Tu ne verra rien par un "ps": à la source ce sont des appels système à la fonction syslog().

syslog-ng est un démon alternatif qui peut remplacer le syslogd traditionel (c'est le cas sous DSM)

[CrashOver1D]

Ok je comprends, je pensais qu'un package utilisait un syslog alternatif, alors qu'en fait c'est DSM lui même qui utilise ce package alternatif et que du coup tout appel à syslog() l'utilise ...

Maintenant faut juste que j'arrive a trouver quel package joue le furieux avec ...

Si seulement il pouvait loguer dès le démarrage du package ça aurais été plus simple !

Il n'y a aucun moyen de savoir sur quel Log travail syslog à un instant T ?

Je vais réessayer un arrêt progressif des packages ce midi à distance déjà, sinon je le ferais avec contrôle du top ce soir

[CrashOver1D]

Bonjour tout le monde !

A priori j'ai réussi a diagnostiquer la source de l'incident, et a mettre en œuvre sa correction, je suis a 0,5 % de CPU depuis presque 24h alors que je dépassais pas 6h avant, du coup je viens vous en faire profiter car cela pourrait toucher d'autres personnes en fait ...

Après plusieurs heures à "jouer" avec les Packages sans réussite ni à isoler le pakage fautif ni stabiliser les ressources, j'ai eu la "chance" de voir en direct live un passage à 99% de CPU !

Sauf que là, les process incriminés n'étaient plus les même mais 4 process "minerd"

Après une recherche rapide, cette fois ci le problème est bien plus clair car connu !

http://forum.synology.com/enu/viewtopic.php?f=7&t=78993&start=15

En lien avec l'alerte CVE-2013-6987 de US-CERT.GOV publiée le 31/12/13

Faille de sécurité permettant de réaliser des actions liées à Filestation sur le port 5000 sans être authentifié

J'ai donc suivi les préco -> Application du Patch correctif numéro 4 sur le dernier DSM 4.3 (quel con j'avais pas les notifs sur les mises à jour de DSM alors que je l'avais mis sur les paquets ...)

En plus de ça j'ai stoppé le forwarding sur le HTTP et le WEBDAV sans SSL (j'en avais besoin car HTTPS bloqué au travail mais tant pis)

Depuis le problème ne s'est pas renouvelé (je croise les doigts pour que ce soit bien définitif !!)

Je reste quand même avec une interrogation, car en suivant le détail explicatif du lien que j'ai mis plus haut, l'inscruste des process minerd (un demon minant des bitcoins ...) est bien connu comme étant une faille de DSM 4.3 (antérieur au correctif 3)

En revanche mon problème initial avec les 4 process syslog à bien commencé sur un DSM 4.2 ... Même hack qui s'est étendu ? autre methode pour autre objectif ? est ce que le minerd au bout d'un moment fait peter un cable à DSM qui se met à loger comme un porc et le problème s'en retrouve transposé sur syslog ? Simple camouflage des process ?

Je suis perplexe ...

[sword]

Bonjour,

J'ai eu le meême problème, c'était dû à la notification d'indexation dans Sickbeard Custom.

J'espère que cela t'aidera.

[CrashOver1D]

Merci pour ton retour !

Pour l'instant depuis la mise à jour de sécurité DSM et la coupure de mes accès HTTP sans SSL, plus aucune occurrence de hausse CPU, je surveille ^^