sangorys Posté(e) le 6 octobre 2012 Partager Posté(e) le 6 octobre 2012 (modifié) Bonjour, j'ai bootstrappé mon Syno. Je ne sais pas ce que ça veut dire ni ce que ça fait, mais du coup je peux utiliser nano et bash (entre autre). Mon problème est qu'il faut que je lance à chaque connexion ssh à mon synology le script syno-mvkw-bootstrap_1.2-7_arm.xsh. D'une part, c chiant, mais le pire c qu'au démarrage du syno, il n'est plus bootstrapper. L'impact est que je lance un script bash au demarrage du syno. Ce script bash ne marche jamais puisque j'ai l'erreur : -ash: bash: not found Comment donc puis je lancer un script bash au demarrage ??? Merci Modifié le 3 janvier 2013 par sangorys 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
DjMomo Posté(e) le 6 octobre 2012 Partager Posté(e) le 6 octobre 2012 As tu suivi http://fredo.servehttp.com/html/Astu-02.htm ? 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
sangorys Posté(e) le 6 octobre 2012 Auteur Partager Posté(e) le 6 octobre 2012 J'ai suivi un autre tuto, mais qui dit la meme chose. Le truc qui cloche avec ma config et ce tuto, c quand je lance sh syno-mvkw-bootstrap_1.2-7_arm.xsh, j'obtiens pas la meme chose que dans le tuto : Optware Bootstrap for syno-mvkw. Extracting archive... please wait bootstrap/ bootstrap/bootstrap.sh bootstrap/ipkg-opt.ipk bootstrap/ipkg.sh bootstrap/optware-bootstrap.ipk bootstrap/wget.ipk 1232+1 records in 1232+1 records out Backup your configuration settings, then type: rm -rf /volume1/@optware rm -rf /usr/lib/ipkg This will remove all existing optware packages. You must *reboot* and then restart the bootstrap script. BusyBox v1.16.1 (2012-08-30 00:05:10 CST) built-in shell (ash) Enter 'help' for a list of built-in commands. Bien entendu, un reboot ne change rien et si j'efface les 2 dossiers comme ils le disent, je dois réinstaller ipkg et je retombe à nouveau sur le meme problème !!! 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Sp@r0 Posté(e) le 6 octobre 2012 Partager Posté(e) le 6 octobre 2012 C'est un problème de path, il faut rajouter /opt/bin dans /root/.profile 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
sangorys Posté(e) le 6 octobre 2012 Auteur Partager Posté(e) le 6 octobre 2012 Enorme progres Avec le path, plus besoin de relancer sh syno-mvkw-bootstrap_1.2-7_arm.xsh Je verrai au prochain redémarrage pour voir si mon probleme est complètement résolu MERCI : vous etes vraiment des stars dans ce forum, et qui plus est "de bonne volonté" 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
sangorys Posté(e) le 13 octobre 2012 Auteur Partager Posté(e) le 13 octobre 2012 Mon problème est partiellement résolu. Ce qui marche : plus besoin dans lancer le script de bootstrap au démarrage de ma session SSH Ce qui marche pas : au démarrage du syno dans le dossier /usr/syno/etc/rc.d, mon script est lancé mais ne marche pas. Est-ce que .profile est lancer avant de lancer les services de rc.d ? J'ai le meme problème avec cron. 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Sp@r0 Posté(e) le 13 octobre 2012 Partager Posté(e) le 13 octobre 2012 En fait le PATH n'est pas forc 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
CoolRaoul Posté(e) le 13 octobre 2012 Partager Posté(e) le 13 octobre 2012 (modifié) Ce qui marche pas : au démarrage du syno dans le dossier /usr/syno/etc/rc.d, mon script est lancé mais ne marche pas. Est-ce que .profile est lancer avant de lancer les services de rc.d ? J'ai le meme problème avec cron. "/etc/profile" et "~/.profile" sont sourcés *uniquement* par les "login shells" (qui sont en général des shells interactifs) ce qui n'est bien entendu n'est pas le cas du shell exécutant les scripts situés dans "/usr/syno/etc/rc.d". C'est en outre une très mauvaise idée de mettre des scripts de démarrage "custom" dans des dossiers système de DSM comme celui-ci, dossiers pouvant être wipés à la moindre mise à jour D'autant plus que les devs Synology, dans leur grande sagesse, nous ont réservé /usr/local (au contenu préservé lors des upgrades) pour les customisations personnelles. Par conséquent je t'invite pour commencer à déplacer ton script dans "/usr/local/etc/rc.d" en appliquant les instructions du fichier README.txt situé à cet endroit, à savoir: If you would like to run an application when the system boots up, you have to write a startup script and put it in /usr/local/etc/rc.d/. Following are some rules for the startup script: It must have the suffix “.sh”. For example, “myprog.sh”. The permission must be 755. It must have the options “start” and “stop”. When the system boots up, it will call “myprog.sh start”; when it shuts down, it will call “myprog.sh stop”. You can refer to the scripts in /usr/syno/etc/rc.d/. They are scripts for Synology default services. J'y ajouterait ma préconisation personnelle de te restreindre à utiliser dans ce script une syntaxe shell posix minimale (et donc d'éviter les extensions bash, et y utiliser impérativement le shebang "#! /bin/sh" ) Cette page de man est la bonne référence à utiliser pour savoir ce que tu peux et ne peux pas utiliser dans un tel script. Pour terminer tu dois savoir que tout script de ce type (s'exécutant automatiquement au démarrage, mais cela s'applique aussi aux scripts lancé par cron) doit être écrit en ne présupposant en aucune manière avoir été lancé dans un contexte prédéfini. Cela signifie qu'il est impératif que ces scripts positionnent *eux mêmes* le contexte dont ils ont besoin pour travailler sans faire la moindre confiance à la façon dont ils ont été invoqués. Cela inclut notamment le PATH, le répertoire courant et toutes les variables d'environnement qui peuvent être nécessaire à leur bonne exécution. A la limite tu peux sourcer explicitement /etc/profile (et ~/.profile) dans ces scripts (avec la commande ".") mais je suis pas sur que ce soit le plus propre. Modifié le 13 octobre 2012 par CoolRaoul 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
CoolRaoul Posté(e) le 14 octobre 2012 Partager Posté(e) le 14 octobre 2012 Conseil supplémentaire: pour voir ce qui se passe dans le cas d'un script lancé automatiquement (au démarrage ou en cron), ajouter une ligne de ce genre au début du script: exec >/tmp/<nom_du_script>.log 2>&1[/CODE] Suffira ensuite d'aller voir dans le fichier log ce qui a coincé. 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
sangorys Posté(e) le 31 octobre 2012 Auteur Partager Posté(e) le 31 octobre 2012 Merci pour tout ces précieux conseils Pour l'instant, mon problème n'est pas encore résolu. J'ai l'impression que mon syno ne lance pas les scripts de "/usr/local/etc/rc.d". D'ailleurs, je n'ai pas trouvé de fichier README.txt. Je continue mes tests et je vous tiens au courant... 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
sangorys Posté(e) le 3 janvier 2013 Auteur Partager Posté(e) le 3 janvier 2013 Mon problème a été résolu grâce à vous et grâce à un dernier truc que j'avais trouvé ! Malheureusement, je ne me rappelle plus le dernier truc que j'avais trouvé !!! Merci encore et si ça me revient, je mettrais ce post à jour 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Messages recommandés
Rejoindre la conversation
Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.