# [boot sequence] Lancement automatique d'applications

## SpikeXtrem

Salut,

j'ai un Gentoo qui me sert de serveur. Je voudrais qu'à chaque démarrage, il lance un serveur teamspeak qui se lance par un script

Commandes:

```

rm /home/Mon_user/tss/server.pid

./home/Mon_user/tss/teamspeak start

```

La premiere commande est essentielle car si le programme quitte brutalement, au prochain boot, le fichier .pid va faire croire qu'il est toujours en marche et va refuser d'en demarrer un autre. Si je pouvais gérer ce serveur avec rc-update ca serait cool!

Puis j'ai un manager de download de newsgroup, appelé nzbget qui recoit des requetes et qui download les fichiers

qu'on appelle tout simplement par

```

nzbget

```

Le probleme avec ce dernier c'est qu'il a une interface ncurse qui permet de gérer les queues de download. Est-ce que c'est possible d'avoir accès a cette interface dans un environnement console? Je voudrais me passer de Gnome, Kde ou tout autre desktop environment.

Comment je fait pour que ces commandes soit exécuter par mon compte user (pas en root svp!) à chaque démarrage?

Et puis pour nzbget, est-ce possible d'avoir accès à l'interface qui gère les download queue? Sinon y doit avoir moyen de l'enlever dans la config...   :Embarassed: 

----------

## Ezka

Ca depends quand tu veux lancer tes applis. Si c'est lorsque tu te log sous ton compte tu peux mettre tes commandes dans : ~/.basrc

Pour teamspeak tu peux bidouiller le script de lancement pour qu'il kill tout les ts qui traine (pkill -9 teamspeakserver) et mettre ton rm a la suite. Mais a y réfléchir en lançant teamspeak restart ça te ferait pas ce que tu veux ?

nzbget je ne connais pas, peux pas t'aider la dessus.

----------

## Temet

Il me semble que ncurse passe en console (pis tu peux essayer avant de virer Gnome ou KDE)

Sinon, c'est "~/.bashrc"  :Wink: 

----------

## Magic Banana

Y-a-t'il un lien entre tes deux problèmes ? Peut-être serait-il judicieux d'éditer ton premier post pour ne garder que la première question et de mettre le reste dans un autre thread...

Pour ta première question, que penses-tu d'ajouter au début du start de ton script d'initialisation de teamspeak la ligne :

```
rm /home/Mon_user/tss/server.pid
```

Sinon je ne sais pas comment lancer au log d'un utilisateur des commandes automatiquement quel que soit l'environnement utilisé mais ça m'intéresse.

Aucune idée concernant nzbget non plus (en tout cas pas de USE flag permettant de modifier l'interface).

EDIT : Woa deux posts alors que j'éditais le mien. Après réflexion je plussoie le fait que ncurse est fait pour fonctionner en console. Sinon pour le .bashrc, ce qui me chagrine c'est que cela force les utilisateurs à utiliser bash pour avoir les scripts au démarrage de leur session. N'y aurait-il pas un moyen d'exécuter des commandes au log, quelque soit le shell utilisé ?

----------

## yoyo

Les rc-scripts local.start et local.stop ne sont pas fait pour ça par hasard ??

Enfin je ne sais pas avec quels droits ils seront exécutés mais bon, c'est peut-être une piste.

Enjoy !

EDIT : et les consoles gèrent parfaitement ncurses (enfin le menuconfig des kernel est bien en ncurses non ??)

----------

## SpikeXtrem

 *yoyo wrote:*   

> Les rc-scripts local.start et local.stop ne sont pas fait pour ça par hasard ??
> 
> Enfin je ne sais pas avec quels droits ils seront exécutés mais bon, c'est peut-être une piste.
> 
> Enjoy !
> ...

 

Local.start... ca sonne bien. il lance une série de commandes "maison" au démarrage?

Oui ncurses est fait pour console. (Meme sous kde ou gnome, j'utilise ce programme en console). La question portait plus sur : si le programme est lané automatiquement au démarrage, est-ce que je peux avoir accès au manager pour éditer les queues? Mais a bien y penser je crois que le programme n'est juste pas concu pour ca. Je veut un programme pour downloader sur les newsgroup et qui peux recevoir des queues de download venant de d'autres pc sur le réseau. En gros, les clients sont configurés pour envoyer la requete à mon serveur, puis celui-ci fait le download. Plutot bien comme principe. Mais si vous en connaissez un qui fait le meme boulot en console, ne vous gênez pas!

Mais la question du démarrage automatique persiste.

Pour clarifier, je veux que les 2 programmes démarrent au boot du pc, sans qu'aucun user ne se log. Pour les solutions que vous me donner, je vais essayer ce soir, je suis au travail.

A votre avis ca dérangerait pas coté sécurité d'utiliser les programmes en root? Mais je constate que par exemple svn, samba ou toutes autres applications tournent en root quand ils sont lancés au démarrage du pc, non?

----------

## Temet

Euh, comment tu veux lancer des programmes en user sans lancer de session utilisateur ? o_O'

Genre si t'as 3 users, le système il sait comment ce qu'il doit lancer pour qui et avec quels droit ?

Si tu te rabats sur le root, y a un howto pour faire des scripts rc (c'est assez simple).  :Wink: 

----------

## SpikeXtrem

 *Temet wrote:*   

> Euh, comment tu veux lancer des programmes en user sans lancer de session utilisateur ? o_O'
> 
> Genre si t'as 3 users, le système il sait comment ce qu'il doit lancer pour qui et avec quels droit ?
> 
> Si tu te rabats sur le root, y a un howto pour faire des scripts rc (c'est assez simple). 

 

bien il me semble que cotés droit d'accès, c'est pas merveilleux pour la protection des données. Pour le principe je sais pas, j'aurais pensé qu'un thread pourrait etre lancé pour un user même s'il est pas loggé... Une genre de session qui se lance automatiquement et qui démarre des taches. Mais j'avoue qu'a bien y penser ca semble pas très clean. L'idée était de restreindre les droits d'accès des programmes qui correspondraient à un user défini.

----------

## Temet

Bah disons qu'en principe (du moins dans mon esprit), si je lance un truc en tâche de fond avec un user spécifique, c'est que pour celui si s'en serve. Si t'as pas de session pour qu'il s'en serve ... j'avoue que j'ai du mal.

----------

## SpikeXtrem

 *Temet wrote:*   

> Bah disons qu'en principe (du moins dans mon esprit), si je lance un truc en tâche de fond avec un user spécifique, c'est que pour celui si s'en serve. Si t'as pas de session pour qu'il s'en serve ... j'avoue que j'ai du mal.

 

Je sais pas, s'il devient fou et qu'il se mette a deleter des fichiers essentiels au OS   :Razz: 

Mais j'avoue que c'est plus un probleme de programme que de droit d'accès a ce moment. C'est bon je suis convaincu   :Cool: 

----------

## geekounet

Pour teamspeak, ya un ebuild dans portage :

```
* media-sound/teamspeak2-server-bin 

     Available versions:  2.0.19.40 2.0.20.1 2.0.20.1-r1

     Homepage:            http://www.goteamspeak.com/

     Description:         The Teamspeak Voice Communication Server
```

Ya ptêt un script de lancement inclus, ça te règlerai au moins ce problème là  :Wink: 

----------

## SpikeXtrem

 *pierreg wrote:*   

> Pour teamspeak, ya un ebuild dans portage :
> 
> ```
> * media-sound/teamspeak2-server-bin 
> 
> ...

 

hm très bon point...

----------

## blasserre

 *SpikeXtrem wrote:*   

> j'aurais pensé qu'un thread pourrait etre lancé pour un user même s'il est pas loggé... Une genre de session qui se lance automatiquement et qui démarre des taches. 

 

pour ça au lieu de lancer 

```

# ton_prog
```

tu lance

```

# su ton_user -c ton_prog
```

----------

## Ezka

 *Quote:*   

> hm très bon point...

 

Yeup trés bon même puisque chez moi j'ai bien :

```
/etc/init.d/teamspeak2-server
```

Donc un coup de rc-update et il se lance en demon au démarrage ... et si jamais il vire pas .pid aprés un plantage et un reboot ou start (pas compliqué a simulé) tu peux trjs éditer le fichier init pour y mettre le rm machin.

----------

## blasserre

 *Ezka wrote:*   

> Donc un coup de rc-update et il se lance en demon au démarrage ... et si jamais il vire pas .pid aprés un plantage et un reboot ou start (pas compliqué a simulé) tu peux trjs éditer le fichier init pour y mettre le rm machin.

 

pour ça tu as le 

```
/etc/init.d/teamspeak2-server zap
```

----------

## Ezka

zap ? Ha tiens je connaissais pas !   :Embarassed: 

Ca fait quoi exactement ?

----------

## blasserre

 *Ezka wrote:*   

> zap ? Ha tiens je connaissais pas !  
> 
> Ca fait quoi exactement ?

 

ca fait tout ce que fait un stop hormis killer l'appli

virer le .pid, peut-être faire un peu de nettoyage ??

et ça te permet de redémarrer un démon proprement quand il a été arrêté salement

----------

## PabOu

moi il me semblait que le zap ne faisait QUE retirer l'appli de rc (c'est utile quand le script rc boggue et qu'on sait pas stopper ou restart l'appli alors qu'elle est déjà stoppée en fait).

----------

## blasserre

 *PabOu wrote:*   

> moi il me semblait que le zap ne faisait QUE retirer l'appli de rc (c'est utile quand le script rc boggue et qu'on sait pas stopper ou restart l'appli alors qu'elle est déjà stoppée en fait).

 

bon après quelques longueurs de runscript.sh, le zap nettoie les /var/lib/init.d/*/démon

et semble permettre le redémarrage du démon indépendamment de l'existence d'un /var/run/démon.pid qui est bêtement écrasé au start (testé avec sshd)

par contre, très fort, un kill 'tout court' de sshd supprime le sshd.pid... trop fort linux   :Cool: 

----------

## CryoGen

 *blasserre wrote:*   

>  *PabOu wrote:*   moi il me semblait que le zap ne faisait QUE retirer l'appli de rc (c'est utile quand le script rc boggue et qu'on sait pas stopper ou restart l'appli alors qu'elle est déjà stoppée en fait). 
> 
> bon après quelques longueurs de runscript.sh, le zap nettoie les /var/lib/init.d/*/démon
> 
> et semble permettre le redémarrage du démon indépendamment de l'existence d'un /var/run/démon.pid qui est bêtement écrasé au start (testé avec sshd)
> ...

 

Ben kill n'est pas une application qui tue violamment un thread (sauf le -9 / -KILL XD)

kill sert à envoyer des signaux à un thread, si le programme est bien codé, il "catch" le signal et execute la fonction associé (souvent un quit) ce qui permet à l'application de se quitter proprement et donc pourquoi pas (soyons fou) effacer son fichier .pid  :Wink: 

----------

## blasserre

 *CryoGen wrote:*   

>  *blasserre wrote:*    *PabOu wrote:*   moi il me semblait que le zap ne faisait QUE retirer l'appli de rc (c'est utile quand le script rc boggue et qu'on sait pas stopper ou restart l'appli alors qu'elle est déjà stoppée en fait). 
> 
> bon après quelques longueurs de runscript.sh, le zap nettoie les /var/lib/init.d/*/démon
> 
> et semble permettre le redémarrage du démon indépendamment de l'existence d'un /var/run/démon.pid qui est bêtement écrasé au start (testé avec sshd)
> ...

 

 :Embarassed:   :Embarassed:  trop bête le blazer ! mais j'ai des excuses, j'ai eu une dure journée   :Very Happy: 

----------

## spider312

Pour lancer au démarage une appli en user, cron est pas mal, il y a une syntaxe de crontab pour ça, un truc genre @reboot à la place des heures/minutes, etc.

Apparement, c'est 

```
@reboot /path/to/my/program
```

Sinon, simplement, lancer toutes les minutes un script qui teste l'existance d'un pid, s'il n'existe pas, lancer l'appli (mieux, puisque gère les plantages, mais faut pondre le script, enfin c'est pas dur avec un pgrep appli || appli, par exemple)

Pour lancer une appli ncurse et pouvoir la récupérer, le couteau suisse de l'admin est là : screen

```
screen -S nom_du_screen nzbget
```

 (avec "nom_du_screen" = ce que tu veux)

Suffit de faire lancer cette commande par cron, ou bien par ton script lui même lancé par cron

Puis pour le récupérer 

```
screen -R nom_du_screen
```

, pour quitter l'appli en la laissant tourner en fond : Ctrl+A puis D (j'utilise ce système pour faire tourner un client IRC ncurse (weechat) sur un serveur dédié que je loue, et pouvoir le récupérer de n'importe où, ça marche du tonnère)

Plus d'infos : formation debian d'Alexis de Lattre

----------

