Shutdown et reboot impossible sur DS710+

Just1 · le 31 décembre 2011

Dans le post n°34 de ce topic, vous trouverez l'ensemble des informations concernant ce problème, ainsi qu'une solution permettant de le résoudre durablement. Ne perdez pas de temps, cliquez sur le lien !

Ce topic a donné lieu à l'écriture d'un tutoriel que je vous conseille de consulter dès maintenant !

Bonjour à tous,

Depuis quelques temps j'ai un problème qui m'embête pas mal, alors après quelques investigations qui m'ont apporté des infos supplémentaires, je m'en remets à la communauté des experts

IPKG est installé sur mon DS710+, notamment pour Icecast et SVN (qui me sert beaucoup en ce moment). Il y a quelques mois, lors de la sortie de TimeBackup, j'avais eu des soucis : impossible de lancer l'application. Après contact du support Synology, ils m'ont dit que c'était à cause d'IPKG, qui montait /opt au démarrage, et résultat TimeBackup n'arrivait pas à faire son premier lancement.

Le problème que j'ai en ce moment est du même goût (en termes de cause) : impossible d'arrêter ou de redémarrer le Syno (obligé de rester appuyé sur le bouton jusqu'à coupure de l'alimentation). J'ai donc essayé de neutraliser IPKG, et là magie : je peux arrêter la machine ! Je ré-active IPKG, et je désinstalle tous les paquets officiels dont je ne me servais pas (dont TimeBackup). Il ne me reste alors que MailStation et phpMyAdmin.

Mais le problème est indemne : IPKG empêche l'arrêt de ma machine. Après extraction des logs, voici les lignes supplémentaires dans le cas ou l'arrêt ne fonctionne pas :


kernel: [2484412.625955] force umount failed! mnt_count:2

kernel: [2484413.679016] device-mapper: ioctl: unable to remove open device vol1-origin

syno_poweroff_task: space_snapshot_origin.c:354 Deleting snapshot-origin of /dev/md2 fail

Pour info : ipkg version 0.99.163

Quelqu'un a-t-il déjà rencontré ce problème ? Peut-il être dû à un seul des paquets IPKG installé, et si oui lequel ?

Un script à l'extinction pourrait-il résoudre le problème ?

Merci à tous, et bonne année 2012

Modifié le 13 avril 2016 par Just1
lien vers tutoriel

bud77 · le 2 janvier 2012

Tu pourrais tenter de faire un "umount <REPERTOIRE_DU_OPT>" puis lancer le reboot pour confirmer tes soupçons

Just1 · le 3 janvier 2012

OK alors je ne peux pas le faire tel quel car le système me répond :


umount: can't umount /opt: Device or resource busy

ce qui est logique puisque des programmes sont en cours d'exécution. Et là je me dis : "Si le système n'arrive pas à exécuter "umount" à la demande, c'est certainement qu'il n'arrive pas non plus à le faire lors de la procédure d'arrêt de la machine..." Sans aller jusqu'à "umount /opt", j'essaye donc de tuer les programmes IPKG en cours d'exécution. Pour cela, je les liste avec :


ps | grep "/opt/"

(Chez moi il y a "saslauthd" et "icecast" qui s'exécutent.) Puis, pour chaque élément de la liste, je tue le programme :


killall mon_programme

Et là évidemment j'essaye un reboot : ça fonctionne. Ce sont donc les programmes en cours d'exécution qui empêchent l'arrêt. Ça paraît tellement logique, et pourtant je n'y avais pas pensé...

Merci bud77.

Mais maintenant se pose une autre question : Comment moi, novice en Linux, je peux faire un script pour arrêter tous les programmes IPKG lors du shutdown (en utilisant par exemple le résultat de ' ps | grep "/opt/" ') ? Et où dois-je placer ces lignes de script ?

Modifié le 7 janvier 2012 par Just1

bud77 · le 4 janvier 2012

J'ai pas la main sur mon nas de la journée, mais je peux regarder ce soir si personne n'a d'idée d'ici là

bud77 · le 4 janvier 2012

Tout ceci reste à confirmer, car j'ai pas eu le temps de tester sur ma config, mais, voici un petit script a placer dans /usr/syno/etc.defaults/rc.d

(Faut créer un script Sxx_NOM_QUE_TU_VEUX.sh ou xx est le numéro de séquence dans le boot/shutdown)

case $1 in

start)

;;

stop)

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

killall $PNAME

;;

*)

;;

esac

Explications :

On va chercher dans la liste des process tout ce qui a un /opt, puis on extrait le PID (première colonne) de cette requête

Et ensuite on killall sur ces PID

A vérifier avant de mettre en script, évidemment

PatrickH · le 5 janvier 2012

Sous linux normalement, les scripts s'exécutent séquentiellement :

- pour le démarrage : les scripts s'exécutent suivant leur ordre de priorité S01xxx -> S99xxx avec en paramètre start

- pour l'arrêt : les scripts s'exécutent suivant leur ordre de priorité K01xxx -> K99xxx avec en paramètre stop

Donc dans ton cas il faudrait donc créer un Kxx_quelquechose.sh

Et moi je le placerais dans /opt/etc/init.d car si tu le mets dans /usr/syno/etc.defaults/rc.d il risque d'être écrase lors d'une mise à jour du firmware

Patrick

bud77 · le 5 janvier 2012

Merci pour le complément d'info Patrick, j'avais quelques doutes

Just1 · le 5 janvier 2012

Et moi je le placerais dans /opt/etc/init.d car si tu le mets dans /usr/syno/etc.defaults/rc.d il risque d'être écrasé lors d'une mise à jour du firmware.

Merci à vous deux. Je vais essayer ça dès que possible.

Petite question supplémentaire cependant : le script une fois placé dans /opt/etc/init.d est-il en "lieu sûr" ? (à l'abri d'une mise à jour de IPKG, ou de l'installation/désinstallation d'un paquet ?).

PatrickH · le 5 janvier 2012

Oui dans /opt/... il est à l'abri d'une mise à jour du firmware officiel du syno, maintenant si tu désinstalle complètement IPKG tu le perdra quand même. Ajouter ou enlever un package venant de IPKG ne posera pas de souci

Patrick

Just1 · le 7 janvier 2012

@bud : Je ne comprends pas bien l'utilisation de 'awk'. En plus lorsque je tape la ligne dans la console, je perds la main ; quand c'est dans le script d'arrêt, ça ne fonctionne pas.

Voici donc mon fichier K99_kill_opt_processes.sh placé dans /opt/etc/init.d/


case $1 in


start)

;;


stop)

PNAME=`ps |grep "/opt/" |grep -v "grep"`

killall $PNAME

;;


*)

;;


esac

Je me suis permis de modifier la ligne du 'ps' avec un slash final pour "/opt/" (on ne sait jamais...) et grep entre guillemets pour être plus clair dans ' grep -v "grep" ' (exclusion du programme grep qui s'exécuterait dans /opt/).

Tel quel ça fonctionne chez moi, donc je le garde !

Merci à tous les deux.

Si un modérateur pouvait déplacer ce sujet vers le forum "Modifications logicielles", où il aurait certainement plus sa place, je le remercie d'avance. A vous de juger

Modifié le 7 janvier 2012 par Just1

bud77 · le 7 janvier 2012

Le awk permet de ne récupérer qu'un ou plusieurs champs sur un résultat

Explication

awk -F" " '{ print $1 }'

Awk, avec comme champ délimiteur <espace> (ici " ") , puis d'afficher le premier champ trouvé ($1) qui est le PID à utiliser pour le kill

Si tu ne met pas le awk, il va sortir le ps complet, et le kill a se lancer pour tout les champs du résultat et te sortir pas mal d'erreurs

Et d'ailleurs je viens de remarquer une erreur, ce n'est pas killall qu'il faut mettre, mais kill tout court (killall attend un nom de process, kill un pid)

Just1 · le 7 janvier 2012

J'ai dû faire une erreur de frappe au début, et ça ne marchait pas.

J'ai donc ré-essayé, et en tapant dans la ligne de commande :


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

kill $PNAME

ça marche au poil. D'ailleurs,


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

me renvoie les bons PID.

Par contre, si j'intègre ces deux lignes à mon précédent post au script de mon précédent post, ça ne fonctionne pas ! Alors que la version que j'ai copié-collé ici tout à l'heure fonctionne... C'est à n'y rien comprendre.

Modifié le 8 janvier 2012 par Just1

bud77 · le 7 janvier 2012

Tu veux dire dans le script ?

Le script se lance en rajoutant stop derrière :

./K99_kill_opt_processes.sh stop

Just1 · le 8 janvier 2012

Lancé manuellement avec ta ligne d'appel, tout baigne.

Ça se complique lorsque je cherche à arrêter ou redémarrer le serveur sans lancer manuellement le script au préalable. Il faudrait que je sache comment et quand mon script est exécuté (si c'est le cas) : ça serait pas mal si j'écrivais une ligne dans les log... Une idée pour faire ça ?

PatrickH · le 8 janvier 2012

Pour écrire une ligne dans un log à partir d'un fichier de commande

echo "un commentaire quelconque" >> /volume1/public/log.txt[/CODE]

Ici dans un fichier log.txt qui se trouve dans le répertoire partagé "public"

Patrick

Just1 · le 8 janvier 2012

(En fait ça fonctionne comme les scripts Windows, donc j'aurais dû me douter de la syntaxe.)

En considérant que le point de montage /opt existe toujours au moment de l'exécution du script (puisque ce serait la raison de mon problème : arrêt impossible cause démontage impossible de /opt), j'ai rajouté une ligne à chaque cas possible de mon script :


echo $(date)+" : x_x" >> /opt/etc/init.d/log.txt

"x_x" vaut "start", "stop", ou "default" en fonction des cas. Quand je le lance à la main, encore une fois ça fonctionne. Mais le script ne semble pas être lancé par le système lors de l'arrêt (aucune entrée dans mon fichier) ! A moins évidemment que /opt n'existe plus...

Pourtant les log systèmes disent toujours :


force umount failed! mnt_count:2

Modifié le 8 janvier 2012 par Just1

bud77 · le 8 janvier 2012

Avec un K99, le script se lance tout à la fin normalement

Essaye de le nommer K01xxx.sh pour qu'il soit le premier à se lancer lors d'un reboot/shutdown

Just1 · le 8 janvier 2012

J'ai essayé, sans succès. J'ai même dupliqué le fichier (un K01, et un autre K99) : aucun des deux ne se lance !

Par contre, j'ai également fait une copie sous le nom de "S99***.sh", et là il se lance au "start" (je le vois de mon fichier de log "perso"), mais jamais au "stop".

Ma conclusion est la suivante : les scripts d'arrêts (Kxx) d'ipkg ne sont pas lancés.

D'ailleurs dans le script de démarrage de fetchmail (S52fetchmail), il y a aussi des instructions pour l'arrêt...


#!/bin/sh

PROG=fetchmail

ARGS="-d 300 -t 60 -a -e 50 --auth password -f /opt/etc/fetchmailrc -L /opt/var/log/fetchmail"

if [ -z "$1" ] ; then

    case `echo "$0" | /bin/sed 's/^.*\/\(.*\)/\1/g'` in

	    S??*) rc="start" ;;

	    K??*) rc="stop" ;;

	    *) rc="usage" ;;

    esac

else

    rc="$1"

fi

case "$rc" in

    start)

	    echo "starting service $PROG"

	    $PROG $ARGS 2>&1

	    ;;

    stop)

	    echo "stopping service $PROG"

	    if [ -n "`/opt/bin/pidof $PROG`" ]; then

		    /opt/bin/killall $PROG

	    fi

	    ;;

    restart)

	    "$0" stop

	    sleep 1

	    "$0" start

	    ;;

    *)

	    echo "Usage: $0 (start|stop|restart|usage)"

	    ;;

esac

Si je comprends bien il y a une sorte de bidouille pour interpréter les K** comme un "stop", mais je ne suis pas bien sûr de tout comprendre, surtout que je suis loin d'être un tueur en expressions régulières.

Une explication ? Patrick peut-être ?

Modifié le 8 janvier 2012 par Just1

bud77 · le 9 janvier 2012

Je regarde çà dans la journée, je te fais un retour quand j'ai le temps

bud77 · le 9 janvier 2012

J'ai trouvé 2 trucs à tester :

1) placer le script dans / opt / etc / init.d /

2) http://forum.synology.com/wiki/index.php/Spindown_issues

Regarde la partie "noatime" et le STEP2 du diagnosis

Just1 · le 9 janvier 2012

1) placer le script dans /opt/etc/init.d/

Ça c'est ce que je fais depuis le début, sur les conseils de Patrick. Mais pour la peine, j'ai aussi essayé de placer mon script (K01shutdown.sh) dans /usr/syno/etc/rc.d/ , et aucun changement significatif... Et parce que je suis généreux, je fais aussi un essai avec /usr/local/etc/rc.d/ , mais rien de plus. Et puis /etc/init.d/ aussi tiens ! Non plus...

2) http://forum.synolog...Spindown_issues

Regarde la partie "noatime" et le STEP2 du diagnosis

J'ai essayé de rediriger le cache vers /opt/lib , mais même après 3 redémarrage (et même pas de fichier /etc/ld.so.config), ça n'a aucun effet chez moi.

Puis j'ai continué à chercher, et je suis tombé sur une page de wiki Synonology en allemand traitant de IPKG. Comme je ne comprends pas un mot d'allemand, je remercie Google de fournir également un traducteur Assez nul dans ce cas là d'ailleurs, puisque les mots-clés des scripts sont également traduits

Mais cette lecture m'a permis, avec quelques farfouilles dans le NAS, de comprendre la suite logique des événements :

/etc/rc.local > /etc/rc.optware > /opt/etc/rc.optware

En très gros, voici ce que donne le contenu de ces scripts :

/etc/rc.local :


/etc/rc.optware start

/etc/rc.optware :


start)

	mkdir /opt

	mount -o bind ${REAL_OPT_DIR} /opt

	/opt/etc/rc.optware

stop)

	echo "Shutting down Optware"

/opt/etc/rc.optware :


for i in /opt/etc/init.d/S??* ;do

	(lancement des programmes avec l'attribut "start")

Après l'ajout de quelques lignes d'écriture vers un fichier depuis les 2 premiers scripts, je constate qu'ils ne sont lancés que lors du démarrage.


Mon Jan 9 22:00:25 CET 2012+ : /etc/rc.local

Mon Jan 9 22:00:25 CET 2012+ : /etc/rc.optware start

Cela explique en partie pourquoi mon script perso n'est jamais appelé avec l'option "stop".

Arrivés là, je vois 2 possibilités :

soit il existe un équivalent de rc.local pour le shutdown, et dans ce cas je serais très heureux que quelqu'un me l'apprenne, comme ça je pourrais lancer /etc/rc.optware en mode "stop", et ainsi de suite
soit il faut agir à un endroit qui m'est encore parfaitement inconnu...

Mais où diable se cache le script qui se charge du démontage des volumes ?? Et pourquoi fetchmail aurait prévu une séquence de "stop" dans son script de lancement si celui-ci n'est jamais exécuté ?

Je crois que ça y est, l'univers Linux m'envahit

Just1 · le 9 janvier 2012

Ça maaaaaaaaaarche !!

Sur cette même page de wiki, j'avais oublié de tester le optware.sh placé dans /usr/local/etc/rc.d/ (aux côtés de phpMyAdmin.sh et deMailStation.sh). J'ai tellement testé de trucs que j'ai fini par oublié celui-là... J'ai pris texto le script proposé, et ça fonctionne Comme quoi dans ce répertoire un fichier qui s'appelle "nimportequoi.sh" s'exécute, alors qu'on fichier "Kxx.sh" non (dans ma situation) !


#!/bin/sh

#

# Optware setup

# Alternatives Optware Startup und Shutdown Script #/usr/local/etc/rc.d/optware.sh

#

case $1 in

start)

	   for i in /opt/etc/init.d/S??* ;do

#

			   # Ignore dangling symlinks (if any).

			   [ ! -f "$i" ] && continue

#

			   case "$i" in

				  *.sh)

					   # Source shell script for speed.

					   (

							   trap - INT QUIT TSTP

							   set start

							   . $i

					   )

					   ;;

				  *)

					   # No sh extension, so fork subprocess.

					   $i start

					   ;;

			   esac

	   done

	   ;;

#

stop)

#

	   for i in /opt/etc/init.d/S??* ;do

#

			   # Ignore dangling symlinks (if any).

			   [ ! -f "$i" ] && continue

#

			   case "$i" in

				  *.sh)

					   # Source shell script for speed.

					   (

							   trap - INT QUIT TSTP

							   set stop

							  . $i

					   )

					   ;;

				  *)

					   # No sh extension, so fork subprocess.

					   $i stop					   ;;

			   esac

		 done

		 ;;

#

*)

		 echo "Usage: $0 [start|stop]"

		 ;;

esac

#

# End

Je suis SOULAGÉ, mon NAS peut maintenant enfin s'arrêter et redémarrer sans l'éteindre par la méthode "bruteforce" (en Français je dirais "bourrin" ).

Allez je me permets une dernière question : est-ce que /usr/local/etc/rc.d/ est l'endroit le plus adapté pour accueillir un tel script "optware.sh" ? Dans la mesure du possible j'aimerais avoir tous dans /opt/...

Modifié le 9 janvier 2012 par Just1

parisbyday · le 10 janvier 2012

J'ai le meme probleme, impossible de rebooter ou faire un shutdown.

Si je fait un reboot, apres 1 ou 2 minutes je peux pinger le DS1511 mais impossible de faire un ssh ou acceder a l'interface web.

Il faut voir que j'utilise ipkg avec sickbeard,coachpotato de synoblog.

C'est peut-etre pour ca.

La Led bleu clignote et la seule solution est de faire un arret brute force.

Jean.

Just1 · le 10 janvier 2012

(Merci à parisbyday qui m'a aidé à retrouver une configuration IPKG normale après la perte d'un de mes fichiers)

La Led bleu clignote et la seule solution est de faire un arret brute force.

J'avais exactement les mêmes symptômes. Le fait est que le NAS se bloque en pleine procédure d'arrêt. Peut-être que tu peux déjà vérifier si tes logs (/var/log/messages) ont des lignes similaires à celles de mon premier post.

Ci c'est le cas, tu peux pousser encore un peu en lançant une session SSH et en exécutant les deux lignes de script du 12ème post de ce topic. Ensuite, essaye d'arrêter ton NAS. Si ça marche, tu as gagné ! Je posterai très bientôt ma solution "définitive", avec des scripts propres et leur emplacement exact.

Sinon, il faudra s'arracher encore quelques cheveux. Mais poste ici tes résulats

parisbyday · le 10 janvier 2012

J'ai pas la meme chose que toi.

j'ai tenté un shutdow via DSM et j'ai du faire un arret brute force.

Dans le /var/log/messages j'ai a 18:35 au moment du shutdown :

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.

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)

Jan 10 18:36:02 syslogd exiting

Jan 10 18:47:00 syslogd started: BusyBox v1.16.1

Jan 10 18:47:01 kernel: [ 19.286300] md: md2: set sda5 to auto_remap [0]

Jan 10 18:47:01 kernel: [ 19.291038] md: md2: set sde5 to auto_remap [0]

Jan 10 18:47:01 kernel: [ 19.295766] md: md2: set sdd5 to auto_remap [0]

Jan 10 18:47:01 kernel: [ 19.300445] md: md2: set sdc5 to auto_remap [0]

Jan 10 18:47:01 kernel: [ 19.305149] md: md2: set sdb5 to auto_remap [0]

Jan 10 18:47:01 kernel: [ 19.343442] 0: w=1 pa=0 pr=5 m=1 a=2 r=5 op1=0 op2=0

Jan 10 18:47:01 kernel: [ 19.348592] 4: w=2 pa=0 pr=5 m=1 a=2 r=5 op1=0 op2=0

Jan 10 18:47:01 kernel: [ 19.353729] 3: w=3 pa=0 pr=5 m=1 a=2 r=5 op1=0 op2=0

Jan 10 18:47:01 kernel: [ 19.358916] 2: w=4 pa=0 pr=5 m=1 a=2 r=5 op1=0 op2=0

Jan 10 18:47:01 kernel: [ 19.364076] 1: w=5 pa=0 pr=5 m=1 a=2 r=5 op1=0 op2=0

Jan 10 18:47:01 kernel: [ 19.369217] raid5: raid level 5 set md2 active with 5 out of 5 devices, algorithm 2

Jan 10 18:47:01 kernel: [ 19.377090] RAID5 conf printout:

Jan 10 18:47:01 kernel: [ 19.380438] --- rd:5 wd:5

Jan 10 18:47:01 kernel: [ 19.383238] disk 0, o:1, dev:sda5

Jan 10 18:47:01 kernel: [ 19.386767] disk 1, o:1, dev:sdb5

Jan 10 18:47:01 kernel: [ 19.390300] disk 2, o:1, dev:sdc5

Jan 10 18:47:01 kernel: [ 19.393847] disk 3, o:1, dev:sdd5

Jan 10 18:47:01 kernel: [ 19.397371] disk 4, o:1, dev:sde5

Jan 10 18:47:01 spacetool: spacetool.c:2201 [info] Old vg path: [/dev/vg1000], New vg path: [/dev/vg1000], UUID: [N7OjqU-rE8c-sU2s-snmR-1HHW-MLFh-6sWkbW]

Jan 10 18:47:01 spacetool: spacetool.c:2208 [info] Activate all VG

Jan 10 18:47:01 spacetool: spacetool.c:2219 Activate LVM [/dev/vg1000]

Connexion

Shutdown et reboot impossible sur DS710+

Messages recommandés

Just1

bud77

Just1

bud77

bud77

PatrickH

bud77

Just1

PatrickH

Just1

bud77

Just1

bud77

Just1

PatrickH

Just1

bud77

Just1

bud77

bud77

Just1

Just1

parisbyday

Just1

parisbyday

Rejoindre la conversation

Qui est en ligne 8 membres, 0 anonyme, 243 invités (Afficher la liste complète)

Contributeurs populaires

Forum

Discussions

Articles

Information importante