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

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)

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.

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 ?

Je dois avouer ne pas avoir la moindre idée de ce qu'est cette méthode "screen" de lancement.

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

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é le 19 janvier 201312 a par CoolRaoul

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.

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é le 19 janvier 201312 a par CoolRaoul

Autant pour moi...