Arrêt impossible du NAS

[Just1]

Ce tutoriel a été originellement posté dans la partie Modifications logicielles du forum. pour plus d'informations.

 

 

 

 

Tutoriel : Arrêt impossible du NAS

 

 

 

Description du problème, Diagnostic de panne, et Mise en place d'une solution

 

 

 

 

I) Symptômes

Après une demande d’arrêt ou de redémarrage, le NAS se bloque dans sa phase d’arrêt. On peut le constater en voyant que le bouton de mise en route ("power") de la machine clignote, même après plusieurs (très longues) minutes, voire même plusieurs heures d’attente.

Le NAS peut éventuellement conserver une activité réseau ou non, en fonction de la configuration de votre machine. Toujours est-il que tous les services sont offline (pas de DSM, pas de partage réseau, etc.), et il n’est donc plus possible de prendre le contrôle.

Après avoir attendu 10min et constaté le problème tel que décrit ci-dessus, le seul moyen pour arrêter la machine est de rester appuyé sur le bouton d’alimentation jusqu’à l’extinction complète.

 

=> Vous vous êtes reconnu dans cette description des symptômes ? Passez à la partie 2 !

 

 

II) Explications et cause probable

Si IPKG n’est pas installé sur votre machine, ou si vous ne savez pas s’il est installé, il y a 95% de chances pour que la solution donnée ci-après ne corresponde pas à votre problème. En effet, nous traitons ici d’un problème lié à IPKG, complètement indépendant du DSM et de la version actuelle du système…

Votre problème, s’il est lié à IPKG, est sûrement dû au fait que le système n’arrive pas à démonter le point de montage d’IPKG (autrement appelé « Optware »), à savoir /opt . Ce point de montage est créé au démarrage par le script /etc/rc.optware et redirige en réalité vers /volume1/@optware .

 

« Si le système arrive à faire le montage, pourquoi pas le démontage ? », me direz-vous. Prenons un exemple :

Vous travaillez sur un document de votre clé USB : un fichier texte est ouvert dans votre éditeur, et vous souhaitez « éjecter » votre clé de l’ordinateur. Dans la plupart des cas, le système refuse en vous signifiant que certains documents sont en cours d’utilisation. En effet, l’éditeur de texte a ouvert un document de la clé ! Il est donc impossible de la « démonter », et pourtant le système a bien réussi à la « monter ».

Il en est de même pour IPKG et /opt : il est probable que certains programmes « tierce-partie » s’exécutent dans /opt et ses sous-répertoires. Dans ce cas, le système est incapable de démonter /opt , et refusera purement et simplement de s’arrêter, car un programme en cours d’exécution peut avoir des bonnes raisons de l’être. C’est donc à l’utilisateur d’arrêter manuellement les programmes tiers, puisque l’installation d’IPKG ne prévoit apparemment pas l’arrêt automatique des programmes lors d’une demande d’arrêt du système.

 

Note :

Pour le diagnostic et la résolution du problème, vous allez avoir besoin d’un accès console à votre NAS (SSH, ou éventuellement Telnet), mais normalement vous êtes habitué, puisque vous avez déjà installé IPKG

Pour vérifier qu’IPKG est installé sur votre machine, connectez-vous via SSH ou Telnet et tapez « ipkg list ». Cette commande renvoie normalement la liste de tous les paquets disponibles au téléchargement ; si c’est la cas, IPKG est installé, et vous pouvez être concerné par le problème décrit dans ce topic.

 

 

III) Diagnostic de panne

1) Vous pouvez très simplement vérifier que votre problème est bien lié à un « démontage impossible » en regardant dans le fichier /var/log/messages et en cherchant une ligne similaire à

 

 

kernel: [******.******] force umount failed! mnt_count:*

2) Si une ligne de ce type existe, vous pouvez confirmer vos soupçons en tapant

 

umount /opt

si la commande s’exécute correctement, le problème vient d’ailleurs, sinon, vous avez bien un problème de démontage. 3) Tentons donc de remonter au coupable de ce « démontage impossible ». Il est probable que des programmes s’exécutent dans « /opt/ ». Pour le vérifier, tapez :

 

ps |grep "/opt/" |grep -v "grep"

Si la commande vous renvoie une ou plusieurs lignes, chacune d'elle correspond à un programme en cours d’exécution sur /opt/ (cause de votre malheur). Sinon, aucun programme ne s’exécute sur /opt/ , et il faudra chercher une autre piste. 4) Enfin, vous pouvez essayer d’arrêter manuellement tous les programmes tournant sur /opt/, puis de démonter le volume :

 

PNAME=`ps |grep "/opt/" |grep -v "grep" |awk -F" " '{ print $1 }'`

kill $PNAME

umount /opt

 

Si la dernière commande ne renvoie pas d’erreur, tentez un arrêt ou redémarrage de votre Syno : ça devrait fonctionner. Si c’est le cas, passons à la mise en place d’une solution automatisée, à base de scripts.

 

 

IV) Solution à adopter

Notre problème intervient lors de la phase d’arrêt, il nous faut donc un script qui se lance automatiquement lors de l’arrêt. Après avoir fait quelques recherches, il semble que sous Linux il y ait beaucoup de répertoires prévus pour lancer des scripts au démarrage, mais pas beaucoup à l’arrêt. Il ne reste donc que /etc/rc.d/ et /usr/local/etc/rc.d/ qui correspondent à nos besoins (source : wiki FreeBSD). D’après un forum relatif à FreeBSD, il est plus sage de placer ses scripts dans /usr/local/etc/rc.d/ (en considérant que toutes les distributions adoptent le même formalisme).

 

Citation

/etc/rc.d/ keeps the resource configuration scripts for FreeBSD. These scripts are designed to handle the launch of infrastructural services and daemons and should not be "polluted" with customized scripts.

Place startup scripts that you write under /usr/local/etc/rc.d/

 

Maintenant que vous savez tout, passons à la mise en place. Nous pouvons considérer qu’il existe deux solutions à notre problème. En plus d’un script d’arrêt général :

1) Pour chaque script S** présent dans « /opt/etc/init.d/ », il faut créer un équivalent K** dédié à l’arrêt du service associé.

2) Pour l’ensemble des scripts S** présents dans « /opt/etc/init.d/ », nous pouvons créer un script générique K99shutdown.sh qui se chargera d’arrêter tous les programmes IPKG en fonctionnement.

A mon avis, la solution 2 est plus simple et plus sûre, car elle ne nécessite qu’un seul script, et se base sur l’état réel de la machine au moment de l’arrêt (et non un état supposé).

 

Attention : Certains scripts S** fournis par les paquets contiennent des instructions d’arrêt. Si celles-ci ont d’autres fonctions qu’un simple kill ou killall, il est impératif de placer ces instructions dans un équivalent K** (sans même prendre en compte si le fichier est lancé en mode « start » ou « stop », puisque tous les S** seront lancés avec « start » et tous les K** avec « stop »).

 

 

V) Les fichiers

C’est parti !

Créons un fichier optware.sh avec les droits 755 dans /usr/local/etc/rc.d/ , il nous servira de lanceur pour l’ensemble des scripts de démarrage S** et d’arrêt K** contenus dans /opt/etc/init.d/ .

/usr/local/etc/rc.d/ optware.sh (chmod 755)

Puis créez un autre fichier K99shutdown.sh avec les droits 755 dans /opt/etc/init.d/ , il scannera tous les programmes s’exécutant dans /opt et les arrêtera.

/opt/etc/init.d/ K99shutdown.sh (chmod 755)

 

 

Enfin, comme décrit précédemment, vérifiez le contenu des /opt/etc/init.d/S** pour supprimer les cas « stop », et créez des équivalents K** qui contiendront les instructions correspondantes.

 

Ouf, maintenant, vous pouvez redémarrer !

 

 

N’hésitez pas à me faire des retours sur le fonctionnement de cette solution. Ce post sera mis à jour en conséquence, pour que tous les utilisateurs puissent en bénéficier.

Ce tutoriel a été écrit en se basant sur la configuration de mon Synology DS710+, mais doit pouvoir fonctionner pour tous les modèles, et pour toutes les versions de DSM (sauf en cas de refonte profonde de l'architecture système).

 

Merci à bud77, parisbyday et PatrickH du forum, qui m’ont permis d’élaborer cette solution, et donc de vous la faire partager.

Modifié le 13 avril 2016 par Just1
Titre corrigé, lien réparé vers le post original

[filoo]

Alors moi je dis "chapo bas", trés bel article. Un plaisir à lire.

[Xylo]

Sympa, cela m'est arrivé pas plus tard que ce matin.

Le reboot de la nuit n'a pas fonctionné et obligé de demander à Madame de se déplacer dans la salle machines pour appuyer sur le bouton power du nas

il faut que j'investigue.

[extenue]

Merci !

qd je pense que la fois ou j'ai eu le probleme , j'ai déplace toutes mes données puis reinstaller from scratch mon syno lol (a cette epoque je savais pas qu'on pouvait reinitialiser le DSM sans toucher au data ...) , je prends note de cette solution !

Sinon .. euh .. mon Syno refuse depuis qq semaines de demarrer via le WOL , ok on sort du sujet mais bon on sait jamais si ca vous parle !

[deltacle]

Merci pour ce tuto, cependant il n'a pas été suffisant pour moi.

J'avais un autre process qui bloquait l'arrêt du NAS, j'ai du rajouter un kill du "/usr/syno/mysql/libexec/mysqld" dans K99shutdown.sh.

[Winjp]

ça à fonctionné à merveille, j'ai eu le soucis depuis que j'ai installé la 4.0 finale.

l'ipkg foirait à mort et le reboot/shutdown aussi.

Grâce à vous, j'ai résolu la partie reboot/shutdown qui restait sans réponse =)

[dufilon]

Nikel merci beaucoup.

Après la mise a jour 4.0 mon syno ne s'éteignais plus.

Ipkg et squid installé.

Après cette procédure tous est rentré dans l'ordre.

Merci encore :-)

[Just1]

ça à fonctionné à merveille, j'ai eu le soucis depuis que j'ai installé la 4.0 finale.

Nikel merci beaucoup.

Après la mise a jour 4.0 mon syno ne s'éteignais plus.

Content de voir que ça fonctionne pour vous, même après une mise à jour du DSM !

[pilot]

Moi aussi DS111 après maj DSM 4

impossible d'éteindre sans couper le jus. Y a peut-être quand même une responsabilité des développeurs qui nous laissent dans la tchouc !

Bon j'ai trouvé un peu compliqué la démarche du script de Just1 : trop pro pour moi...

J'ai fait juste une désactivation d'IPKG : (on a le droit de citer ? )

Désactiver momentanément IPKG

- Pour neutraliser

o Renommer le fichier mv /etc/rc.local /etc/rc.local-sav

o Rebooter le Syno

- Pour réactiver

o Renommer le fichier mv /etc/rc.local-sav /etc/rc.local

o Rebooter le Syno

Et ça marche !

Source : http://www.acrodev.fr/global/a-propos/

Modifié le 1 avril 2012 par pilot

[mikael2235]

Super tuto !!! :D

Même problème pour moi, depuis le passage à DSM 4.0., impossible de couper mon syno à cause des scripts IPKG.

Problèmes résolu avec ce tuto.

[Just1]

Bonne nouvelle, pour ma part la mise à jour vers le DSM 4.0 n'a pas affecté les modifications décrites dans ce tutoriel. Espérons qu'au fil des mises à jour suivante nous puissions tous faire le même constat.

[tonymans72]

Je ne sais pas si je suis concerné par ce problème.

J'explique mon problème :

J'avais la main sur mon NAS à distance, et d'un coup, plus aucune connexion, pas accès au DSM...

Du coup, je rentre chez moi, essaie de m'y connecter en local via mon navigateur ==> impossible

Je tente en SSH et telnet ==> impossible

Je ne le détecte pas dans mes réseaux via l'explorateur windows.

En revanche, j'arrive à le pinguer (seule chose que j'arrive)

Du coup, j'essaie de l'éteindre au bouton. La led clignote bleue.. encore et encore et encore sans que rien ne se passe...

Donc coup de flip de l'éteindre électriquement...

Je le redémarre, tout est normal (un grand ouf)

Donc je lis ce sujet, je me faire un petit "cat /var/log/messages | grep kernel" mais je ne vois rien qui ressemble à un problème de démontage (umount)

Seul message qui m'intrigue, c'est celui ci :

Jun 26 17:06:26 kernel: [77737.210000] CIFS VFS: No response for cmd 114 mid 4360

et qui se répète une bonne cinquantaine/centaines de fois... (numéro à la fin qui augmente de 2 en 2)

Si vous avez des idées et si mon problème est bien celui du sujet.

PS : j'ai bien IPKG d'installé

[ppsy]

J'ai exactement le problème décrit, depuis quelques jours. Cela rassure de savoir que je ne suis pas le seul.

Par contre pas de IPKG chez moi (je ne sais même pas ce que c'est). De toutes façons, je n'y connaît rien à la programmation du NAS, donc beaucoup trop compliqué pour moi.

Synology ne devrait-il pas résoudre le problème???

J'ai juste installé un DS412+ tout neuf avec le dernier DSM et installé quelques packages, et le problème est survenu.

[mikael2235]

J'ai exactement le problème décrit, depuis quelques jours. Cela rassure de savoir que je ne suis pas le seul.

Par contre pas de IPKG chez moi (je ne sais même pas ce que c'est). De toutes façons, je n'y connaît rien à la programmation du NAS, donc beaucoup trop compliqué pour moi.

Synology ne devrait-il pas résoudre le problème???

J'ai juste installé un DS412+ tout neuf avec le dernier DSM et installé quelques packages, et le problème est survenu.

As-tu résolu ton problème ?

[ppsy]

As-tu résolu ton problème ?

Non. Je pense que c'est lié au PMS (Plex Media Server), mais ça pourrait bien être autre chose. Ce n'est pas trop pénalisant, vu que je peux rester appuyé sur le bouton 10 secondes en continu, et ça l'éteint.

e je peux rester appuyé sur le bouton 10 secondes en continu, et ça l'éteint.

Modifié le 11 août 2012 par ppsy

[erig]

ipkg je sais même pas ce que c'est, mon DS212J ne s'éteint plus lumière bleue clignote , il faut rester combien de temps appuyé sur le bouton marche arret, en appuyant plus d'une minute ça s'éteint toujours pas

[Ben22640]

Bonjour J'ai également le même problème que #erig depuis quelques semaines.

Même en appuyant sur le bouton power pendant une minutes le NAS ne s'éteint pas. Je suis obligé de le débrancher électriquement.

Modifié le 9 août 2013 par Ben22640

[synoben]

Meme probleme sur mon DS214.

Mise à jour DSM 100%
Rédemarrage en cours...

en cours...

en cours...

La led bleu clignote. Arret impossible par le bouton.

ah! je viens de me rendre compte que j'avais un fichier texte stocké sous le syno qui était resté ouvert pendant la mise à jour.

Le problème pourrait-il venir de là?

Modifié le 5 juin 2014 par synoben