Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

executer un script au démarrage

athomas

Bonjour

Je suis actuellement sur un projet de système embarqué que j'ai basé sur un NAS modifié, certains connaissent peut etre : NSLU2 (de chez Linksys).
J'ai installé dessus une distribution basée sur Debian, et donc très proche également de Ubuntu.
Ce système ne dispose ni de disque dur, ni d'écran clavier souris ... il est totalement autonome, et piloté via ssh et une liaison RJ45.

J'ai créer mon programme en c++, et je voudrais que celui ci se lance automatiquement au démarrage du systeme (je ne pourrai plus interragir avec le système car celui-ci sera installé en bordure de route)

J'ai suivi de nombreux tutoriaux qui consistait à placer la commande (?) dans le fichier /etc/init.d/rc.local.

J'ai donc placé dans le fichieren question la commande /root/test-projet qui est le chemin absolu du fichier nommé (test-projet).

Si je suis ici , c'est que cela ne fonctionne pas, j'aurais donc aimé une manière pas-a-pas permettant d'executer mon programme dès le boot du système.

Merci d'avance de l'aide que vous pourrez m'apporter.

GutsdBlack

Pour faire bien les choses, les scripts sont à placer dans /etc/init.d/
Tu fais un petit lien symbolique dans /etc/rc2.d/ qui est le runlevel par défaut sur Debian.

Ton script doit commencer par un S majuscule pour lui indiquer de placer le paramètre en start pour être exécuté.

Edit : tu peux aussi utiliser update-rc.d

update-rc.d ton_script start 45 2 . place ton script en priorité 45 dans le runlevel 2 avec le paramètre start (ne pas oublier le point).

xelator

genre
nano /etc/init.d/ton_script
chmod +x /etc/init.d/ton_script
ls -s /etc/ini.d/ton_script /etc/rc2.d/S99ton_script

ou un truc du genre

et le script :
#!/bin/bash
commande &

Si ça marche pas y a toujours la méthode barbare que j'utilise :
dirctement un script dans rc2.d avec un chmod +x et voila

athomas

donc si j'ai bien compris, mon script ressemblerait a ceci ?

#!bin/bash
sh /root/test-projet

car dans un terminal , je tape "sh /root/test-projet pour lancer mon projet et cela fonctionne correctement.

Ai-je bien compris ?

PS : GutsdBlack , je n'ai pas tout compris à ta méthode, malgré qu'elle semble plus "propre".

xelator

#!bin/bash
sh /root/test-projet &

Je sais pas trop si ça change grand chose ... normalement ça laisse le système continuer si test-projet ne se fini pas.

GutsdBlack

athomas a écritPS : GutsdBlack , je n'ai pas tout compris à ta méthode, malgré qu'elle semble plus "propre".

Je reprend !
Ton script tu dois le placer absolument dans /etc/init.d/ton_script

Ensuite pour l'ajouter tu tapes : update-rc.d ton_script start 45 2 .

*start indique que ton script est en position start (démarrage)
* 45 indique qu'il a la position 45 par rapports aux autres scripts... c'es toi qui choisis qui démarre avant l'autre
* 2 indique le runlevel, une debian en mode normal démarre en runlevel 2
* C'est quoi un runlevel ?

Le système te marqueras un truc du genre :

Adding system startup for /etc/init.d/ton_script ...
   /etc/rc2.d/S45ton_script -> ../init.d/ton_script

Voilà ton script démarreras automatiquement au démarrage de ton pc à la position 45.

[supprimé]

Résumé méthode compliquée :

- Tu rends ton script executable

- Tu le place dans le répertoire /etc/init.d

- Tu crées un lien dans le répertoire /etc/rc2.d, lien dont le nom doit commencer par un S pour qu'il soit lancé ou par K pour être ignoré.

Méthode simple à tester :

- Tu places la commande de ton script dans le script "squelette" /etc/rc.local qui est le dernier script à être lu pendant la procédure de boot, après que le boot a effectué tous les scripts de /etc/init.d vers lesquels pointent les liens du fichier /etc/rc?.d (? selon niveau d'execution... 2 par défaut comme dit plus haut)

Dans /etc/rc.local, le script squelette, tu trouveras quelques lignes de com' Sinon dans /etc/init.d tu as un README, qui renvoie à http://www.debian.org/doc/debian-policy/#contents pour ce qui a trait à la procédure de boot.

[supprimé]

Désolé, j'aurais pu être plus précis, suis allé trop vite : http://www.debian.org/doc/debian-policy/ch-opersys.html#s-sysvinit

[supprimé]

xelator a écrit

#!bin/bash
sh /root/test-projet &

Je sais pas trop si ça change grand chose ... normalement ça laisse le système continuer si test-projet ne se fini pas.

L'esperluette "&" permet de placer une tâche de fond avant de rendre la main à l'utilisateur. Pour faire revenir la tâche au premier plan, "fg". Ne pas confondre avec "&&" qui vérifie le succès d'une tâche avant de passer à la suivante et ";" qui passe d'une tâche à l'autre sans vérifier s'il y a succès ou échec.

athomas

Merci bien !

Vos explications sont très claires et cela fonctionne ! en tout cas sur mon pc fixe. Demain je testerai sur le système embarqué.

En tout cas, je suis toujours épaté par les capacités des systèmes linux, tout est vraiment paramétrable jusque dans les détails...

[supprimé]

Vrai. Bash est un truc vraiment de fou.

Une dernière chose, il existe aussi la commande "exec" pour remplacer le shell courant par le programme indiqué. C'est plus propre que de lui demander "sh" si ta machine attend seule au bord de la route et n'a que ton prog à executer. Exemple simple :

$exec vim

Quand tu quittes vim, tu n'as rien derrière, il faut refaire un log.

athomas

Ok, merci bien,

En effet, exec semble plus propre ; car oui, de toute maniere, la système sera amorcé une fois situé dans son boitier de bord de route.
Il sera totalement autonome , et alimenté grâce à un bloc de batteries. Sa consommation totale n'était que de 5W !

[supprimé]

Tu m'as pas fait poster pour faire tourner un radar de la gendarmerie fonctionnant à l'énergie solaire par hasard ?

Désolé, mais le "exec" m'est revenu sur un pur coup de parano en me disant que le shell lancé par ton script devait bien appartenir à quelqu'un et que ce devait être "root"... ce qui m'a donné envie de pas laisser traîner une connexion en cas d'interruption du programme. Le plus important là-dedans demeurant que je suis parano, ce qui explique la question initiale de ce billet.

athomas

Bonjour,

Non, ne t'inquiète pas , ce n'est pas un radar, il s'agit d'un projet de détection de camions sur route forestière, qui est en fait un projet de fin d'étude destiné uniquement à des tests , sans aucune finalité commerciale ou autre ! :-)

C'est dingue les possibilités qu'offrent ce système, il s'agit du NAS NSLU2 (linksys). Un site entier, est dédié aux utilisations linux : http://www.nslu2-linux.org/
Ce produit coûte 80 euros (neuf) et se trouve sur price-minister aux alentours de 45 euros.

Il comprend 32Mo de ram interne, un processeur ARM cadencé à 266Mhz , 2 ports USB, 1 port RJ45. Il est livré à la base avec un petit programme lui permettant de remplir le rôle de NAS, mais on trouve assez facilement sur internet des images de distri linux qui tournent dessus. Nous avions installé la distri sur un disque dur USB, puis maintenant sur une clé USB et cela tourne plutôt bien. Reste maintenant à voir la durée de vie de la clé USB !

;-)

GutsdBlack

athomas a écritReste maintenant à voir la durée de vie de la clé USB !

Tu peux essayer par exemple une MagicStore 2 Go au format compactflash. C'est en fait un microdrive, un micro disque dur.

athomas

Merci pour l'info 😉