[Résolu] /etc/rc.local non exécuté au démarrage ?

Arbiel · Le 03/02/2015, à 19:01

Bonsoir à tous

J'essaie, sans succès, de faire exécuter quelques scripts au démarrage.
Pour tester, j'ai inséré dans /etc/rc.local un script pour afficher le nom de l'utilisateur dans un dialogue zenity, et ceci se passe bien si je tape la commande

. /etc/rc.local

Le nom de l'utilisateur est effectivement affiché dans une fenêtre zenity.

Par contre, ce n'est pas le cas lorsque j'exécute ce fichier par le biais de /etc/init.d/rc.local :

cat /etc/rc.local && . /etc/init.d/rc.local start
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
function qui_suis_je () {
		ti="exécution de rc.local"; te=15; l=220; h=60
		ty="--info"
		zenity ${ty} --title="${ti}" --timeout=${te} --width=${l} --height=${h} --no-wrap --text=${USER} ;
}
qui_suis_je
exit 0
/etc/rc.local: 13: /etc/rc.local: Syntax error: "(" unexpected

En retirant les () de "function qui_suis_je () {" (ligne 13), bash m'insulte différemment, mais m'insulte néanmoins

cat /etc/rc.local && . /etc/init.d/rc.local start
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
function qui_suis_je {
		ti="exécution de rc.local"; te=15; l=220; h=60
		ty="--info"
		zenity ${ty} --title="${ti}" --timeout=${te} --width=${l} --height=${h} --no-wrap --text=${USER} ;
}
qui_suis_je
exit 0
/etc/rc.local: 13: /etc/rc.local: function: not found

Merci d'avance à quiconque pourra me mettre sur la voix.

En attendant, je lance mes scripts par des lanceurs dans ~/.config/autostart avec l'inconvénient de devoir m'authentifier si nécessaire (sudo …)

Arbiel

Dernière modification par Arbiel (Le 06/02/2015, à 02:05)

gl38 · Le 03/02/2015, à 19:14

Pour ouvrir une fenêtre dans un script, il faut un environnement graphique. Est-ce bien le cas quand /etc/rc.local est exécuté ?
Tu devrais commencer par essayer par quelque chose du genre :

echo bonjour >/tmp/bonjour

Cordialement,
Guy

Arbiel · Le 03/02/2015, à 20:27

Le problème vient de l'erreur que bash trouve dans mon fichier /etc/rc.local lorsqu'il est appelé par la ligne

/etc/rc.local

du fichier /etc/init.d/rc.local dont le contenu est le suivant

#! /bin/sh
### BEGIN INIT INFO
# Provides:          rc.local
# Required-Start:    $all
# Required-Stop:
# Default-Start:     2 3 4 5
# Default-Stop:
# Short-Description: Run /etc/rc.local if it exist
### END INIT INFO


PATH=/sbin:/usr/sbin:/bin:/usr/bin

. /lib/init/vars.sh
. /lib/lsb/init-functions

do_start() {
	if [ -x /etc/rc.local ]; then
	        [ "$VERBOSE" != no ] && log_begin_msg "Running local boot scripts (/etc/rc.local)"
		/etc/rc.local
		ES=$?
		[ "$VERBOSE" != no ] && log_end_msg $ES
		return $ES
	fi
}

case "$1" in
    start)
	do_start
        ;;
    restart|reload|force-reload)
        echo "Error: argument '$1' not supported" >&2
        exit 3
        ;;
    stop)
        ;;
    *)
        echo "Usage: $0 start|stop" >&2
        exit 3
        ;;
esac

alors que bash ne trouve pas d'erreur lorsque je lance le script depuis un terminal ou depuis un lanceur dans ~/.config/autostart

jplemoine · Le 03/02/2015, à 20:33

gl38 a écrit :

Pour ouvrir une fenêtre dans un script, il faut un environnement graphique. Est-ce bien le cas quand /etc/rc.local est exécuté ?

Je pense comme gl38 qu'il n'y a pas d’environnement graphique au moment où rc.local est exécuté...
--> donc, pas de zenity possible.

Dans le cron, il y a une syntaxe particulière avec un truc du genre DISPLAY:0 : c'est peut-être pareil avec rc.local.

tiramiseb · Le 03/02/2015, à 21:49

Salut,

Le fichier /etc/rc.local est lu par l'interpréteur sh par défaut, qui est Dash sur Ubuntu.
Il faut donc respecter la syntaxe POSIX.
Si tu l'exécutais par "/etc/rc.local" au lieu de le charger dans le shell courant avec ". /etc/rc.local", tu t'en serais rendu compte

En l'occurrence, le mot-clé "function" est un bashisme, il faut juste enlever ce mot. Donc :

qui_suis_je () {
[...]
}

D'ailleurs c'est de la même manière que la fonction "do_start" est définie dans le fichier /etc/init.d/rc.local que tu cites toi-même

Enfin, même après correction de cette erreur, il reste deux problèmes :
1/ en effet, comme l'ont dit gl38 et jplemoine, rien ne s'affichera et ce pour deux raisons :
- la variable "DISPLAY" n'est pas définie lors de l'exécution zenity,
- aucune interface graphique n'est lancée quand ce fichier est exécuté ;
2/ lors de l'exécution de ce fichier, aucun utilisateur n'est connecté (ce qui est logique vu qu'aucune interface graphique n'est lancée).

Arbiel · Le 03/02/2015, à 23:43

Merci à vous trois pour vos conseils et explications.

J'avais introduit un message zenity dans mon test parce que le script que je veux exécuter peut aussi être utilisé lorsque la session est ouverte et que dans ce cadre là le message me semble plus ergonomique. J'ai maintenant ajouté un paramètre qui conditionne cet affichage, mais je ne crois pas que cela ait beaucoup d'importance.

J'avais été surpris par la définition de do_start, mais sans vraiment me rendre compte de la différence entre cette définition et celle des fonctions de mes scripts.

J'avais également fini par essayer "/etc/rc.local" dans un terminal et constaté que cela provoquait les mêmes erreurs que l'exécution de /etc/init.d/rc.local. Mais, bien évidemment, je n'avais pas su interpréter ce constat.

tiramiseb a écrit :

Le fichier /etc/rc.local est lu par l'interpréteur sh par défaut, qui est Dash sur Ubuntu.

Est-ce la raison pour laquelle la première ligne de /etc/init.d/rc.local est

#! /bin/sh

?
Que dois-je en conclure pour mon script ? Pour l'instant c'est un script bash (#! /bin/bash)

Pour l'instant, j'ai la certitude qu'il n'est pas exécuté par /etc/init.d/rc.local, où je l'appelle pourtant par

.  <chemin_accès> <paramètres>

J'en ai la certitude car j'ai laissé l'appel par le lanceur de ~/.config/autostart et que cet appel m'affiche le message zenity du déchiffrement, alors que si le déchiffrement avait été fait par rc.local, le message aurait été différent.

Arbiel

Edit

Plus de problème, avec

bash  <chemin_accès> <paramètres>

Dernière modification par Arbiel (Le 03/02/2015, à 23:51)

tiramiseb · Le 04/02/2015, à 08:40

le script que je veux exécuter peut aussi être utilisé lorsque la session est ouverte

Alors il ne faut pas utiliser /etc/rc.local. Ce fichier sert à lancer des commandes système, définies manuellement par l'administrateur, au démarrage de l'ordinateur uniquement.

Est-ce la raison pour laquelle la première ligne de /etc/init.d/rc.local est
#! /bin/sh

Oui : ce script est défini comme un script sh (donc respectant la syntaxe POSIX normée) et non un script bash.

Attention : il n'y a généralement pas d'espace après le point d'exclamation, évite d'en mettre

Pour l'instant, j'ai la certitude qu'il n'est pas exécuté par /etc/init.d/rc.local, où je l'appelle pourtant par
.  <chemin_accès> <paramètres>

Je recommence encore une fois : quand tu commences par un point, tu n'exécutes pas un script, tu intègres ses instructions au shell courant, comme si tu tapais directement les commandes. En d'autres termes :
- exécuter un script ou un programme, c'est créer un nouvel environnement d'exécution (faire un fork) et y lancer l'exécutable en question ;
- appeler un fichier avec le point devant, c'est demander au shell courant de lire et exécuter les commandes d'un fichier (le point est un synonyme de "source", voir la manpage de bash par exemple).

Par ailleurs, dans /etc/init.d/rc.local, ce script n'est pas appelé avec un point devant : il est bel et bien exécuté indépendamment. Ou alors tu as changé ce fichier depuis que tu l'as montré en #3, auquel cas je me dois de te rappeler une règle importante : on évite autant que possible de modifier les fichiers système.

J'en ai la certitude car j'ai laissé l'appel par le lanceur de ~/.config/autostart et que cet appel m'affiche le message zenity du déchiffrement, alors que si le déchiffrement avait été fait par rc.local, le message aurait été différent.

D'une part, je ne comprends pas ton explication de message qui aurait été différent et je pense que ton utilisation du terme "déchiffrement" est erronée : les commandes que tu nous montres ne travaillent sur aucun élément chiffré, c'est juste l'exécution d'une simple commande zenity.

D'autre part, je le répète, ce fichier est fait pour le démarrage de l'ordinateur, il ne faut pas l'appeler dans une config utilisateur.

Je pense qu'il faut que tu reprennes ton raisonnement depuis le début et que tu oublies complètement le fichier /etc/rc.local.

Je propose de te donner des pistes pour faire ce que tu veux, dans ce cas j'ai besoin de réponses aux questions suivantes :
- à quel moment précis, au démarrage, veux-tu exécuter des commandes ?
- quelles commandes veux-tu y exécuter ?
- ces commandes sont-elles à exécuter quel que soit l'utilisateur qui se connecte ?

Dans tous les cas :
- oublie l'« exécution » avec le point, ceci est une utilisation spécifique de fichiers par bash ;
- rien dans /etc ne doit être lié à un utilisateur ;
- quand on fait un script système, on se cantonne autant que possible à la syntaxe POSIX normée.

Plus de problème, avec
bash  <chemin_accès> <paramètres>

Bien sûr, vu que cette fois-ci tu exécutes explicitement Bash, en lui donnant le fichier à exécuter comme argument : dans ce cas, le système n'utilise pas le shebang pour trouver quelle est la commande à exécuter, vu que tu as toi-même exécuté Bash.

Dernière modification par tiramiseb (Le 04/02/2015, à 08:41)

Arbiel · Le 06/02/2015, à 02:02

Bonsoir

Le script que j'ai affiché dans cette discussion était destiné à des tests et n'a presque rien à voir avec les deux scripts que je veux insérer dans /etc/rc.local, ou là où je dois les mettre pour les exécuter à bon escient. Le seul rapport consiste en l'avertissement que je veux afficher à l'utilisateur en cas de problème et c'est la raison pour laquelle j'ai utilisé zenity dans le script de test.

Le premier script a comme effet d'inhiber le pavé tactile lorsque la souris est raccordée, et de le réactiver au débranchement de la souris. Je veux l'exécuter au démarrage, et au réveil puisque je suppose que l'hibernation et le passage en veille l'arrêtent probablement.

Le second script a pour but de déchiffrer automatiquement une partition chiffrée et de la monter. Je veux l'exécuter au démarrage, en dehors de tout contexte utilisateur, pour une partition nécessaire au bon fonctionnement de mon système (archives), mais aussi à l'intérieur d'un script pour atteindre des fichiers sur une partition chiffrée d'un disque externe (comptes). Dans cette seconde situation, il s'exécute dans un contexte utilisateur.

Les effets du script lancé au démarrage pour archives n'étant probablement pas affectés par le passage en veille, il est vraisemblablement suffisant de le lancer au démarrage seulement. Cependant, pour éviter l'occurrence d'erreurs, j'évite, dans ma dernière version, de déchiffrer une partition lorsqu'elle l'a déjà été, ou de la monter lorsqu'elle est déjà montée.

Ce script s'appuie sur le contenu des fichiers crypttab et fstab et invoque les commandes cryptdisks_start et mount. Les lignes de crypttab pour déchiffrement au démarrage permettent, par leur troisième champ, de désigner un fichier contenant la phrase de chiffrement. Pour éviter de saisir autant de phrases de chiffrement que de partitions concernées, j'ai initialement voulu utiliser ce troisième champ, mais je n'ai pas réussi à le faire, l'arborescence des fichiers n'étant pas encore constituée lors du traitement de crypttab ; je me suis ainsi heurté à la manière de référencer ce fichier, ce qui m'a conduit à demander de l'aide.

C'est pour ce script que je veux présenter à l'utilisateur la sortie de ces deux commandes. La sortie de cryptdisks_start dépend de "l'état" de la partition chiffrée, et c'est de ce message dont je parlais en disant

Arbiel a écrit :

J'en ai la certitude car j'ai laissé l'appel par le lanceur de ~/.config/autostart et que cet appel m'affiche le message zenity du déchiffrement, alors que si le déchiffrement avait été fait par rc.local, le message aurait été différent.

La sortie de cryptdisks_start, lors de la première exécution est la suivante

cryptdisks_start a écrit :

* Starting crypto disk...
* archives: INSECURE OWNER FOR /home/.archives, see /usr/share/doc/cryptsetup/README.Debian.
* archives: INSECURE OWNER GROUP FOR /home/.archives, see /usr/share/doc/cryptsetup/README.Debian.
* archives: INSECURE MODE FOR /home/.archives, see /usr/share/doc/cryptsetup/README.Debian.
* archives (starting)..
* archives (started)...
...done.

et mount n'émet aucun commentaire.
Par contre, les sorties de cryptdisks_start et de mount, lorsque le script s'exécute ultérieurement sont

cryptdisks_start a écrit :

* Starting crypto disk...
* archives: INSECURE OWNER FOR /home/.archives, see /usr/share/doc/cryptsetup/README.Debian.
* archives: INSECURE OWNER GROUP FOR /home/.archives, see /usr/share/doc/cryptsetup/README.Debian.
* archives: INSECURE MODE FOR /home/.archives, see /usr/share/doc/cryptsetup/README.Debian.
* archives (running)...
...done.

mount a écrit :

mount : /dev/mapper/archives est déjà monté ou /home/archives est occupé
mount : selon mtab, /dev/mapper/archives est déjà monté sur /home/archives

Bien évidemment rien n'est affiché lorsque le script est lancé par /rc.local, mais ce qui apparaît lors de l'exécution par le lanceur de .config/autostart permet de savoir si le premier appel s'est bien déroulé ou non.

Mon problème, à savoir comment faire exécuter un script par /rc.local, est maintenant résolu.

Merci encore.

Arbiel

tiramiseb · Le 06/02/2015, à 21:41

Dans tout ton machin il y a quelque chose qui me choque.
Tu parles de "déchiffrer automatiquement" un volume.
Comment un déchiffrement peut être automatique ? Tu stockes le mot de passe en clair sur un volume non chiffré ?

Arbiel · Le 07/02/2015, à 00:04

Je crois que tout te paraîtra clair à la lecture de mes fichiers /etc/crypttab et /etc/fstab.

Mon fichier /etc/crypttab contient les lignes suivantes

hm UUID=9c21b407-620d-4511-8e5f-41b621d57505 none luks,retry=3
archives UUID=6800b9e6-5907-4589-b658-4d5796536daf /home/.archives luks,noauto
comptes UUID=8357f4d4-7d39-4c35-8497-117bc0e007a7 /home/.comptes luks,noauto

et mon fichier /etc/fstab contient, entre autres, les lignes suivantes

/dev/mapper/hm /home ext4 defaults 0 2
/dev/mapper/archives /home/archives ext4 defaults,noauto,user 0 2
/dev/mapper/comptes /media/DonnÃ©es ext4 defaults,noauto,owner 0 0

Les fichiers qui contiennent les phrases de chiffrement sont dans /home. Celle-ci, chiffrée, est déchiffrée avec saisie de la phrase de chiffrement pendant la phase de démarrage, alors que les deux autres sont déchiffrées après que fstab a été exploitée, et donc quand les chemins /home/.archives et /home/.comptes ont été résolus.

Comme les commandes cryptdisks_start et mount de mon script nécessitent le passage en mode superutilisateur, j'ai également enregistré mon mot de passe de session dans un fichier de /home. J'ai dû retenir une solution de cette nature car ma partition / n'est pas chiffrée. J'ai comme objectif de la chiffrer dans le futur, et peut-être choisirai-je alors une autre solution.

Arbiel

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 03/02/2015, à 19:01

[Résolu] /etc/rc.local non exécuté au démarrage ?

#2 Le 03/02/2015, à 19:14

Re : [Résolu] /etc/rc.local non exécuté au démarrage ?

#3 Le 03/02/2015, à 20:27

Re : [Résolu] /etc/rc.local non exécuté au démarrage ?

#4 Le 03/02/2015, à 20:33

Re : [Résolu] /etc/rc.local non exécuté au démarrage ?

#5 Le 03/02/2015, à 21:49

Re : [Résolu] /etc/rc.local non exécuté au démarrage ?

#6 Le 03/02/2015, à 23:43

Re : [Résolu] /etc/rc.local non exécuté au démarrage ?

#7 Le 04/02/2015, à 08:40

Re : [Résolu] /etc/rc.local non exécuté au démarrage ?

#8 Le 06/02/2015, à 02:02

Re : [Résolu] /etc/rc.local non exécuté au démarrage ?

#9 Le 06/02/2015, à 21:41

Re : [Résolu] /etc/rc.local non exécuté au démarrage ?

#10 Le 07/02/2015, à 00:04

Re : [Résolu] /etc/rc.local non exécuté au démarrage ?

Pied de page des forums