Sous mdk 9.1, j'ai fait un script qui me fait la synchronisation de
certains répertoires entre mon portable et mon serveur.
Je veux que ce script se lance au démarrage et à l'extinction du
portable.
Dans ce script (synchrod) placé dans /etc/init.d , j'ai donc :
# chkconfig: 2345 98 01
et :
========== 8< =========================
case "$1" in
'start')
echo "Fonction (start)"
fct_synchro &
;;
'stop')
echo "Fonction (stop)"
fct_synchro
echo "fin (stop)"
;;
esac
exit 0
========== 8< =========================
En effet, je veux que la synchro au démarrage tourne en tâche de fond
non bloquante (d'où le &), mais que l'extinction attente que la synchro
soit faite.
J'ai fait un chkconfig --add synchrod
Et j'ai bien :
$ ls /etc/rc?.d/*synchrod
/etc/rc0.d/K01synchrod@ /etc/rc3.d/S98synchrod@ /etc/rc6.d/K01synchrod@
/etc/rc1.d/K01synchrod@ /etc/rc4.d/S98synchrod@ /etc/rc7.d/S98synchrod@
/etc/rc2.d/S98synchrod@ /etc/rc5.d/S98synchrod@
Pourtant, le script n'est jamais lancé à l'extinction, bien qu'il le
soit parfaitement au démarrage (aucun doute sur la fonction
fct_synchro() ).
Les fonctions "echo" sont redigirées vers un log par un exec en début
de script et la "fonction (stop)" n'y est jamais inscrite.
L'extinction étant testée par un "reboot" ou "halt" en ligne de commande.
comment on reboote la machine sur une mandrake ? avec "reboot" ou bien avec "shutdown -r now" ?
sur ma slack c'est "shutdown -r now"
ce que je fais :
- je renome shutdown (en shutdown2 , par exemple) - je créée un script to_do_before_shutdown.sh ( a mettre dans le PATH ) - je fais un script shell qui s'appelle shutdown ( et que je place dans le PATH )
#!/bin/zsh # oui j'utilise zsh quand je peux to_do_before_shutdown.sh shutdown -$0 $1
et voila .... bon je l'ai fait sur une ancienne distrib ( ya longtemps ) mais en tout cas ça marche .... Voila .
comment on reboote la machine sur une mandrake ?
avec "reboot" ou bien avec "shutdown -r now" ?
sur ma slack c'est "shutdown -r now"
ce que je fais :
- je renome shutdown (en shutdown2 , par exemple)
- je créée un script to_do_before_shutdown.sh ( a mettre dans le PATH )
- je fais un script shell qui s'appelle shutdown ( et que je place dans
le PATH )
#!/bin/zsh
# oui j'utilise zsh quand je peux
to_do_before_shutdown.sh
shutdown -$0 $1
et voila .... bon je l'ai fait sur une ancienne distrib ( ya longtemps )
mais en tout cas ça marche .... Voila .
comment on reboote la machine sur une mandrake ? avec "reboot" ou bien avec "shutdown -r now" ?
sur ma slack c'est "shutdown -r now"
ce que je fais :
- je renome shutdown (en shutdown2 , par exemple) - je créée un script to_do_before_shutdown.sh ( a mettre dans le PATH ) - je fais un script shell qui s'appelle shutdown ( et que je place dans le PATH )
#!/bin/zsh # oui j'utilise zsh quand je peux to_do_before_shutdown.sh shutdown -$0 $1
et voila .... bon je l'ai fait sur une ancienne distrib ( ya longtemps ) mais en tout cas ça marche .... Voila .
Dans le message <news:, *Christophe PEREZ* tapota sur f.c.o.l.configuration :
Mais ici se pose le problème des niveaux de priorité qui vu le type d'applicatif, doivent effectivement être différents selon le runlevel. Il faudra alors éventuellement créer manuellement les liens symboliques vers /etc/rc?.d.
Pas encore bien compris ça...
Qu'il s'agisse du démarrage ou de l'arrêt, les scripts lancés sur chacun des runlevels sont lancés dans un ordre précis et définis par ce qu'on appelle les niveaux de priorité. Si chkconfig est utilisé pour mettre en place le script, cela correspond alors aux deux valeurs numériques qui suit les runlevels sur la ligne chkconfig du script. La première valeur indique le niveau de priorité pour le démarrage, la deuxième valeur le niveau de priorité de l'arrêt. Une valeur faible aura pour conséquence de lancer le script avant ceux ayant une valeur plus élevée et inversement pour une valeur élevée. Dans votre cas, comme il s'agit de synchroniser des données au mieux, donc au démarrage le script doit être lancé après la majorité des services et à l'arrêt avant les autres. Or dans mon deuxième exemple de script, si on utilise chkconfig et si on utilise le niveau de priorité de lancement du script (start) à 98, le script sera effectivement lancé parmi les tous derniers scripts au démarrage mais aussi dans les tous derniers à l'arrêt. C'est pourquoi je vous conseillais de ne pas utiliser chkconfig pour ce deuxième script mais de créer manuellement les liens symboliques vers /etc/rc?.d. Ce qui donnerait par exemple :
Mais attention, parce qu'en fait à l'arrêt, les services qui sont à lancer, le sont après les services qui sont à stopper, alors que nous souhaitons lancer le script avant tout en premier. Finalement mon deuxième exemple de script s'adapte assez mal à votre cas. Vaut mieux se rabattre sur le premier exemple. ;)
J'espère avoir été clair. Ce qu'il faut c'est bien comprendre le mécanisme de lancement des scripts sur chacun des runlevels. Une lecture du script /etc/rc.d/rc pourrait peut être vous éclairer un peu plus.
-- TiChou
Dans le message <news:pan.2004.04.14.16.33.38.263789@novazur.fr>,
*Christophe PEREZ* tapota sur f.c.o.l.configuration :
Mais ici se pose le problème des niveaux de priorité qui vu le type
d'applicatif, doivent effectivement être différents selon le runlevel.
Il faudra alors éventuellement créer manuellement les liens symboliques
vers /etc/rc?.d.
Pas encore bien compris ça...
Qu'il s'agisse du démarrage ou de l'arrêt, les scripts lancés sur chacun des
runlevels sont lancés dans un ordre précis et définis par ce qu'on appelle
les niveaux de priorité. Si chkconfig est utilisé pour mettre en place le
script, cela correspond alors aux deux valeurs numériques qui suit les
runlevels sur la ligne chkconfig du script.
La première valeur indique le niveau de priorité pour le démarrage, la
deuxième valeur le niveau de priorité de l'arrêt. Une valeur faible aura
pour conséquence de lancer le script avant ceux ayant une valeur plus élevée
et inversement pour une valeur élevée.
Dans votre cas, comme il s'agit de synchroniser des données au mieux, donc
au démarrage le script doit être lancé après la majorité des services et à
l'arrêt avant les autres.
Or dans mon deuxième exemple de script, si on utilise chkconfig et si on
utilise le niveau de priorité de lancement du script (start) à 98, le script
sera effectivement lancé parmi les tous derniers scripts au démarrage mais
aussi dans les tous derniers à l'arrêt.
C'est pourquoi je vous conseillais de ne pas utiliser chkconfig pour ce
deuxième script mais de créer manuellement les liens symboliques vers
/etc/rc?.d.
Ce qui donnerait par exemple :
Mais attention, parce qu'en fait à l'arrêt, les services qui sont à lancer,
le sont après les services qui sont à stopper, alors que nous souhaitons
lancer le script avant tout en premier. Finalement mon deuxième exemple de
script s'adapte assez mal à votre cas. Vaut mieux se rabattre sur le premier
exemple. ;)
J'espère avoir été clair. Ce qu'il faut c'est bien comprendre le mécanisme
de lancement des scripts sur chacun des runlevels. Une lecture du script
/etc/rc.d/rc pourrait peut être vous éclairer un peu plus.
Dans le message <news:, *Christophe PEREZ* tapota sur f.c.o.l.configuration :
Mais ici se pose le problème des niveaux de priorité qui vu le type d'applicatif, doivent effectivement être différents selon le runlevel. Il faudra alors éventuellement créer manuellement les liens symboliques vers /etc/rc?.d.
Pas encore bien compris ça...
Qu'il s'agisse du démarrage ou de l'arrêt, les scripts lancés sur chacun des runlevels sont lancés dans un ordre précis et définis par ce qu'on appelle les niveaux de priorité. Si chkconfig est utilisé pour mettre en place le script, cela correspond alors aux deux valeurs numériques qui suit les runlevels sur la ligne chkconfig du script. La première valeur indique le niveau de priorité pour le démarrage, la deuxième valeur le niveau de priorité de l'arrêt. Une valeur faible aura pour conséquence de lancer le script avant ceux ayant une valeur plus élevée et inversement pour une valeur élevée. Dans votre cas, comme il s'agit de synchroniser des données au mieux, donc au démarrage le script doit être lancé après la majorité des services et à l'arrêt avant les autres. Or dans mon deuxième exemple de script, si on utilise chkconfig et si on utilise le niveau de priorité de lancement du script (start) à 98, le script sera effectivement lancé parmi les tous derniers scripts au démarrage mais aussi dans les tous derniers à l'arrêt. C'est pourquoi je vous conseillais de ne pas utiliser chkconfig pour ce deuxième script mais de créer manuellement les liens symboliques vers /etc/rc?.d. Ce qui donnerait par exemple :
Mais attention, parce qu'en fait à l'arrêt, les services qui sont à lancer, le sont après les services qui sont à stopper, alors que nous souhaitons lancer le script avant tout en premier. Finalement mon deuxième exemple de script s'adapte assez mal à votre cas. Vaut mieux se rabattre sur le premier exemple. ;)
J'espère avoir été clair. Ce qu'il faut c'est bien comprendre le mécanisme de lancement des scripts sur chacun des runlevels. Une lecture du script /etc/rc.d/rc pourrait peut être vous éclairer un peu plus.
-- TiChou
Bernard Déléchamp
Bonjour,
Bonsoir,
Sous mdk 9.1, j'ai fait un script qui me fait la synchronisation de certains répertoires entre mon portable et mon serveur. Je veux que ce script se lance au démarrage et à l'extinction du portable. Dans ce script (synchrod) placé dans /etc/init.d , j'ai donc :
[...]
Pourquoi ne pas, tout simplement, ajouter l'appel à ton script dans /etc/rc.sysinit ou /etc/rc.local pour le démarrage et dans /etc/init.d/halt pour l'extinction ?
Amicalement.
-- C'est grande pitié quand beauté manque à cul de bonne volonté. François Rabelais
Bonjour,
Bonsoir,
Sous mdk 9.1, j'ai fait un script qui me fait la synchronisation de
certains répertoires entre mon portable et mon serveur.
Je veux que ce script se lance au démarrage et à l'extinction du
portable.
Dans ce script (synchrod) placé dans /etc/init.d , j'ai donc :
[...]
Pourquoi ne pas, tout simplement, ajouter l'appel à ton script dans
/etc/rc.sysinit ou /etc/rc.local pour le démarrage et dans
/etc/init.d/halt pour l'extinction ?
Amicalement.
--
C'est grande pitié quand beauté manque à cul de bonne volonté.
François Rabelais
Sous mdk 9.1, j'ai fait un script qui me fait la synchronisation de certains répertoires entre mon portable et mon serveur. Je veux que ce script se lance au démarrage et à l'extinction du portable. Dans ce script (synchrod) placé dans /etc/init.d , j'ai donc :
[...]
Pourquoi ne pas, tout simplement, ajouter l'appel à ton script dans /etc/rc.sysinit ou /etc/rc.local pour le démarrage et dans /etc/init.d/halt pour l'extinction ?
Amicalement.
-- C'est grande pitié quand beauté manque à cul de bonne volonté. François Rabelais
TiChou
Dans le message <news:c5jvrl$32b$, *Bernard Déléchamp* tapota sur f.c.o.l.configuration :
Pourquoi ne pas, tout simplement, ajouter l'appel à ton script dans /etc/rc.sysinit ou /etc/rc.local pour le démarrage et dans /etc/init.d/halt pour l'extinction ?
Parce que, mis à part le script /etc/rc.local, ces scripts ne devraient jamais être modifiés, qu'ils ne sont pas prévus à cet usage et qu'en plus ils ne permettent pas de lancer son script au meilleur moment pour ne pas dire au bon moment.
-- TiChou
Dans le message <news:c5jvrl$32b$1@mangouin01430.delechamp.fam>,
*Bernard Déléchamp* tapota sur f.c.o.l.configuration :
Pourquoi ne pas, tout simplement, ajouter l'appel à ton script dans
/etc/rc.sysinit ou /etc/rc.local pour le démarrage et dans
/etc/init.d/halt pour l'extinction ?
Parce que, mis à part le script /etc/rc.local, ces scripts ne devraient
jamais être modifiés, qu'ils ne sont pas prévus à cet usage et qu'en plus
ils ne permettent pas de lancer son script au meilleur moment pour ne pas
dire au bon moment.
Dans le message <news:c5jvrl$32b$, *Bernard Déléchamp* tapota sur f.c.o.l.configuration :
Pourquoi ne pas, tout simplement, ajouter l'appel à ton script dans /etc/rc.sysinit ou /etc/rc.local pour le démarrage et dans /etc/init.d/halt pour l'extinction ?
Parce que, mis à part le script /etc/rc.local, ces scripts ne devraient jamais être modifiés, qu'ils ne sont pas prévus à cet usage et qu'en plus ils ne permettent pas de lancer son script au meilleur moment pour ne pas dire au bon moment.
-- TiChou
Christophe PEREZ
Le Wed, 14 Apr 2004 19:32:07 +0200, TiChou a écrit:
[...]
Dans votre cas, comme il s'agit de synchroniser des données au mieux, donc au démarrage le script doit être lancé après la majorité des services et à l'arrêt avant les autres.
Jusque là, je savais tout ça...
Or dans mon deuxième exemple de script, si on utilise chkconfig et si on utilise le niveau de priorité de lancement du script (start) à 98, le script sera effectivement lancé parmi les tous derniers scripts au démarrage mais aussi dans les tous derniers à l'arrêt.
Je n'avais effectivement pas tilté la dessus, sur le numéro d'ordre de lancement si tout était en Sxx...
C'est pourquoi je vous conseillais de ne pas utiliser chkconfig pour ce deuxième script mais de créer manuellement les liens symboliques vers /etc/rc?.d.
Bien sûr, logique.
Mais attention, parce qu'en fait à l'arrêt, les services qui sont à lancer, le sont après les services qui sont à stopper, alors que nous souhaitons lancer le script avant tout en premier. Finalement mon deuxième exemple de script s'adapte assez mal à votre cas. Vaut mieux se rabattre sur le premier exemple. ;)
Je crois aussi, et intuitivement, c'est le premier que j'aurais choisi, en gérant correctement ces verrous... D'ailleurs si c'est le principe "normal", c'est celui qu'il faut utiliser dans la mesure du possible, à mon sens. Je n'ai pas encore eu le temps de me plonger dedans pour l'instant.
J'espère avoir été clair.
Parfaitement. D'ailleurs, c'était certainement déjà clair mais moi qui n'avais pas pris le temps de lire correctement.
Ce qu'il faut c'est bien comprendre le mécanisme de lancement des scripts sur chacun des runlevels.
Je crois l'avoir à peu près compris jusqu'à maintenant ;-)
Une lecture du script /etc/rc.d/rc pourrait peut être vous éclairer un peu plus.
A l'occasion, oui, merci beaucoup pour tout.
-- Christophe PEREZ Écrivez moi sans _faute !
Le Wed, 14 Apr 2004 19:32:07 +0200, TiChou a écrit:
[...]
Dans votre cas, comme il s'agit de synchroniser des données au mieux,
donc au démarrage le script doit être lancé après la majorité des
services et à l'arrêt avant les autres.
Jusque là, je savais tout ça...
Or dans mon deuxième exemple de script, si on utilise chkconfig et si on
utilise le niveau de priorité de lancement du script (start) à 98, le script
sera effectivement lancé parmi les tous derniers scripts au démarrage mais
aussi dans les tous derniers à l'arrêt.
Je n'avais effectivement pas tilté la dessus, sur le numéro d'ordre de
lancement si tout était en Sxx...
C'est pourquoi je vous conseillais de ne pas utiliser chkconfig pour ce
deuxième script mais de créer manuellement les liens symboliques vers
/etc/rc?.d.
Bien sûr, logique.
Mais attention, parce qu'en fait à l'arrêt, les services qui sont à lancer,
le sont après les services qui sont à stopper, alors que nous souhaitons
lancer le script avant tout en premier. Finalement mon deuxième exemple de
script s'adapte assez mal à votre cas. Vaut mieux se rabattre sur le premier
exemple. ;)
Je crois aussi, et intuitivement, c'est le premier que j'aurais choisi, en
gérant correctement ces verrous...
D'ailleurs si c'est le principe "normal", c'est celui qu'il faut utiliser
dans la mesure du possible, à mon sens.
Je n'ai pas encore eu le temps de me plonger dedans pour l'instant.
J'espère avoir été clair.
Parfaitement.
D'ailleurs, c'était certainement déjà clair mais moi qui n'avais pas
pris le temps de lire correctement.
Ce qu'il faut c'est bien comprendre le mécanisme
de lancement des scripts sur chacun des runlevels.
Je crois l'avoir à peu près compris jusqu'à maintenant ;-)
Une lecture du script
/etc/rc.d/rc pourrait peut être vous éclairer un peu plus.
Le Wed, 14 Apr 2004 19:32:07 +0200, TiChou a écrit:
[...]
Dans votre cas, comme il s'agit de synchroniser des données au mieux, donc au démarrage le script doit être lancé après la majorité des services et à l'arrêt avant les autres.
Jusque là, je savais tout ça...
Or dans mon deuxième exemple de script, si on utilise chkconfig et si on utilise le niveau de priorité de lancement du script (start) à 98, le script sera effectivement lancé parmi les tous derniers scripts au démarrage mais aussi dans les tous derniers à l'arrêt.
Je n'avais effectivement pas tilté la dessus, sur le numéro d'ordre de lancement si tout était en Sxx...
C'est pourquoi je vous conseillais de ne pas utiliser chkconfig pour ce deuxième script mais de créer manuellement les liens symboliques vers /etc/rc?.d.
Bien sûr, logique.
Mais attention, parce qu'en fait à l'arrêt, les services qui sont à lancer, le sont après les services qui sont à stopper, alors que nous souhaitons lancer le script avant tout en premier. Finalement mon deuxième exemple de script s'adapte assez mal à votre cas. Vaut mieux se rabattre sur le premier exemple. ;)
Je crois aussi, et intuitivement, c'est le premier que j'aurais choisi, en gérant correctement ces verrous... D'ailleurs si c'est le principe "normal", c'est celui qu'il faut utiliser dans la mesure du possible, à mon sens. Je n'ai pas encore eu le temps de me plonger dedans pour l'instant.
J'espère avoir été clair.
Parfaitement. D'ailleurs, c'était certainement déjà clair mais moi qui n'avais pas pris le temps de lire correctement.
Ce qu'il faut c'est bien comprendre le mécanisme de lancement des scripts sur chacun des runlevels.
Je crois l'avoir à peu près compris jusqu'à maintenant ;-)
Une lecture du script /etc/rc.d/rc pourrait peut être vous éclairer un peu plus.
A l'occasion, oui, merci beaucoup pour tout.
-- Christophe PEREZ Écrivez moi sans _faute !
Christophe PEREZ
Le Wed, 14 Apr 2004 19:30:15 +0200, Rakotomandimby Mihamina a écrit:
#!/bin/zsh # oui j'utilise zsh quand je peux to_do_before_shutdown.sh shutdown -$0 $1
Mouais... C'est un peu bidouille quand même, et j'en fait déjà assez comme ça. Alors tant que je peux rester dans la normalité, j'essaye de me forcer un peu ;-) Mais merci quand même.
-- Christophe PEREZ Écrivez moi sans _faute !
Le Wed, 14 Apr 2004 19:30:15 +0200, Rakotomandimby Mihamina a écrit:
#!/bin/zsh
# oui j'utilise zsh quand je peux
to_do_before_shutdown.sh
shutdown -$0 $1
Mouais...
C'est un peu bidouille quand même, et j'en fait déjà assez comme ça.
Alors tant que je peux rester dans la normalité, j'essaye de me forcer un
peu ;-)
Mais merci quand même.
Le Wed, 14 Apr 2004 19:30:15 +0200, Rakotomandimby Mihamina a écrit:
#!/bin/zsh # oui j'utilise zsh quand je peux to_do_before_shutdown.sh shutdown -$0 $1
Mouais... C'est un peu bidouille quand même, et j'en fait déjà assez comme ça. Alors tant que je peux rester dans la normalité, j'essaye de me forcer un peu ;-) Mais merci quand même.
-- Christophe PEREZ Écrivez moi sans _faute !
Christophe PEREZ
Le Wed, 14 Apr 2004 20:28:04 +0200, Bernard Déléchamp a écrit:
Pourquoi ne pas, tout simplement, ajouter l'appel à ton script dans /etc/rc.sysinit ou /etc/rc.local pour le démarrage et dans /etc/init.d/halt pour l'extinction ?
C'est une idée aussi, mais en général, je préfère garder cet avantage de ces appels dans /etc/rcX.d/ que l'on peut gérer facilement avec chkconfig qui est justement fait pour ça.
Merci quand même ;-)
-- Christophe PEREZ Écrivez moi sans _faute !
Le Wed, 14 Apr 2004 20:28:04 +0200, Bernard Déléchamp a écrit:
Pourquoi ne pas, tout simplement, ajouter l'appel à ton script dans
/etc/rc.sysinit ou /etc/rc.local pour le démarrage et dans
/etc/init.d/halt pour l'extinction ?
C'est une idée aussi, mais en général, je préfère garder cet avantage
de ces appels dans /etc/rcX.d/ que l'on peut gérer facilement avec
chkconfig qui est justement fait pour ça.
Le Wed, 14 Apr 2004 20:28:04 +0200, Bernard Déléchamp a écrit:
Pourquoi ne pas, tout simplement, ajouter l'appel à ton script dans /etc/rc.sysinit ou /etc/rc.local pour le démarrage et dans /etc/init.d/halt pour l'extinction ?
C'est une idée aussi, mais en général, je préfère garder cet avantage de ces appels dans /etc/rcX.d/ que l'on peut gérer facilement avec chkconfig qui est justement fait pour ça.
Merci quand même ;-)
-- Christophe PEREZ Écrivez moi sans _faute !
no_spam
On Wed, 14 Apr 2004 11:28:43 -0400, Christophe PEREZ wrote:
Le Wed, 14 Apr 2004 09:26:26 +0200, no_spam a écrit:
Il a raison.
Ouf ! Merci ;-)
Halt et reboot sont juste des changement de runlevel vers les niveaux 0 et 6. Donc, si les scripts d'arrêt sont présent dans /etc/rc0.d/ et /etc/rc6.d/ et valides, il n'y a aucune utilité à les mettre autre part.
Et une idée alors du pourquoi il ne se lance pas ?
Sans doute un pb dans le script... Difficile d'en dire plus...
On Wed, 14 Apr 2004 11:28:43 -0400, Christophe PEREZ wrote:
Le Wed, 14 Apr 2004 09:26:26 +0200, no_spam a écrit:
Il a raison.
Ouf ! Merci ;-)
Halt et reboot sont juste des changement de runlevel vers les niveaux
0 et 6. Donc, si les scripts d'arrêt sont présent dans /etc/rc0.d/
et /etc/rc6.d/ et valides, il n'y a aucune utilité à les mettre
autre part.
Et une idée alors du pourquoi il ne se lance pas ?
Sans doute un pb dans le script... Difficile d'en dire plus...
On Wed, 14 Apr 2004 11:28:43 -0400, Christophe PEREZ wrote:
Le Wed, 14 Apr 2004 09:26:26 +0200, no_spam a écrit:
Il a raison.
Ouf ! Merci ;-)
Halt et reboot sont juste des changement de runlevel vers les niveaux 0 et 6. Donc, si les scripts d'arrêt sont présent dans /etc/rc0.d/ et /etc/rc6.d/ et valides, il n'y a aucune utilité à les mettre autre part.
Et une idée alors du pourquoi il ne se lance pas ?
Sans doute un pb dans le script... Difficile d'en dire plus...
Christophe PEREZ
Le Wed, 14 Apr 2004 17:09:09 -0400, Christophe PEREZ a écrit:
Je crois aussi, et intuitivement, c'est le premier que j'aurais choisi, en gérant correctement ces verrous...
Bon, tout est à priori maintenant parfait, avec juste quelques petites modifs :
- un rajout de service=${service#[SK]??} car sinon, le verrou était S98synchrod, et du coup, le K01synchrod n'effaçait pas le même.
- la ligne : gprintf "Starting %s service: " "$service" fct_synchro &
est devenue : gprintf "Starting %s service: " "$service" fct_synchro & J'avais juste la sortie : Starting synchrod service: Starting fct_synchro service: mais pas le lancement de la fonction fct_synchro
Il me reste maintenant à appliquer cette utilisation de verrou à mes autres scripts de démarrage qui, je ne savais pourquoi, se relançaient à chaque changement de niveau :-)
-- Christophe PEREZ Écrivez moi sans _faute !
Le Wed, 14 Apr 2004 17:09:09 -0400, Christophe PEREZ a écrit:
Je crois aussi, et intuitivement, c'est le premier que j'aurais choisi, en
gérant correctement ces verrous...
Bon, tout est à priori maintenant parfait, avec juste quelques petites
modifs :
- un rajout de
service=${service#[SK]??}
car sinon, le verrou était S98synchrod, et du coup, le K01synchrod
n'effaçait pas le même.
- la ligne :
gprintf "Starting %s service: " "$service" fct_synchro &
est devenue :
gprintf "Starting %s service: " "$service"
fct_synchro &
J'avais juste la sortie :
Starting synchrod service: Starting fct_synchro service:
mais pas le lancement de la fonction fct_synchro
Il me reste maintenant à appliquer cette utilisation de verrou à mes
autres scripts de démarrage qui, je ne savais pourquoi, se relançaient
à chaque changement de niveau :-)
Le Wed, 14 Apr 2004 17:09:09 -0400, Christophe PEREZ a écrit:
Je crois aussi, et intuitivement, c'est le premier que j'aurais choisi, en gérant correctement ces verrous...
Bon, tout est à priori maintenant parfait, avec juste quelques petites modifs :
- un rajout de service=${service#[SK]??} car sinon, le verrou était S98synchrod, et du coup, le K01synchrod n'effaçait pas le même.
- la ligne : gprintf "Starting %s service: " "$service" fct_synchro &
est devenue : gprintf "Starting %s service: " "$service" fct_synchro & J'avais juste la sortie : Starting synchrod service: Starting fct_synchro service: mais pas le lancement de la fonction fct_synchro
Il me reste maintenant à appliquer cette utilisation de verrou à mes autres scripts de démarrage qui, je ne savais pourquoi, se relançaient à chaque changement de niveau :-)
-- Christophe PEREZ Écrivez moi sans _faute !
Christophe PEREZ
Le Wed, 14 Apr 2004 23:32:28 +0200, no_spam a écrit:
Sans doute un pb dans le script... Difficile d'en dire plus...
Non non, comme trouvé par TiChou plus bas (haut? ;-) ), c'était une question de verrou dans /var/lock/subsys que je ne mettais pas.
Par conséquent, le script ne pouvait pas être "stoppé" puisqu'il n'avait pas été "démarré" selon le système.
-- Christophe PEREZ Écrivez moi sans _faute !
Le Wed, 14 Apr 2004 23:32:28 +0200, no_spam a écrit:
Sans doute un pb dans le script... Difficile d'en dire plus...
Non non, comme trouvé par TiChou plus bas (haut? ;-) ), c'était une
question de verrou dans /var/lock/subsys que je ne mettais pas.
Par conséquent, le script ne pouvait pas être "stoppé" puisqu'il n'avait
pas été "démarré" selon le système.
