Pourquoi l'option "splash" du chargement du noyau fait planter mon petit dém on ?
14 réponses
Francois Lafont
Bonjour à tous,
Je suis sous Linux Ubuntu 9.04 et j'ai petit démon dont la
fonction "start" fonctionne parfaitement en ligne de
commande, mais ne fonctionne pas correctement lors du
démarrage du poste.
Par contre, si dans "/boot/grub/menu.lst", je désactive
l'option splash du chargement du noyau, c'est-à-dire que,
dans l'item du menu sélectionné par défaut de grub, je mets ceci
alors tout fonctionne correctement au démarrage, exactement
comme en ligne de commande (sans que je ne touche un iota de
mon script de démon).
Avez vous une explication ? Je serais très curieux d'avoir
le fin mot de l'histoire car j'ai passé une bonne semaine
sur mon démon croyant qu'il était incorrect alors que ce
n'est finalement pas le cas (enfin j'espère).
Si j'ai bien compris "splash" c'est juste une option pour
afficher une jolie image pendant le démarrage au lieu des
messages en noir et blanc un peu austères. Je ne vois pas
pourquoi cela aurait une incidence sur mon démon ?
Merci d'avance pour votre aide. :-)
Si plus de détails sont nécessaire, en voici.
Voici mon démon (il lance une machine virtuelle de Virtualbox) :
PATH=/usr/sbin:/usr/bin:/sbin:/bin
NAME=ztest # le nom du fichier script
SCRIPTNAME="/etc/init.d/$NAME"
MANAGE_CMD=VBoxManage
START_CMD=VBoxHeadless
VM_OWNER=francois # le possesseur de la VM
VM_NAME="XPpro" # nom de la VM
# Pour faire un tracage du script
#set -x
# Pour lancer le demon
do_start()
{
# Return
# 0 --> le demon a demarre
# 1 --> le demon etait deja demarre
# 2 --> le demon n'a pas pu demarrer
# On verifie si la VM est deja en train de tourner
running=$(sudo -H -u $VM_OWNER $MANAGE_CMD showvminfo
"$VM_NAME" | grep "^State:.*running" | wc -l)
if [ $running -eq 1 ]
then
echo " * $VM_NAME is already
running..............................[ OK ]"
return 1
fi
# Si elle n'est pas encore allumee, on la lance.
nohup sudo -H -u $VM_OWNER $START_CMD --startvm
"$VM_NAME" --vrdp off > /dev/null 2>&1 &
# On verifie que la VM est bien lancee.
sleep 2
running=$(sudo -H -u $VM_OWNER $MANAGE_CMD showvminfo
"$VM_NAME" | grep "^State:.*running" | wc -l)
if [ $running -eq 0 ]
then
echo " * Failed to start
$VM_NAME..............................[ ERROR ]"
sleep 10 # Pour avoir le temps de voir le message
au demarrage
return 2
else
echo " * $VM_NAME
started..............................[ OK ]"
sleep 10 # Pour avoir le temps de voir le message
au demarrage
return 0
fi
}
# Pour arreter le demon
do_stop()
{
# sans intérêt pour le problème ici car c'est
# do_start qui est en cause
}
# Pour obtenir les statuts du demon
do_status()
{
sudo -H -u $VM_OWNER $MANAGE_CMD showvminfo "$VM_NAME"
| grep "^State:"
}
Avec l'option splash, la VM est bien lancée mais quand je
tape /etc/init.d/mon_demon status, cela m'indique que la VM
est sur off. Ça pose problème car dans ce cas la fonction
do_stop() n'éteint pas la VM proprement vu qu'elle pense que
celle-ci est éteinte. En revanche, sans l'option splash,
tout marche parfaitement. Pourquoi ? Quel rapport ?
J'ai lu le fil très en diagonale, mais je remarque que là :
# VBoxHeadless --startvm XPpro --vrdp off
XPpro n'est pas entre guillemets alors là :
# su francois -c "VBoxHeadless --startvm "XPpro" --vrdp off"
il l'est. A creuser ?
Hélas, je ne crois pas que le problème se situe là. En fait les guillements, c'est au cas où le nom de la VM ait des espaces, ce qui est indifférent dans mon cas vu que la VM s'appelle XPpro.
Justement :
si tu mets --startvm XPpro ou --startvm "XPpro" le paramètre XPpro (sans guillemets) sera passé à virtualbox par le shell si tu mets --startvm "XPpro" le paramètre "XPpro" (*avec* guillemets) sera passé à virtualbox par le shell. Et virtualbox cherchera le répertoire de configuration "XPpro" (avec guillemets, donc) qui n'existe pas.
PS: Les fichiers de configuration des machines se trouvent dans ~/.VirtualBox/Machines avec un sous-répertoire par machine.
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Le 10/05/2010 14:04, Francois Lafont a écrit :
J'ai lu le fil très en diagonale, mais je remarque que là :
# VBoxHeadless --startvm XPpro --vrdp off
XPpro n'est pas entre guillemets alors là :
# su francois -c "VBoxHeadless --startvm "XPpro" --vrdp off"
il l'est. A creuser ?
Hélas, je ne crois pas que le problème se situe là. En fait
les guillements, c'est au cas où le nom de la VM ait des
espaces, ce qui est indifférent dans mon cas vu que la VM
s'appelle XPpro.
Justement :
si tu mets --startvm XPpro ou --startvm "XPpro" le paramètre XPpro (sans guillemets) sera passé à virtualbox par le shell
si tu mets --startvm "XPpro" le paramètre "XPpro" (*avec* guillemets) sera passé à virtualbox par le shell. Et virtualbox
cherchera le répertoire de configuration "XPpro" (avec guillemets, donc) qui n'existe pas.
PS: Les fichiers de configuration des machines se trouvent dans ~/.VirtualBox/Machines avec un sous-répertoire par machine.
--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
J'ai lu le fil très en diagonale, mais je remarque que là :
# VBoxHeadless --startvm XPpro --vrdp off
XPpro n'est pas entre guillemets alors là :
# su francois -c "VBoxHeadless --startvm "XPpro" --vrdp off"
il l'est. A creuser ?
Hélas, je ne crois pas que le problème se situe là. En fait les guillements, c'est au cas où le nom de la VM ait des espaces, ce qui est indifférent dans mon cas vu que la VM s'appelle XPpro.
Justement :
si tu mets --startvm XPpro ou --startvm "XPpro" le paramètre XPpro (sans guillemets) sera passé à virtualbox par le shell si tu mets --startvm "XPpro" le paramètre "XPpro" (*avec* guillemets) sera passé à virtualbox par le shell. Et virtualbox cherchera le répertoire de configuration "XPpro" (avec guillemets, donc) qui n'existe pas.
PS: Les fichiers de configuration des machines se trouvent dans ~/.VirtualBox/Machines avec un sous-répertoire par machine.
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Francois Lafont
Sergio a écrit :
Justement :
si tu mets --startvm XPpro ou --startvm "XPpro" le paramètre XPpro (sans guillemets) sera passé à virtualbox par le shell si tu mets --startvm "XPpro" le paramètre "XPpro" (*avec* guillemets) sera passé à virtualbox par le shell. Et virtualbox cherchera le répertoire de configuration "XPpro" (avec guillemets, donc) qui n'existe pas.
D'accord, mais je persiste à penser que le problème n'est pas là. :-)
1) Déjà l'échappement des guillemets, je ne le fais pas comme tu l'écris ci-dessus. J'utilise l'échappement ici :
su $VM_OWNER -c "nohup $START_CMD --startvm "$VM_NAME" --vrdp off > /dev/null 2>&1 &"
qui devient
su francois -c "nohup VBoxHeadless --startvm "XPpro" --vrdp off > /dev/null 2>&1 &"
ce qui revient à dire « exécute en tant que francois cette commande là : nohup VBoxHeadless --startvm "XPpro" --vrdp off >/dev/null 2>&1 & » et donc les guillemets ne sont pas un problème.
2) Autre raison : comme je le disais au départ, le script que j'ai mis dans mon tout premier message marche a) en ligne de commande et b) au démarrage du PC à condition que le noyau soit chargé sans l'option splah. Si j'avais un problème avec les guillemets, ça ne marcherait jamais, je pense.
Pour être au clair sur ce dont on parle, je vous donne ci-dessous la totalité de mon script. (Même si, dans mon problème, on se moque complètement des fonctions do_stop et do_status car c'est do_start qui est en cause.)
http://sisco.laf.free.fr/codes/MyVM.txt (c'est le même script que dans mon premier message, sauf que j'ai changé les "sudo" pour des "su" comme me l'a suggéré Erwan David).
-- François Lafont
Sergio a écrit :
Justement :
si tu mets --startvm XPpro ou --startvm "XPpro" le paramètre XPpro (sans
guillemets) sera passé à virtualbox par le shell
si tu mets --startvm "XPpro" le paramètre "XPpro" (*avec* guillemets)
sera passé à virtualbox par le shell. Et virtualbox cherchera le
répertoire de configuration "XPpro" (avec guillemets, donc) qui n'existe
pas.
D'accord, mais je persiste à penser que le problème n'est
pas là. :-)
1) Déjà l'échappement des guillemets, je ne le fais pas
comme tu l'écris ci-dessus. J'utilise l'échappement ici :
su $VM_OWNER -c "nohup $START_CMD --startvm "$VM_NAME"
--vrdp off > /dev/null 2>&1 &"
qui devient
su francois -c "nohup VBoxHeadless --startvm "XPpro"
--vrdp off > /dev/null 2>&1 &"
ce qui revient à dire « exécute en tant que francois cette
commande là : nohup VBoxHeadless --startvm "XPpro" --vrdp
off >/dev/null 2>&1 & » et donc les guillemets ne sont pas
un problème.
2) Autre raison : comme je le disais au départ, le script
que j'ai mis dans mon tout premier message marche a) en
ligne de commande et b) au démarrage du PC à condition que
le noyau soit chargé sans l'option splah. Si j'avais un
problème avec les guillemets, ça ne marcherait jamais, je pense.
Pour être au clair sur ce dont on parle, je vous donne
ci-dessous la totalité de mon script. (Même si, dans mon
problème, on se moque complètement des fonctions do_stop et
do_status car c'est do_start qui est en cause.)
http://sisco.laf.free.fr/codes/MyVM.txt
(c'est le même script que dans mon premier message, sauf que
j'ai changé les "sudo" pour des "su" comme me l'a suggéré
Erwan David).
si tu mets --startvm XPpro ou --startvm "XPpro" le paramètre XPpro (sans guillemets) sera passé à virtualbox par le shell si tu mets --startvm "XPpro" le paramètre "XPpro" (*avec* guillemets) sera passé à virtualbox par le shell. Et virtualbox cherchera le répertoire de configuration "XPpro" (avec guillemets, donc) qui n'existe pas.
D'accord, mais je persiste à penser que le problème n'est pas là. :-)
1) Déjà l'échappement des guillemets, je ne le fais pas comme tu l'écris ci-dessus. J'utilise l'échappement ici :
su $VM_OWNER -c "nohup $START_CMD --startvm "$VM_NAME" --vrdp off > /dev/null 2>&1 &"
qui devient
su francois -c "nohup VBoxHeadless --startvm "XPpro" --vrdp off > /dev/null 2>&1 &"
ce qui revient à dire « exécute en tant que francois cette commande là : nohup VBoxHeadless --startvm "XPpro" --vrdp off >/dev/null 2>&1 & » et donc les guillemets ne sont pas un problème.
2) Autre raison : comme je le disais au départ, le script que j'ai mis dans mon tout premier message marche a) en ligne de commande et b) au démarrage du PC à condition que le noyau soit chargé sans l'option splah. Si j'avais un problème avec les guillemets, ça ne marcherait jamais, je pense.
Pour être au clair sur ce dont on parle, je vous donne ci-dessous la totalité de mon script. (Même si, dans mon problème, on se moque complètement des fonctions do_stop et do_status car c'est do_start qui est en cause.)
http://sisco.laf.free.fr/codes/MyVM.txt (c'est le même script que dans mon premier message, sauf que j'ai changé les "sudo" pour des "su" comme me l'a suggéré Erwan David).
-- François Lafont
Francois Lafont
Francois Lafont a écrit :
http://sisco.laf.free.fr/codes/MyVM.txt (c'est le même script que dans mon premier message, sauf que j'ai changé les "sudo" pour des "su" comme me l'a suggéré Erwan David).
Voici un lien vers le même code mais en couleur : http://sisco.laf.free.fr/codes/MyVM.html
-- François Lafont
Francois Lafont a écrit :
http://sisco.laf.free.fr/codes/MyVM.txt
(c'est le même script que dans mon premier message, sauf que j'ai changé
les "sudo" pour des "su" comme me l'a suggéré Erwan David).
Voici un lien vers le même code mais en couleur :
http://sisco.laf.free.fr/codes/MyVM.html
http://sisco.laf.free.fr/codes/MyVM.txt (c'est le même script que dans mon premier message, sauf que j'ai changé les "sudo" pour des "su" comme me l'a suggéré Erwan David).
Voici un lien vers le même code mais en couleur : http://sisco.laf.free.fr/codes/MyVM.html
-- François Lafont
Francois Lafont
Le 10/05/2010 16:23, Francois Lafont a écrit :
Francois Lafont a écrit :
Voici un lien vers le même code mais en couleur : http://sisco.laf.free.fr/codes/MyVM.html
Bon, je conclus ce fil car on va dire que le problème est résolu. Le script de démon donné en lien ci-dessus, quand il était exécuté sous Ubuntu 9.04, :
* marchait très bien en ligne de commande ;
* marchait très bien lors du boot (en tant que démon) à condition que l'option "splash" du chargement du noyau soit désactivée ou que l'on tape "CTRL+ALT+F1" au moment du boot pour voir tous les messages un peu austères sur l'écran en fond noir.
* ne marchait pas correctement lors d'un boot classique sur Ubuntu, c'est-à-dire avec l'option "splash".
J'ai upgradé ma distribution Ubuntu pour passer à la version 10.04, et là le même script fonctionne parfaitement dans tous les cas.
Du coup, je n'aurai pas le fin mot de l'histoire, mais disons que tout ceci m'incite à penser que mon script n'était pas vraiment en cause, et que ça concerne plus les arcanes d'Ubuntu. Du coup, je vais en rester là... :-)
Merci aux intervenants pour leur aide. A+
-- François Lafont
Le 10/05/2010 16:23, Francois Lafont a écrit :
Francois Lafont a écrit :
Voici un lien vers le même code mais en couleur :
http://sisco.laf.free.fr/codes/MyVM.html
Bon, je conclus ce fil car on va dire que le problème est
résolu. Le script de démon donné en lien ci-dessus, quand il
était exécuté sous Ubuntu 9.04, :
* marchait très bien en ligne de commande ;
* marchait très bien lors du boot (en tant que démon) à
condition que l'option "splash" du chargement du noyau soit
désactivée ou que l'on tape "CTRL+ALT+F1" au moment du boot
pour voir tous les messages un peu austères sur l'écran en
fond noir.
* ne marchait pas correctement lors d'un boot classique sur
Ubuntu, c'est-à-dire avec l'option "splash".
J'ai upgradé ma distribution Ubuntu pour passer à la version
10.04, et là le même script fonctionne parfaitement dans
tous les cas.
Du coup, je n'aurai pas le fin mot de l'histoire, mais
disons que tout ceci m'incite à penser que mon script
n'était pas vraiment en cause, et que ça concerne plus les
arcanes d'Ubuntu. Du coup, je vais en rester là... :-)
Voici un lien vers le même code mais en couleur : http://sisco.laf.free.fr/codes/MyVM.html
Bon, je conclus ce fil car on va dire que le problème est résolu. Le script de démon donné en lien ci-dessus, quand il était exécuté sous Ubuntu 9.04, :
* marchait très bien en ligne de commande ;
* marchait très bien lors du boot (en tant que démon) à condition que l'option "splash" du chargement du noyau soit désactivée ou que l'on tape "CTRL+ALT+F1" au moment du boot pour voir tous les messages un peu austères sur l'écran en fond noir.
* ne marchait pas correctement lors d'un boot classique sur Ubuntu, c'est-à-dire avec l'option "splash".
J'ai upgradé ma distribution Ubuntu pour passer à la version 10.04, et là le même script fonctionne parfaitement dans tous les cas.
Du coup, je n'aurai pas le fin mot de l'histoire, mais disons que tout ceci m'incite à penser que mon script n'était pas vraiment en cause, et que ça concerne plus les arcanes d'Ubuntu. Du coup, je vais en rester là... :-)