Shutdown et reboot impossible sur DS710+

[Just1]

Jan 10 18:35:33 root: /usr/syno/etc/rc.d/S98findhostd.sh stop findhostd

Jan 10 18:35:42 kernel: [282425.556451] nfsd: last server has exited, flushing export cache

Jan 10 18:35:43 ssctl: services.cpp:486:StopAllSsd(): Try to stop cam[1].

Jan 10 18:35:43 ssctl: services.cpp:423:StopSsdThread(): Stop cam[1] failed.

Jan 10 18:35:49 scheduler: scheduler.c (1661) Got signal. Die gracefully.

Jan 10 18:35:51 ntpdate: Sync with time server 192.43.244.18 offset 0.440070 sec.

Tout ça c'est normal, de ce que j'ai pu constater.

Jan 10 18:36:01 kernel: [282444.252266] hub 6-0:1.0: cannot reset port 1 (err = -19)

Jan 10 18:36:01 kernel: [282444.257901] hub 6-0:1.0: cannot disable port 1 (err = -19)

Jan 10 18:36:01 kernel: [282444.263685] hub 6-0:1.0: cannot reset port 1 (err = -19)

Jan 10 18:36:01 kernel: [282444.269263] hub 6-0:1.0: cannot disable port 1 (err = -19)

Jan 10 18:36:01 kernel: [282444.275084] hub 6-0:1.0: cannot reset port 1 (err = -19)

Jan 10 18:36:01 kernel: [282444.280666] hub 6-0:1.0: cannot disable port 1 (err = -19)

Jan 10 18:36:01 kernel: [282444.286449] hub 6-0:1.0: cannot reset port 1 (err = -19)

Jan 10 18:36:01 kernel: [282444.292034] hub 6-0:1.0: cannot disable port 1 (err = -19)

Jan 10 18:36:01 kernel: [282444.297830] hub 6-0:1.0: unable to enumerate USB device on port 1

Jan 10 18:36:02 kernel: [282444.304210] hub 6-0:1.0: cannot disable port 1 (err = -19)

Ça c'est beaucoup moins normal. Tu sembles avoir un périphérique USB connecté (un onduleur peut-être ?), et le port sur lequel il est branché ne peut pas être arrêté, va savoir pourquoi... Pour tester, je pense que si tu débranches les périphériques USB, tu ne devrais pas constater ce problème. Il faudrait chercher du côté de ce code d'erreur "-19" en rapport avec "hub 6-0:1.0". Dans tous les cas, on ne dirait pas que ce soit lié à IPKG.

Tu as vu qu'un gars avait le même problème que toi sur le forum officiel Synology ? Peut-être que depuis il a trouvé la solution... (Tiens, il est en RAID5, comme toi Mais ça n'a peut-être aucun rapport.)

Peut-être qu'il vaut mieux que tu démarres un nouveau sujet, dans une partie du forum plus adaptée à ton problème.

[bud77]

A tout hasard, ce serait pas un périphérique USB 3?

[parisbyday]

Merci Just1 pour ton temps et ton analyse.

En fait il n'y a qu'un péripérique USB attaché et il s'agit d'un Onduleur APC.

J'ai egalement un disque e-sata attaché sur lequel je fais mes backup.

Je vais voir si en déconnectant l'onduleur le power off ou reboot devient possible.

Je vais continuer mes recherche sur le site US et eventuellement ouvrir un incident au support.

Merci pour ton aide.

[parisbyday]

j'ajoute que dans mon cas, je peux toujours pinger le DS1511 apres avoir fait le shutdown.

[parisbyday]

Je viens de faire un test avec l'UPS desactivé et deconnecté. Meme message sur l'USB. Donc ca a pas l'air lié.

Cependant ce qui est interressant c'est que je vois un message qui ressemble aux tiens :

Jan 10 21:50:01 ntpdate: Sync with time server 192.43.244.18 offset 0.192517 sec.

Jan 10 21:50:11 kernel: [11007.342908] force umount failed! mnt_count:9

Jan 10 21:50:14 syno_poweroff_task: lvm_poweroff.c:56 Failed to /sbin/vgchange -an > /dev/null 2>&1

Jan 10 21:50:14 kernel: [11009.754555] hub 6-0:1.0: hub_port_status failed (err = -19)

Jan 10 21:50:14 kernel: [11009.760300] hub 6-0:1.0: cannot disable port 1 (err = -19)

Jan 10 21:50:14 kernel: [11009.765983] hub 6-0:1.0: cannot reset port 1 (err = -19)

Jan 10 21:50:14 kernel: [11009.771470] hub 6-0:1.0: cannot disable port 1 (err = -19)

Jan 10 21:50:14 kernel: [11009.777133] hub 6-0:1.0: cannot reset port 1 (err = -19)

Jan 10 21:50:14 kernel: [11009.782662] hub 6-0:1.0: cannot disable port 1 (err = -19)

Jan 10 21:50:14 kernel: [11009.788390] hub 6-0:1.0: cannot reset port 1 (err = -19)

Jan 10 21:50:14 kernel: [11009.793861] hub 6-0:1.0: cannot disable port 1 (err = -19)

Jan 10 21:50:14 kernel: [11009.799519] hub 6-0:1.0: unable to enumerate USB device on port 1

Jan 10 21:50:14 kernel: [11009.805848] hub 6-0:1.0: cannot disable port 1 (err = -19)

Jan 10 21:50:14 syslogd exiting

J

[parisbyday]

Conclusion j'ai fait un kill des process ipkg (grep opt) et le shutdown fonctionne !

Top merci pour l'aide, ca faisait 2 mois que je trainais ca.

Reste plus qu'a mettre en place le script pour killer ces process a la fin.

Bonne soirée.

[parisbyday]

Dis Jut1, as tu fait les modifcations recommandés sur le forum hollandais ?

L'ajout des commentaires dans l'ancien startup script

Puis umount /opt

et l'ajout du lien symbolique :

rmdir /opt

ln-s /volume1/@optware /opt

[Just1]

Non non, mon installation IPKG "standard" faisait très bien les choses toutes seules, il n'y avait aucune raison que je change. Et puis démonter un volume pour créer un lien symbolique, ce n'est que contourner le problème, pas le résoudre...

En tout cas ton problème est bien lié à IPKG, ça m'étonnait aussi que je sois le seul.

Je compte encore faire quelques modifications sur mes scripts, et je ferai un post "résumé", avec :

• les symptômes constatés,
  
• la méthode de diagnostique,
  
• et la mise en place de la solution.
  

Sois patient encore 2 ou 3 jours, et tu auras la version "clé en main"

[Just1]

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 de la machine clignote en bleu, 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).

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

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

Modifié le 12 janvier 2012 par Just1

[bud77]

Joli Just1

Par contre, hésite pas a créer un nouveau post dans la section Tutoriels si c'est pas déjà fait

[parisbyday]

Super tuto.

Je vais tester tout ça !

[parisbyday]

Ca fonctionne parfaitement dans mon cas.

Dans opt/etc/init.d j'avais S10cron et S70net-snmp (pour cacti).

Merci pour le tuto.

Jean

[eprevot]

J'ai créé un script pour démarrer svn quand je démarre le NAS, dans /opt/etc/init.d/S50svn.sh :

/opt/bin/svnserve -d -r /volume1/svn/blabla

Quand j'essaie d'éteindre le NAS alors que le svn tourne, il ne s'éteint pas et umont /opt me retourne "umount: can't umount /opt: Device or resource busy", donc j'ai l'impression que mon problème correspond au tuto. Je voudrais donc pouvoir killer automatiquement le processus svn quand je demande d'éteindre le NAS.

J'ai copié optware.sh dans /usr/local/etc/rc.d/ et K99shutdown.sh dans /opt/etc/init.d/, mais le NAS refuse toujours de s'éteindre.

Quand j'essaie d'éteindre le NAS (via le synology assistant), je peux toujours me connecter en ssh, mais /opt ne contient plus rien. Dans /var/log/messages j'ai :

Jul 9 15:55:13 scemd: scemd.c:255 receive SIGTERM

Jul 9 15:55:14 root: /usr/syno/etc/rc.d/S98findhostd.sh stop findhostd

killall: synolunbkp: no process killed

Jul 9 15:55:26 ntpdate: Sync with time server 17.72.255.12 offset -0.036931 sec.