Sky007FR

@Jeff777 Moi aussi j'avais un moment bloqué les updates en 1.20-2 mais je suis repassé en update automatique "latest" depuis. Mis à part ce bug de parsing rencontré avec la 1.22.0, le monitoring fonctionne parfaitement. En effet, dans ma config j'ai décommenté les lignes qui concerne la rotation des logs : logfile_rotation_interval = "7d" logfile_rotation_max_size = "10MB" logfile_rotation_max_archives = 10 Et ça fonctionnait parfaitement comme cela depuis longtemps. Voici l'erreur renvoyée dans le journal avec la 1.22.0 : [telegraf] Error running agent: Error loading config file /etc/telegraf/telegraf.conf: error parsing [agent]: line 83: (config.AgentConfig.LogfileRotationInterval) time: unknown unit "d" in duration "7d" @oracle7 Je suis en DSM 6.2.4 car mon DS1812+ n'est pas compatible avec DSM 7. Je confirme que le paramètre par défaut est bien "0d" et "7d" devrait aussi fonctionner... J'ai essayé "7D", même souci. Du coup j'ai remplacé par "168h" et ça passe !

Hello! Pour info, la maj auto de telegraf en 1.22 m'a causé un souci. J'ai du remplacer : logfile_rotation_interval = "7d" Par : logfile_rotation_interval = "168h" Sinon j'avais une erreur de parsing du fichier de conf... qui n'aime pas le "d"

Merci 👍 J'ai testé 2 configurations: - 1er essai position 1 et 2, la position 3 étant libre puis 4, 5, 6, 7, 8 prises par des HDD - 2eme essai position 2 et 3, la position 1 étant libre puis 4, 5, 6, 7, 8 idem que précédemment. => Pas de différence sur la température CPU

Merci pour ton retour. C'est bien la température que j'avais "avant". Je vais devoir revérifier les radiateurs sur la carte mère une 2e fois.

Merci pour ta réponse. La courbe c'est un peu compliqué, j'ai un telegraf qui monitore le NAS et enregistre les données dans un BDD InfluxDB et je visualise avec Grafana... Le plus simple est d'aller ici :

Bonjour à tous, J'ai récemment installé 2 SSD SATA sur mon vénérable DS1812+ pour accélerer les accès disques sur les petits fichiers qui avaient tendance à beaucoup trop faire travailler mes HDD. Avant et après l'opération la température du CPU a beaucoup augmenté (cf. graphique de monitoring ci-dessous avec à gauche la température avant opération et à droite la température après opération) avec environ 15°C de plus pour passer de 45°C à 60°C sans avoir une température ambiante différente. Je ne pense pas que ce soit réellement le cache SSD qui ait provoqué cette hausse de témperature. En effet la charge CPU est globalement la même qu'avant : De plus, pensant avoir, peut-être, fait bouger le radiateur CPU lors de l'installation des SSD, j'ai retiré les 2 radiateurs présents sur la CM du Synology, j'ai remplacé la (très) vieille pate thermique par une nouvelle et j'ai remis les radiateurs en place ce qui m'a fait gagner quelques degrés en passant de 60°C environ à 55°C maintenant. Du coup, avec 55°C de température moyenne actuelle, dois-je m'inquiéter ? Est-ce que d'autres possesseus d'un modèle de la série xx12+ pourrait m'indiquer leur température CPU moyenne ?

Voici les droits sur mon NAS :

Bonjour, Une info pour ceux qui pourraient avoir le même souci. Watchtower m'a automatiquement mis à jour telegraf depuis la 1.20.2 en 1.20.3 à 4h du matin. Depuis le récupération des infos docker ne fonctionnait plus : message d'erreur dans le journal "permission denied" sur "/var/run/docker.sock". N'ayant pas trouvé de solution, je suis repassé en 1.20.2, j'ai désactivé watchtower et c'est reparti : Dans les releases notes de telegraf 1.20.3, il y a une mention concernant docker : https://docs.influxdata.com/telegraf/v1.20/about_the_project/release-notes-changelog/

Même en version finale... Mais dans ce DSM 4.1 bêta me semble plus buggé qu'à l'accoutumée vu les retours sur les forums.

Bonjour, Depuis la MAJ en DSM4.1 mon NAS plante lamentablement lorsque j'essaie de me connecter à photostation. La charge CPU passe alors à 100% et je ne peux plus accéder à l'interface web ni même au SSH... Je ne peux même pas l'éteindre correctement. Je suis obligé de rester appuyé 10s sur le bouton ON/OFF pour l'éteindre de force. J'ai essayé avec la paquet photostation normal et celui en version beta, le comportement est identique. J'ai vraiment l'impression, pour une fois, d'avoir à faire à une version alpha et non bêta... car il y a de nombreux bugs dont certains très gênants.

J'ai la même question S'il faut être absolument administrateur c'est dommage...

Bon... après une réinstall propre du DSM sur le DS1812+, ça marche ! Je ne sais pas pourquoi la 1ère fois ça n'avait pas fonctionné...

Euh... c'est bizarre, j'ai branché l'onduleur sur mon autre NAS, le DS209+II avec la même version de firmware et... ça marche ! Dans le /var/log/messages du DS209+II j'obtiens : Jul 6 20:14:36 usbhid-ups[12922]: Startup successful Jul 6 20:14:36 upsd[12945]: Startup successful Jul 6 20:14:36 upsd[12945]: upsd.c:723 IP [127.0.0.1] add to ACL list Jul 6 20:14:36 upsd[12945]: upsd.c:727 IP [::1] add to ACL list Et j'ai bien l'UPS qui apparait dans le menu Alimentation. Si je rebranche sur le DS1812+, rien... nada...

J'ai acheté le modèle au dessus, le EATON Ellipse ECO 1600 USB, en pensant qu'il serait aussi compatible mais non : ça ne marche pas... Marque & Modèle:EATON Ellipse ECO 1600 USB Raccordement: USB Puissance: 1600VA / 1000W Firmware : DS1812+ DSM 4.0-2228 INCOMPATIBLE -> "root: This UPS is not supported" dans /var/log/messages et "aucun UPS connecté" dans le menu "Alimentation"

Le nouveau firmware CC4H est dispo ici : http://knowledge.sea...US/FAQ/223651en C'est censé corriger un problème de "chirp sound" comme on l'entend sur cette vidéo : Moi je n'ai rien entendu de tel en CC4B mais comme je n'ai encore pas mis de données sur les disques, autant mettre le dernier firmware dispo dès le départ

Bon... 8h30 de boulot et les disques sont tous préparés ! Je viens de voir que mes Seagate sont en firmware CC4B -> je vais les passer en CC4H...

Tu n'es pas obligé mais c'est (toujours) recommandé. Si tu as de la place dans le syno, je te conseille de le faire directement dedans en suivant le tuto de Fred (catégorie "Sous Telnet. SYNO neuf et 2 disques minimum")

Évidemment que je ne vais pas l'utiliser s'il est vraiment défectueux. Je vais le tester sur mon PC avant de décider s'il va faire un tour à la poubelle ou pas, si oui un autre WD 1To servira de backup à la place. PS : sans compter une sauvegarde rsync supplémentaire sur mon PC donc double backup, non je n'aime pas vivre dangereusement Ah oui j'oubliais : un onduleur est aussi en route pour protéger tout cela des coupures de courant. Ce sera un Eaton Ellipse ECO 1600VA Offline sur lequel pas mal de choses seront branchées, notamment : - le NAS DS1812+ et le disque branché USB2 - la box ADSL avec switch gigabit intégré - le PC (gros consommateur de Watts avec Crossfire et triple écran...)

Bon... j'ai reçu mon DS1812+ et 3 disques Seagate 3To ce midi ! Au final je vais opter pour la configuration suivante : - 2x Western Digital Caviar Green WD10EADS-65L5B1 en RAID1 pour le volume 1 qui servira notamment à du torrent 24/7 (emplacements 2 et 3) - 3x Seagate ST3000DM001-9YN166 en SHR1 pour le volume 2 dédié au stockage des données photos/musiques/vidéos... (emplacements 5, 6 et 7) - 1x Samsung Spinpoint F1 HD103UJ (si celui-ci est encore en vie car j'ai des erreurs SMART... cf ) branché en USB2 pour les backups des fichiers les plus important uniquement En attendant j'ai provisoirement mis un autre disque WD 1To sur le premier emplacement pour préparer les 5 autres disques en même temps en suivant le tuto de Fred : préparation lancée vers 13h15, les 5 processus "dd" sont en cours et monopolisent % des ressources CPU...

Ok merci, me voilà rassuré pour mes Seagate ! Il me reste à voir si le Samsung est réellement HS ou pas, je crois que je vais devoir l'installer dans le PC pour tester...

Je viens de récupérer 3 nouveaux disques Seagate 3To ce midi que je suis en train de les préparer (avec "dd"). Les valeurs SMART de ces disques me semble bien étranges (cf. valeurs 1, 7 et 240)... Seagate ne semble pas coder les infos comme les autres (enfin j'espère car sinon c'est grave!) Les valeurs des autres disques Seagate sont du même ordre.

Hello, En vue de mon transfert de données dans mon nouveau NAS, j'ai fait quelques tests SMART sur chacun de mes disques. Il s'avère qu'un de mes disques (branché en eSATA pour du faire du backup hebdomadaire) n'arrive pas à effectuer le test (ni rapide, ni étendu) ce qui met son statut sur "anormal" (il était sur "normal" avant que j'essaie de lancer le test). Si je regarde les détails des infos SMART, je ne vois rien de bien alarmant... à part peut-être la valeur 24 pour "UDMA_CRC_Error_Count". Est-ce grave docteur ? Faut-il jeter ce disque à la poubelle ?

Le nouveau SPK (bêta) fonctionne bien chez moi. Je n'ai pas remarqué de hausse sensible de la conso en CPU. Merci

Encore une petite question, est-il toujours nécessaire de préparer les disques comme à l'époque où j'avais installé mon DS 209+II sachant que Synology à integré une préparation sur les firmwares récents?

J'ai lu mais... visiblement je n'ai (toujours) pas compris ce que tu conseillais J'ai cru que tu conseillais de faire un volume RAID1 pour le système et un SHR1 pour le reste. Si le RAID1 sur le disque système ainsi que la séparation système/données en deux volume sont inutiles, je m'abstiens dans ce cas. Donc le RAID1 ne sert à rien pour la partition système ? Ok je pensais qu'il pouvait y avoir un gain en performance en séparant les 2 volumes. Un peu comme sur un PC où j'ai l'habitude d'avoir un disque (ou une partition) dédiée au système et un autre au stockage (voire aussi pour le swap)