Aller au contenu

StephWe

Membres
  • Compteur de contenus

    38
  • Inscription

  • Dernière visite

À propos de StephWe

  • Date de naissance 12/06/1976

Mon Profil

  • Sex
    Male

Visiteurs récents du profil

999 visualisations du profil

StephWe's Achievements

Newbie

Newbie (1/14)

0

Réputation sur la communauté

  1. Cela a fonctionné. L'astuce et le programme est génial. Pour l'erreur, c'est surement un copié/collé qui a mal tourné Voici ce que j'ai trouvé via WinSCP Par la suite, j'ai renommé avant de supprimer et ça ne bug plus Un très grand merci pour ton aide. Passe une bonne soirée a+
  2. Bonjour à tous, je vous explique mon problème. Après avoir installé Docker, j’ai installé l’image mongodb et un conteneur. Et cela a fonctionné toute la journée d’hier. Ce matin, j’ai essayé de localiser ou Docker sauvait les fichiers collection de mongodb. Et après plusieurs recherches sur le web, j’ai constaté que le dbpath était indispensable. J’ai inséré dans un conteneur dans une option un chemin vers un dossier. Mais cela n’a pas fonctionné. Par la suite, je ne sais via quelle ligne de commande ou autre (car j’ai fait plusieurs test en ssh), j’ai fait quelque chose qu’il ne fallait pas. Dès que je me connecte en ssh, et que je tape « ls -l / » dans le terminal, cela crée un gros bug qui n’est pas visible directement. Par contre, via le DSM, je n’ai plus de paquet installé dans le centre de paquet du DSM comme si je n’avais rien installé. Et par la suite, si je coupe ma connexion ssh et que j’ouvre une connexion via Putty, avant même de taper mon login, j’ai instantanément le message d’erreur « Network error : Software caused connection abort ». Après le redémarrage complet du Nas, les paquets sont à nouveaux disponibles et chaque programme fonctionne correctement. Mais si je me connecte en ssh et que je tape dans la console « ls -l », le problème revient. Voici un print screen du terminal avec le résultat de la commande ; de plus, il y a une chose étrange, il y a un deuxième dossier « var » avec un caractère bizarre à la fin. Quelqu'un a une idée du problème que je rencontre ?
  3. Salut, j'ai fait les modif comme ceci : is_running() { PID=$(get_pid) ! [ -z "$(pidof node | grep "^$PID$")" ] && ! [ -z "$(netstat -lnt | egrep ".*:1337" | awk -F' ' '{print $6}' | grep "^LISTEN$")" ] } Je suis dans le bon ? J'ai testé la commande nohup et cela fonctionne temps que je ne quitte pas le terminal. Mais d'après ceci : Voici ce que j'ai tapé : nas> nohup /usr/local/etc/rc.d/s0001_manage-nodeJS.sh start & nas> nohup: appending output to nohup.out nas> exit Tu as une idée sur le fait qu'après avoir tapé exit, le processus s'arrête ? PS : le site http://www.christopher.compagnon.name est vraiment génial merci pour le lien.
  4. J'ai été obligé de garder "-an" car "-l" prend trop de temps à charger dans la fonction is_running et le retour n'est jamais correct. Donc, j'ai réécrit la commande netstat et j'affiche uniquement le String (6ème colonne) si le résultat est égal à 'LISTEN' et si le port 1337 est ouvert dans la liste : nas> /usr/local/etc/rc.d/s0001_manage-nodeJS.sh stop Stopping node app ... Killing process 11291 Removing pid file Node app stopped nas> netstat -an | egrep ".*:1337" | awk -F' ' '{print $6}' | grep "^LISTEN$" nas> /usr/local/etc/rc.d/s0001_manage-nodeJS.sh start Starting node app ... Node app started with pid 12763 nas> netstat -an | egrep ".*:1337" | awk -F' ' '{print $6}' | grep "^LISTEN$" LISTEN nas> J'ai également réécrit la commande pidof et j'affiche uniquement le pid si il est égale au pid demandé dans le grep : nas> pidof node 12763 nas> pidof node | grep "12763" 12763 Donc, dans la fonction is_running (je n'ai pas oublié le not "!" au départ de la condition ) : Quand penses-tu ? is_running() { PID=$(get_pid) ! [ -z "$(pidof node | grep "^$PID$" && netstat -an | egrep ".*:1337" | awk -F' ' '{print $6}' | grep "^LISTEN$")" ] } J'ai rien trouvé qui pouvait me mettre sur la piste. Tu peux m'en dire plus ?
  5. Salut , pour vérifié le statut, voici ce que j'ai fait en utilisant les commandes pitof et netstat : is_running() { PID=$(get_pid) [ -z "$(pidof node | awk '{print $2}' | grep "^$PID$" && netstat -an | egrep ".*:1337" | awk '{print $2}' | grep "^$PID$")" ] } Donc, lancé manuellement via la console cela donne : nas> /usr/local/etc/rc.d/s0001_manage-nodeJS.sh stop Stopping node app ... Killing process 17292 Removing pid file Node app stopped nas> /usr/local/etc/rc.d/s0001_manage-nodeJS.sh status Node app stopped nas> /usr/local/etc/rc.d/s0001_manage-nodeJS.sh start Starting node app ... Node app started with pid 17391 nas> /usr/local/etc/rc.d/s0001_manage-nodeJS.sh status Node app running with pid 17391 Penses-tu que la fonction is_running peut être optimisé ou c'est bon comme cela ? Également, pour les testes. J'ai lancé le daemon nodsJS manuellement et si je quitte la console, le serveur nodeJS ne fonctionne plus. Sais-tu comment faire pour lancer le daemon nodsJS manuellement et quitté la console sans que le serveur nodeJS soit hors-service ? Je voudrais une solution pour éviter de redémarrer le nas . Vu comme ça, en effet . Sur un premier temps, je relance le serveur comme prévu. Comme ça, cela me permet de créer mon premier cron Par la suite, une fois que j'ai créé l'appli web, je ferais comme tu m'as dit car évidement, je ne voudrais pas me retrouver dans une des situations que tu as cités.
  6. Par contre je ne suis pas pour relancer un programme toutes les minutes s'il se plante, car s'il s'est planté, c'est surement pour une bonne raison, donc il faut mettre des limites (par exemple vérifier depuis combien de temps il est planté) La seule façon pour le serveur de planter est de ne pas initialiser une variable correctement, une erreur de syntaxe du code js ou (le pire), une lenteur dans l’exécution du script car même si le JavaScript est exécuté en lecture ligne par ligne (procédurale) la ligne 2 peut-être plus lente et la ligne 3 n'attend pas et le bug se produit (variable non initialé ou vide). Si le serveur nodeJS se plante, je le saurais coté client car la connexion au port sera fermé. Je m'enverrais un email directement et les clients auront un message avec un compte à rebours vers la reprise du serveur. Les clients connectés seront sauvés dans la db. Cette une sécurité que je met en place car le javascript est instable. Je sauve les données d'un array avec un json_encode (PHP) coté serveur qui devient un String dans un champ de la table et je recrée les array et object sans problème. Il faut impérativement que le serveur continue à tourner et que je règle le problème en parallèle.
  7. Oui, en effet. J'ai une seule erreur sur mes testes, c'est quand je vérifie le statut : nas> /usr/local/etc/rc.d/s0001_manage-nodeJS.sh status ps: invalid option -- 'a' BusyBox v1.16.1 (2015-11-12 18:01:52 CST) multi-call binary. Usage: ps Report process status Options: w Wide output Cela vient du ps aux : is_running() { PID=$(get_pid) ! [ -z "$(ps aux | awk '{print $2}' | grep "^$PID$")" ] } Je crois que ps n'est pas utilisé dans cette version du Shell. Tu as une idée ? Je voudrais également ajouter dans cette vérification, si le port est ouvert.
  8. En effet, je devrais peut-être créer un cron vers un autre script qui toutes les 60 sec., vérifie si le serveur nodeJS est lancé. Et donc, je préserve le script actuel tel qu'il est. Et je le relance dans le cas ou le serveur est hs. Tu as peut-être une autre idée (plus optimisé ou plus simple) pour créer le script qui surveille l'état du daemon nodeJS ?
  9. Dans les commentaires, il annonce ceci : # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 Ce que je ne comprend pas, donc, comment sont initialisées les variables $1 et $2 à la ligne 136 et 150 J'imagine qu'à la ligne 33, il y a un genre un array ou object. Peux-tu m'expliquer cette ligne stp ?
  10. Oui, en effet mais l'erreur ne vient pas de là et ni de la modification du script. J'avais redémarrer le serveur et par la suite, le navigateur m'affichait une erreur 404. Alors j'ai lancé manuellement par la console et j'ai fait une erreur La vrai erreur est que si le serveur (nas) redémarre, le fichier server.pid pose problème au démarrage du serveur nodeJS. A mon avis, le développeur a ajouté une condition inutile dans le script. J'ai regardé le script de plus prêt et à la ligne 83, la variable $FORCE_OP doit être égale à true alors qu'à la ligne 34, elle est initialisée à false par défaut. J'ai réglé le problème en initialisant la variable à true. Désolé pour le retour négatif .
  11. Re : j'ai un message d'erreur à la ligne 13 nas> node /usr/local/etc/rc.d/s0001_manage-nodeJS.sh start /usr/local/etc/rc.d/s0001_manage-nodeJS.sh:13 NODE_EXEC=$(which node) ^^^^ SyntaxError: Unexpected identifier at exports.runInThisContext (vm.js:73:16) at Module._compile (module.js:443:25) at Object.Module._extensions..js (module.js:478:10) at Module.load (module.js:355:32) at Function.Module._load (module.js:310:12) at Function.Module.runMain (module.js:501:10) at startup (node.js:129:16) at node.js:814:3
  12. Tu as raison, mon expression était mal placé. Elle s'utilise uniquement si l'on maîtrise le sujet (la syntaxe). Mais il y a plusieurs façons d’apprendre. Il est également possible de plonger la tête la première directement dans le code (C'est une expression qui convient le mieux pour ce que je veux expliquer ). A chaque fois que je rencontre un soucis inconnu, une définition très complète s'offre à moi avec d'autres choses en parallèles qui n'étaient pas forcement liés et qui m'ouvre l'esprit. De plus, j'ai gagné du temps dans l'optimisation de la syntaxe. La personne qui a développé ce script m'offre une vision plus large pour en créer d'autres Si je parle de cette façon, c'est parce-que je suis développeur et j'ai une logique qui me permet de réfléchir de cette façon. Enfin, je crois . J'ai fait la modification est cela a fonctionné. Je dois encore y compléter un plantage volontaire du serveur nodeJS et qu'il se relance automatiquement. Merci pour ton aide précieuse. J'avais pas vu ta dernière intervention. Je fais les modif.
  13. Re : Merci CoolRaoul, en effet. Mais je ne savais pas que l'on pouvait pré-configurer les sauts de ligne pour Unix directement dans Notepas++. J'ai installé le packet nodeJS, et j'ai créé un script avec le contenu suivant pour le serveur nodeJS : var http = require('http'); http.createServer(function (req, res) { res.writeHead(200, {'Content-Type': 'text/plain'}); res.end('Hello World\n'); }).listen(1337, '192.168.1.250'); console.log('Server running at http://192.168.1.250:1337/'); Via la console, j'ai bien un retour positif : nas> node /volume1/web/nodeJS_server-xxx-xxx/server.js Server running at http://192.168.1.250:1337/ Via le port 1337 (http://192.168.1.250:1337) sur le navigateur j'ai également un retour positif : Hello World Jusqu'ici tout vas bien. Pour évité de réinventer la roue, j'ai fait quelques recherche sur un éventuel script pour gérer le lancement de nodeJS et j'ai trouvé ceci https://github.com/chovy/node-startup/blob/master/init.d/node-app. Donc, j'ai créé et copié/collé le contenu dans le fichier /usr/local/etc/rc.d/s0001_manage-nodeJS.sh et également créé les sous-dossiers et fichier /pid et /log/server.log. Il ne faut pas créer le fichier server.pid car il stop le script avec le message d'erreur suivant : nas> ./s0001_manage-nodeJS.sh start ps: invalid option -- 'a' BusyBox v1.16.1 (2015-11-12 18:01:52 CST) multi-call binary. Usage: ps Report process status Options: w Wide output Node app stopped, but pid file exists J'ai modifié les variables suivante dans le fichier /usr/local/etc/rc.d/s0001_manage-nodeJS.sh : #!/bin/sh USER="root" NODE_ENV="production" PORT="1337" APP_DIR="/volume1/web/nodeJS_server-xxx-xxx" NODE_APP="server.js" CONFIG_DIR="$APP_DIR" PID_DIR="$APP_DIR/pid" PID_FILE="$PID_DIR/server.pid" LOG_DIR="$APP_DIR/log" LOG_FILE="$LOG_DIR/server.log" NODE_EXEC=$(which node) ############### J'ai rendu le fichier exécutable : nas> cd /usr/local/etc/rc.d/ nas> chmod +x s0001_manage-nodeJS.sh nas> chmod 0755 s0001_manage-nodeJS.sh nas> ls -l s0001_manage-nodeJS.sh -rwxr-xr-x 1 root root 3278 Jan 2 15:54 /usr/local/etc/rc.d/s0001_manage-nodeJS.sh J'ai lancé le script manuellement pour vérifier si il fonctionne. Voici les erreurs que j'ai en retour : nas> ./s0001_manage-nodeJS.sh start Starting node app ... ./s0001_manage-nodeJS.sh: line 170: sudo: not found cat: can't open '/volume1/web/nodeJS_server-xxx-xxx/pid/server.pid': No such file or directory Node app started with pid Pourquoi ne trouve-t-il pas la commande sudo ?
  14. En effet, je comprend mieux l'importance du PATH. Ce sont les répertoires dans lesquels le shell cherche la commande et la recherche se fait dans l'ordre des répertoires contenus dans la variable PATH. On peut également avoir depuis les sources une version plus récente de la commande dont l'exécutable se trouve dans un autre dossier. Alors il faut utiliser le chemin absolu et l'adjoindre au départ du PATH. Mais le PATH peut également inclure des répertoires dans les quels se trouve des fichiers à exécuter. Pour par exemple écrire un script qui sera exécuté via d'autres scripts (au boot, manuellement, en cron, etc ...) comme disait CoolRaoul. C'est génial merci pour toutes ces précisions.
  15. Ton problème peut venir de plusieurs choses, l'erreur la plus courante c'est de créer son script sous Windows (il ajoute des caractères de contrôle afin d'être moins compatible avec le reste du monde mais de le rester avec DOS). Si tu es sous Windows, tu peux utiliser notepad++ en spécifiant bien le format d'encodage (UTF-8 sans BOM) Oui, je suis sous Windows mais j'avais bien utilisé Notepad++ et sauver en UTF-8 sans BOM. Dans le passé, un administrateur m'avait parlé que Windows générait sur la première ligne un caractère genre retour à la ligne qui ne plaisait pas à Linux :) Comme tu me l'as conseillé, j'ai utilisé vi pour générer un nouveau fichier et cela à fonctionné du premier coup :) Je peux même le rééditer et sauver avec Notepad++. Tout d'abord, si tu veux vraiment que ton script soit lancé à chaque démarrage de ton NAS et qu'il se soit pas supprimé à chauqe upgrade du NAS, il vaut mieux le mettre dans le répertoire suivant (si ma mémoire est bonne): "/usr/local/etc/rc.d/" et lui donner un nom de la forme "S99Monscript.sh" avec comme structure : Super, comme ça je vais dans la bonne direction et cela me fait une base de script pour démarrer Pour ma part, je préconise de *toujours* spécifier le PATH *dans* le script, au début En rapport avec le PATH, si on l'ajoute dans le fichier, c'est uniquement parce-qu'il est possible d'inclure le fichier dans un autre fichier comme en PHP avec : include 'fichier.php'; J'essai de comprendre l'utilité. Au départ, je croyais qu'il était utile de redéfinir le PATH. Comme ça, en ligne de commande, je ne devait plus retrouver le bon dossier (cd /) et également, si j'étais dans le bon dossier, ne plus taper "./" mais directement le nom du fichier depuis n'importe où dans la racine. Peux-tu m'en dire plus ?
×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.