Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Pourquoi l'option "splash" du chargement du noyau fait planter mon petit dém on ?

14 réponses
Avatar
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

#------------------------------
kernel /boot/vmlinuz-2.6.28-18-generic
root=UUID=2028abef-28d5-4a55-960f-8e86ea99c82b ro quiet
#------------------------------

au lieu de cela (j'ai enlevé splash)

#------------------------------
kernel /boot/vmlinuz-2.6.28-18-generic
root=UUID=2028abef-28d5-4a55-960f-8e86ea99c82b ro quiet splash
#------------------------------

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) :

#------------------------------
#! /bin/sh
### BEGIN INIT INFO
# Provides: ztest
# Required-Start: $local_fs $remote_fs vboxdrv vboxnet
# Required-Stop: $local_fs $remote_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: virtual machine
# Description: virtual machine hosted by VirtualBox
### END INIT INFO
#
# Author: Francois Lafont

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:"
}


case "$1" in
start)
do_start
;;
stop)
do_stop
;;
status)
do_status
;;
*)
echo "Usage: $SCRIPTNAME {start|stop|status}" >&2
exit 3
;;
esac
#------------------------------

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 ?



--
François Lafont

10 réponses

1 2
Avatar
Frédéric Perrin
Francois Lafont writes:
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 ?

# 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)



Est-il possible que sudo s'attende à avoir un terminal sur son stdin,
que l'option "splash" redirige stdin depuis /dev/null, et que sudo
n'apprécie pas cela ? As-tu essayé avec -S (ne pas essayer de lir e le
mot de passe sur le terminal) ?

--
Fred
Avatar
Erwan David
Frédéric Perrin écrivait :

Francois Lafont writes:
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 ?

# 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)



Est-il possible que sudo s'attende à avoir un terminal sur son stdin,
que l'option "splash" redirige stdin depuis /dev/null, et que sudo
n'apprécie pas cela ? As-tu essayé avec -S (ne pas essayer de lire le
mot de passe sur le terminal) ?



Faudrait surtout utiliser su plutôt que sudo...

Ou alors une crontab avec @reboot comme spécification du moment du lancement.

--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Avatar
Francois Lafont
Frédéric Perrin a écrit :

# 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)



Est-il possible que sudo s'attende à avoir un terminal sur son stdin,
que l'option "splash" redirige stdin depuis /dev/null, et que sudo
n'apprécie pas cela ? As-tu essayé avec -S (ne pas essayer de lire le
mot de passe sur le terminal) ?



Je viens de le faire. À la place des "sudo -H" dans mon
script, j'ai testé "sudo -S" et j'ai aussi testé "sudo -S
-H", mais dans les deux cas, la VM est bien lancée (et
accessible via le réseau), malheureusement une commande comme

~$ VBoxManage showvminfo "XPpro" | grep "^State:"

m'indique que la VM est sur off (ce qui est faux donc) et du
coup ça fait planter les fonctions do_stop et do_status du
démon.



--
François Lafont
Avatar
bruno666
Frédéric Perrin a écrit :

Francois Lafont writes:
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 ?

# 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)



Est-il possible que sudo s'attende à avoir un terminal sur son stdin,
que l'option "splash" redirige stdin depuis /dev/null, et que sudo
n'apprécie pas cela ? As-tu essayé avec -S (ne pas essayer de lire le
mot de passe sur le terminal) ?




Moi je m'interroge sur l'utilité de sudo (ou de su) dans un script d'init ?
Pourquoi est-ce nécessaire ?

Le souci avec usplash ne vient-il pas des messages renvoyés sur la con sole
avec les "echo" et les "sleep 10" ?

--
Bruno
Avatar
Frédéric Perrin
bruno666 <bruno+ writes:
Frédéric Perrin a écrit :
Est-il possible que sudo s'attende à avoir un terminal sur son
stdin, que l'option "splash" redirige stdin depuis /dev/null, et
que sudo n'apprécie pas cela ? As-tu essayé avec -S (ne pas es sayer
de lire le mot de passe sur le terminal) ?



Moi je m'interroge sur l'utilité de sudo (ou de su) dans un script
d'init ? Pourquoi est-ce nécessaire ?



Visiblement, pour lancer la VM avec les privilèges de "francois"
plut^ot que root. Lancer une commande sous l'identité d'un autre
utilisateur est précisément ce que sudo sait très bien faire.

--
Fred
Avatar
Francois Lafont
bruno666 a écrit :

Moi je m'interroge sur l'utilité de sudo (ou de su) dans un script d'init ?
Pourquoi est-ce nécessaire ?



Je m'explique. Virtualbox est une application graphique à la
base (même si elle admet des commandes pour démarrer en
ligne de commandes). Dans mon cas, Virtualbox a été
installée via le compte "francois" (mon compte). La machine
virtuelle "XPpro" a été installée sous ce compte et
appartient à "francois".

Dans mon démon, la commande utilisée pour lancer la VM est
VBoxHeadless. Si je l'utilise en tant que root directement
pour lancer la VM, voilà ce qu'il se passe :

#-------------------------------------------
# VBoxHeadless --startvm XPpro --vrdp off
Sun VirtualBox Headless Interface 3.1.6
(C) 2008-2010 Sun Microsystems, Inc.
All rights reserved.

Invalid machine name! # <-------
#-------------------------------------------

L'idée, je pense, c'est que root lui ne possède aucune VM
selon Virtualbox. Mais si je tape ceci en tant que root :

# su francois -c "VBoxHeadless --startvm "XPpro" --vrdp off"

alors la VM est bien lancée. C'est cette commande qu'utilise
mon démo. En fait, le démon lance la VM plus exactement
comme ceci (ajout de nohup et > /dev/null 2>&1 &) :

# su francois -c "nohup VBoxHeadless --startvm "XPpro"
--vrdp off > /dev/null 2>&1 &"

car sinon la commande VBoxHeadless ne redonne jamais la main
sur le prompt, sauf quand la VM finit par s'éteindre.

Le souci avec usplash ne vient-il pas des messages renvoyés sur la con sole
avec les "echo" et les "sleep 10" ?



Je viens de faire le test (j'ai commenté tous les sleep et
les echo de la fonction do_start), c'est toujours le même
problème : la VM est bien lancée au démarrage mais elle est
considérée comme éteinte par Virtualbox. Par exemple, en
tant que root, j'ai ceci :

# su francois -c "VBoxManage showvminfo XPpro | grep
"^State:""
State: powered off (since 2010-05-10T02:53:27)

(alors que la VM est accessible sur le réseau et j'ai même
la main dessus). Comme cette commande est à la base des
fonctions do_status et do_stop de mon démon, ça fait planter
l'arrêt du démon par exemple.



--
François Lafont
Avatar
Michael DENIS
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 ?

--
Michaël DENIS
Avatar
Francois Lafont
Michael DENIS 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.

À la base, le script met des guillemets partout (pour le cas
où la VM possède un nom avec espace). Bon par acquis de
conscience, j'ai quand même fait un test en enlevant les
guillemets. Dans le script, j'ai mis :

VM_NAME=XPpro

au lieu de l'ancien

VM_NAME="XPpro"

et là où j'avais un truc du genre

su $VM_OWNER -c "nohup $START_CMD --startvm "$VM_NAME"
--vrdp off > /dev/null 2>&1 &"

j'ai mis ceci :

su $VM_OWNER -c "nohup $START_CMD --startvm $VM_NAME --vrdp
off > /dev/null 2>&1 &"

Hélas, c'est toujours le même problème.
Merci quand même pour la suggestion. :-)


--
François Lafont
Avatar
Francois Lafont
Je crois que j'ai une piste, mais ça dépasse mais
compétence. Peut-être que parmi vous, certains auront une idée.

Dans la fonction do_start du démon, il y a pas mal de
fioritures et au final la ligne qui lance la VM est celle-ci :

su $VM_OWNER -c "nohup $START_CMD --startvm "$VM_NAME"
--vrdp off > /dev/null 2>&1 &"

(qui finalement devient après remplacement des variables ceci :
su francois -c "nohup VBoxHeadless --startvm "XPpro"
--vrdp off > /dev/null 2>&1 &")

Cette Instruction de Lancement, je l'appelle "IL" pour me
simplifier la vie.

Et bien, j'ai fait un test avec ceci :

#-----------------------------------
case "$1" in
start)
## do_start <---- on escamote do_start
su $VM_OWNER -c "nohup $START_CMD --startvm
"$VM_NAME" --vrdp off > /dev/null 2>&1 &"
;;
#-----------------------------------

Autrement dit, je me suis débarrasser de la fonction
do_start qui servait à appeler "IL" et j'ai mis directement
"IL". Et bien ça marche (avec l'option splah -- je rappelle
que le script marchait déjà sans l'option splash) ! La VM
est lancée et elle est bien reconnue par Virtualbox comme
étant en marche. Autrement dit, quand l'option splash est
activée, le fait de lancer la VM via une fonction pose
problème, mais si je la lance dans le script directement
(sans fonction) et bien là c'est ok.

Avez vous un début d'explication sur tout ça ?



--
François Lafont
Avatar
Francois Lafont
Francois Lafont a écrit :

Je crois que j'ai une piste, mais ça dépasse mais compétence.
[...]
Autrement dit, je me suis débarrasser de...



Oh, pardon pour l'orthographe ! :-(
Les prochaines fois, promis je me relis.

--
François Lafont
1 2