Aller au contenu

Lancer Un Programme Au D


declencher

Messages recommandés

Bonjour,

C'est surement une question de noob mais savez vous quelle est la solution la plus propre pour lancer un programme au démarrage du NAS ?

Je viens de finir un programme en C qui tourne H24, et pour l'instant le programme est très "verbeux" et je l'ai lancé avec screen. Mais par la suite, si je fais un programme "propre" qui n'écrit dans sa log qu'en cas d'erreur applicative, quel est la meilleur façon de le lancer au boot du syno ?

J'ai déjà un shell qui s'exécute au démarrage pour la téléinformation, mais là ça ne doit pas être pareil car mon, programme ne s'interrompant jamais, il ne doit pas empêcher la fin de l'exécution du shell...

Merci d'avance aux pro d'unix ;)

Lien vers le commentaire
Partager sur d’autres sites

Alors déjà les scripts de démarrage peuvent être à plusieurs endroit mais je te propose de le mettre dans /opt/rc.d/

Il doit au moins supporter les procédure start et stop

Pour ton programme qui tourne tt le temps dans l'ordre du moins vers le plus barbue

- lancer simplement ton programme dans un script de démarrage avec une esperluette a la fin (&) pour qu'il passe en tâche de fond cela fonctionne mais c pas super classe

- démarrer un screen dans un script de démarrage pour exécuter ton programme (screen -DmS monscreen macommande)

- modifier ton code pour qu'il devienne un daemon Linux (l'équivalent d'un services windows)

Lien vers le commentaire
Partager sur d’autres sites

Alors déjà les scripts de démarrage peuvent être à plusieurs endroit mais je te propose de le mettre dans /opt/rc.d/

petit bemol: "/opt/rc.d" est le répertoire des scripts de démarrage d'optware (que certains appellent ipkg ).

Ce dernier n'est pas forcément installé et, si ce n'est pas le cas, les scripts ne seront pas exécutés au boot.

Au contraire, "/usr/local/etc/rc.d", que je conseille d'utiliser dans est un répertoire pris en compte nativement par les procédure de démarrages de DSM.

D'accord par contre sur le reste du post.

Lien vers le commentaire
Partager sur d’autres sites

Mon script lancé au démarrage est déjà à cet emplacement. Je vais retenir la solution screen pour l'instant car c'est déjà comme ça que je lance mon prog.

Je vais faire quelques recherches côté service pour voir comment ça se code. Est ce que les appli du syno sont déclarées ainsi comme le serveur multimédia par exemple ?

Lien vers le commentaire
Partager sur d’autres sites

Je voulais dire que j'allais garder la solution exploitant screen comme le disait sp@ro ;)

Oki, pour ma part et comme ne ne sais absolument pas à peux bien servir cette commande "screen" (qui d'ailleurs n'est pas installée sur mon syno), pour lancer un programme , j'aurais tendance à choisir la première proposition de sp@ro qui me semble la plus simple, mettre dans ton script un truc du genre:

mon_programme >/var/log/mon_programme.log 2>&1 &

me semble tout simple et fonctionnel sans prise de tête.

Sinon il n'est pas très difficile de transformer ton programme en "démon", suffit qu'il se détache de lui même comme détaillé ici:

http://www.danielhall.me/2010/01/writing-a-daemon-in-c/

Ca t'économisera le "&" final et sera plus propre.

(prévoir une option qui désactive le passage en fond - souvent "-n" traditionnellement - peut être utile lors de la mise au point)

Modifié par CoolRaoul
Lien vers le commentaire
Partager sur d’autres sites

alors pour la petit histoire screen permet de créer un shell virtuel persistant que tu peut récupérer a tous moment, cela permet a toutes les applications qui ne sont pas des daemons de perdurer éternellement.

L'esperluette n'est pas élégante car le processus parent perdure indéfiniment (normal c'est pour cela que l'application continue de tourner) en soit ce n'est pas grave mais ce n'est pas très logique qu'une application utilise un processus parent sans raison (d'ailleurs certaines distribution ne le permette pas). screen en soit est une solution aussi sale mais au moins c'est fait pour...

Le fait de transformer une application en daemon offre d'autre avantage que le simple fait quelle perdure dans le temps notamment au niveau de la possibilité d'échanger des infos entre un script tiers et le daeomon par exemple.

Lien vers le commentaire
Partager sur d’autres sites

L'esperluette n'est pas élégante car le processus parent perdure indéfiniment

pas d'accord sur ce point

Demo:

fserv> cat fork.sh
#! /bin/sh
echo pid pere: $$
sleep 9999 &
echo pid fils=$! 

exécution:

fserv> ./fork.sh
pid pere: 1353
pid fils=1355

fserv> ps -p 1353
  PID TTY          TIME CMD
# on constate que le père est mort
fserv> ps -p 1355
  PID TTY          TIME CMD
1355 pts/0    00:00:00 sleep
# alors que le fils est toujours vivant
Modifié par CoolRaoul
Lien vers le commentaire
Partager sur d’autres sites

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.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.

×
×
  • 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.