script : savoir si c'est la première exécution depuis le dernier démarrage
22 réponses
Francois Lafont
Bonjour à tous,
J'ai un script sur une Debian Squeeze qui s'exécute de temps en temps de
manière automatique (en fait à chaque fois que la fenêtre de connexion
apparaît, c'est-à-dire à chaque démarrage mais aussi après chaque
fermeture de session). L'exécution se fait via le compte root.
Je voudrais affiner le script pour qu'il se comporte légèrement
différemment suivant que l'exécution est la première depuis le dernier
démarrage ou non. Comment faire cela de manière fiable ?
J'avais pensé écrire un fichier « pipeau » dans /tmp, profitant du fait
que /tmp est vidé à chaque démarrage il me semble. Du coup, dans le
script, ça donnerait un truc dans le genre ça :
if [ -e /tmp/pipeau ]; then
# Alors ce n'est pas la première exécution
# depuis le dernier démarrage de la machine.
else
# Alors c'est la première exécution
# depuis le dernier démarrage de la machine.
# Du coup on crée le fichier.
touch /tmp/pipeau
fi
Mais je ne sais pas si c'est une bonne façon de faire :
1. Suis-je sûr que /tmp/pipeau sera effacé au prochain démarrage ?
2. Suis-je sûr qu'il ne peut pas être effacé à un moment donné alors
qu'il n'y a pas eu encore redémarrage ?
3. Lorsque je crée /tmp/pipeau, peut-être que ce fichier existe déjà
dans /tmp après tout (même si c'est hautement non probable) ?
Du coup, je me dis qu'on peut peut-être s'y prendre mieux que ça. :-)
if [ -e /tmp/pipeau ]; then # Alors ce n'est pas la première exécution # depuis le dernier démarrage de la machine. else # Alors c'est la première exécution # depuis le dernier démarrage de la machine. # Du coup on crée le fichier. touch /tmp/pipeau fi
Si deux occurences du script sont lancées en meme temps, elles peuvent toutes les deux tester l'existence de /tmp/pipeau avant que l'autre n'aie le temps de le créer. C'est un exemple de ce que l'on appelle "race condition", et qui est à la base d'un grand nombre de trous de sécurités, et, plus généralement, de bug. La solution est d'utiliser la possibilité qu'offre le noyau de jeter un programme qui lui demande de créer un fichier qui existe déjà:
if sh -c 'set -C; : > /tmp/pipeau' 2>/dev/null; then # c'est la première exécution else # c'est pas la première fi
Le set -C dit au shell de ne pas accepter les redirections vers un fichier existant. Je passe par un nouveau shell, parce que, au moins le dash avec lequel je teste panique lors de l'echec d'un > au lieu de juste renvoyer un code d'erreur pour la commande.
1. Suis-je sûr que /tmp/pipeau sera effacé au prochain démarrage ?
2. Suis-je sûr qu'il ne peut pas être effacé à un moment donné alors qu'il n'y a pas eu encore redémarrage ?
3. Lorsque je crée /tmp/pipeau, peut-être que ce fichier existe déjà dans /tmp après tout (même si c'est hautement non probable) ?
Pour toutes ces raisons, il est plus raisonnable de travailler ailleurs que dans /tmp. Tu peux te créer un répertoire ad-hoc quelque part dans /var, avec un script de boot qui l'efface (ou qui y monte un tmpfs). Ou profiter de /var/run qui sert à ce genre de choses.
Francois Lafont :
if [ -e /tmp/pipeau ]; then
# Alors ce n'est pas la première exécution
# depuis le dernier démarrage de la machine.
else
# Alors c'est la première exécution
# depuis le dernier démarrage de la machine.
# Du coup on crée le fichier.
touch /tmp/pipeau
fi
Si deux occurences du script sont lancées en meme temps, elles peuvent
toutes les deux tester l'existence de /tmp/pipeau avant que l'autre n'aie le
temps de le créer. C'est un exemple de ce que l'on appelle "race condition",
et qui est à la base d'un grand nombre de trous de sécurités, et, plus
généralement, de bug. La solution est d'utiliser la possibilité qu'offre le
noyau de jeter un programme qui lui demande de créer un fichier qui existe
déjà:
if sh -c 'set -C; : > /tmp/pipeau' 2>/dev/null; then
# c'est la première exécution
else
# c'est pas la première
fi
Le set -C dit au shell de ne pas accepter les redirections vers un fichier
existant. Je passe par un nouveau shell, parce que, au moins le dash avec
lequel je teste panique lors de l'echec d'un > au lieu de juste renvoyer un
code d'erreur pour la commande.
1. Suis-je sûr que /tmp/pipeau sera effacé au prochain démarrage ?
2. Suis-je sûr qu'il ne peut pas être effacé à un moment donné alors
qu'il n'y a pas eu encore redémarrage ?
3. Lorsque je crée /tmp/pipeau, peut-être que ce fichier existe déjà
dans /tmp après tout (même si c'est hautement non probable) ?
Pour toutes ces raisons, il est plus raisonnable de travailler ailleurs que
dans /tmp. Tu peux te créer un répertoire ad-hoc quelque part dans /var,
avec un script de boot qui l'efface (ou qui y monte un tmpfs). Ou profiter
de /var/run qui sert à ce genre de choses.
if [ -e /tmp/pipeau ]; then # Alors ce n'est pas la première exécution # depuis le dernier démarrage de la machine. else # Alors c'est la première exécution # depuis le dernier démarrage de la machine. # Du coup on crée le fichier. touch /tmp/pipeau fi
Si deux occurences du script sont lancées en meme temps, elles peuvent toutes les deux tester l'existence de /tmp/pipeau avant que l'autre n'aie le temps de le créer. C'est un exemple de ce que l'on appelle "race condition", et qui est à la base d'un grand nombre de trous de sécurités, et, plus généralement, de bug. La solution est d'utiliser la possibilité qu'offre le noyau de jeter un programme qui lui demande de créer un fichier qui existe déjà:
if sh -c 'set -C; : > /tmp/pipeau' 2>/dev/null; then # c'est la première exécution else # c'est pas la première fi
Le set -C dit au shell de ne pas accepter les redirections vers un fichier existant. Je passe par un nouveau shell, parce que, au moins le dash avec lequel je teste panique lors de l'echec d'un > au lieu de juste renvoyer un code d'erreur pour la commande.
1. Suis-je sûr que /tmp/pipeau sera effacé au prochain démarrage ?
2. Suis-je sûr qu'il ne peut pas être effacé à un moment donné alors qu'il n'y a pas eu encore redémarrage ?
3. Lorsque je crée /tmp/pipeau, peut-être que ce fichier existe déjà dans /tmp après tout (même si c'est hautement non probable) ?
Pour toutes ces raisons, il est plus raisonnable de travailler ailleurs que dans /tmp. Tu peux te créer un répertoire ad-hoc quelque part dans /var, avec un script de boot qui l'efface (ou qui y monte un tmpfs). Ou profiter de /var/run qui sert à ce genre de choses.
Doug713705
Le 10-05-2012, Francois Lafont nous expliquait dans fr.comp.os.linux.configuration :
Bonjour à tous,
Bonjour,
Mais je ne sais pas si c'est une bonne façon de faire :
Moi non plus.
1. Suis-je sûr que /tmp/pipeau sera effacé au prochain démarrage ?
Efface le toi même avec un script executé lors de l'extinction du système.
Les scripts d'init sont là pour ça (par contre ne m'en demande pas plus, je ne sais pas le faire sur une Debian).
2. Suis-je sûr qu'il ne peut pas être effacé à un moment donné alors qu'il n'y a pas eu encore redémarrage ?
Mets les droits qui vont bien dessus.
3. Lorsque je crée /tmp/pipeau, peut-être que ce fichier existe déjà dans /tmp après tout (même si c'est hautement non probable) ?
En toute logique tu devrais savoir ce qui se passe sur ton système, au moins dans les grande ligne.
La probabilité qu'un tel fichier existe reste faible si c'est toi qui en choisit le nom.
Plutôt que de créer un fichier /tmp/pipeau qui pourrait déjà exister, peut-être qu'un fichier /tmp/pipeau/mon_pipeau serait plus 'sûr' (disons encore moins probable).
-- Doug - Linux user #307925 - Slackware64 roulaize ;-) http://usenet-fr.chainon-marquant.org http://newsportal.chainon-marquant.org http://news.chainon-marquant.org
Le 10-05-2012, Francois Lafont nous expliquait dans
fr.comp.os.linux.configuration :
Bonjour à tous,
Bonjour,
Mais je ne sais pas si c'est une bonne façon de faire :
Moi non plus.
1. Suis-je sûr que /tmp/pipeau sera effacé au prochain démarrage ?
Efface le toi même avec un script executé lors de l'extinction du
système.
Les scripts d'init sont là pour ça (par contre ne m'en demande pas plus,
je ne sais pas le faire sur une Debian).
2. Suis-je sûr qu'il ne peut pas être effacé à un moment donné alors
qu'il n'y a pas eu encore redémarrage ?
Mets les droits qui vont bien dessus.
3. Lorsque je crée /tmp/pipeau, peut-être que ce fichier existe déjà
dans /tmp après tout (même si c'est hautement non probable) ?
En toute logique tu devrais savoir ce qui se passe sur ton système, au
moins dans les grande ligne.
La probabilité qu'un tel fichier existe reste faible si c'est toi qui
en choisit le nom.
Plutôt que de créer un fichier /tmp/pipeau qui pourrait déjà exister,
peut-être qu'un fichier /tmp/pipeau/mon_pipeau serait plus 'sûr'
(disons encore moins probable).
--
Doug - Linux user #307925 - Slackware64 roulaize ;-)
http://usenet-fr.chainon-marquant.org
http://newsportal.chainon-marquant.org
http://news.chainon-marquant.org
Le 10-05-2012, Francois Lafont nous expliquait dans fr.comp.os.linux.configuration :
Bonjour à tous,
Bonjour,
Mais je ne sais pas si c'est une bonne façon de faire :
Moi non plus.
1. Suis-je sûr que /tmp/pipeau sera effacé au prochain démarrage ?
Efface le toi même avec un script executé lors de l'extinction du système.
Les scripts d'init sont là pour ça (par contre ne m'en demande pas plus, je ne sais pas le faire sur une Debian).
2. Suis-je sûr qu'il ne peut pas être effacé à un moment donné alors qu'il n'y a pas eu encore redémarrage ?
Mets les droits qui vont bien dessus.
3. Lorsque je crée /tmp/pipeau, peut-être que ce fichier existe déjà dans /tmp après tout (même si c'est hautement non probable) ?
En toute logique tu devrais savoir ce qui se passe sur ton système, au moins dans les grande ligne.
La probabilité qu'un tel fichier existe reste faible si c'est toi qui en choisit le nom.
Plutôt que de créer un fichier /tmp/pipeau qui pourrait déjà exister, peut-être qu'un fichier /tmp/pipeau/mon_pipeau serait plus 'sûr' (disons encore moins probable).
-- Doug - Linux user #307925 - Slackware64 roulaize ;-) http://usenet-fr.chainon-marquant.org http://newsportal.chainon-marquant.org http://news.chainon-marquant.org
Doug713705
Le 10-05-2012, Francois Lafont nous expliquait dans fr.comp.os.linux.configuration :
Bonjour à tous,
Bonjour,
Mais je ne sais pas si c'est une bonne façon de faire :
Moi non plus.
1. Suis-je sûr que /tmp/pipeau sera effacé au prochain démarrage ?
Efface le toi même avec un script executé lors de l'extinction du système.
Les scripts d'init sont là pour ça (par contre ne m'en demande pas plus, je ne sais pas le faire sur une Debian).
2. Suis-je sûr qu'il ne peut pas être effacé à un moment donné alors qu'il n'y a pas eu encore redémarrage ?
Mets les droits qui vont bien dessus.
3. Lorsque je crée /tmp/pipeau, peut-être que ce fichier existe déjà dans /tmp après tout (même si c'est hautement non probable) ?
En toute logique tu devrais savoir ce qu'il se passe sur ton système, au moins dans les grande ligne.
La probabilité qu'un tel fichier existe reste faible si c'est toi qui en choisit le nom.
Plutôt que de créer un fichier /tmp/pipeau qui pourrait déjà exister, peut-être qu'un fichier /tmp/pipeau/mon_pipeau serait plus 'sûr' (disons encore moins probable).
-- Doug - Linux user #307925 - Slackware64 roulaize ;-) http://usenet-fr.chainon-marquant.org http://newsportal.chainon-marquant.org http://news.chainon-marquant.org
Le 10-05-2012, Francois Lafont nous expliquait dans
fr.comp.os.linux.configuration :
Bonjour à tous,
Bonjour,
Mais je ne sais pas si c'est une bonne façon de faire :
Moi non plus.
1. Suis-je sûr que /tmp/pipeau sera effacé au prochain démarrage ?
Efface le toi même avec un script executé lors de l'extinction du
système.
Les scripts d'init sont là pour ça (par contre ne m'en demande pas plus,
je ne sais pas le faire sur une Debian).
2. Suis-je sûr qu'il ne peut pas être effacé à un moment donné alors
qu'il n'y a pas eu encore redémarrage ?
Mets les droits qui vont bien dessus.
3. Lorsque je crée /tmp/pipeau, peut-être que ce fichier existe déjà
dans /tmp après tout (même si c'est hautement non probable) ?
En toute logique tu devrais savoir ce qu'il se passe sur ton système,
au moins dans les grande ligne.
La probabilité qu'un tel fichier existe reste faible si c'est toi qui
en choisit le nom.
Plutôt que de créer un fichier /tmp/pipeau qui pourrait déjà exister,
peut-être qu'un fichier /tmp/pipeau/mon_pipeau serait plus 'sûr'
(disons encore moins probable).
--
Doug - Linux user #307925 - Slackware64 roulaize ;-)
http://usenet-fr.chainon-marquant.org
http://newsportal.chainon-marquant.org
http://news.chainon-marquant.org
Le 10-05-2012, Francois Lafont nous expliquait dans fr.comp.os.linux.configuration :
Bonjour à tous,
Bonjour,
Mais je ne sais pas si c'est une bonne façon de faire :
Moi non plus.
1. Suis-je sûr que /tmp/pipeau sera effacé au prochain démarrage ?
Efface le toi même avec un script executé lors de l'extinction du système.
Les scripts d'init sont là pour ça (par contre ne m'en demande pas plus, je ne sais pas le faire sur une Debian).
2. Suis-je sûr qu'il ne peut pas être effacé à un moment donné alors qu'il n'y a pas eu encore redémarrage ?
Mets les droits qui vont bien dessus.
3. Lorsque je crée /tmp/pipeau, peut-être que ce fichier existe déjà dans /tmp après tout (même si c'est hautement non probable) ?
En toute logique tu devrais savoir ce qu'il se passe sur ton système, au moins dans les grande ligne.
La probabilité qu'un tel fichier existe reste faible si c'est toi qui en choisit le nom.
Plutôt que de créer un fichier /tmp/pipeau qui pourrait déjà exister, peut-être qu'un fichier /tmp/pipeau/mon_pipeau serait plus 'sûr' (disons encore moins probable).
-- Doug - Linux user #307925 - Slackware64 roulaize ;-) http://usenet-fr.chainon-marquant.org http://newsportal.chainon-marquant.org http://news.chainon-marquant.org
Lucas Levrel
Le 10 mai 2012, Francois Lafont a écrit :
1. Suis-je sûr que /tmp/pipeau sera effacé au prochain démarrage ?
Clairement non. Mon /tmp est plein de fichiers temporaires « anciens » (antérieurs au dernier démarrage) ; leur effacement est configurable (opensuse 11.2) en fonction de l'âge.
3. Lorsque je crée /tmp/pipeau, peut-être que ce fichier existe déjà dans /tmp après tout (même si c'est hautement non probable) ?
Il y a je crois une commande qui renvoie à tous les coups un nom libre dans tmp, mais je ne la connais pas. (Ça t'aide, hein !)
-- LL
Le 10 mai 2012, Francois Lafont a écrit :
1. Suis-je sûr que /tmp/pipeau sera effacé au prochain démarrage ?
Clairement non. Mon /tmp est plein de fichiers temporaires « anciens »
(antérieurs au dernier démarrage) ; leur effacement est configurable
(opensuse 11.2) en fonction de l'âge.
3. Lorsque je crée /tmp/pipeau, peut-être que ce fichier existe déjà
dans /tmp après tout (même si c'est hautement non probable) ?
Il y a je crois une commande qui renvoie à tous les coups un nom libre
dans tmp, mais je ne la connais pas. (Ça t'aide, hein !)
1. Suis-je sûr que /tmp/pipeau sera effacé au prochain démarrage ?
Clairement non. Mon /tmp est plein de fichiers temporaires « anciens » (antérieurs au dernier démarrage) ; leur effacement est configurable (opensuse 11.2) en fonction de l'âge.
3. Lorsque je crée /tmp/pipeau, peut-être que ce fichier existe déjà dans /tmp après tout (même si c'est hautement non probable) ?
Il y a je crois une commande qui renvoie à tous les coups un nom libre dans tmp, mais je ne la connais pas. (Ça t'aide, hein !)
-- LL
Luc.Habert.00__arjf
Lucas Levrel :
Il y a je crois une commande qui renvoie à tous les coups un nom libre dans tmp, mais je ne la connais pas. (Ça t'aide, hein !)
mktemp. Son option -d pour créer un répertoire temporaire est précieuse, c'est beaucoup moins prise de tete de se créer un répertoire temporaire et de bosser dedans à sa guise que de travailler directement dans /tmp.
Lucas Levrel :
Il y a je crois une commande qui renvoie à tous les coups un nom libre
dans tmp, mais je ne la connais pas. (Ça t'aide, hein !)
mktemp. Son option -d pour créer un répertoire temporaire est précieuse,
c'est beaucoup moins prise de tete de se créer un répertoire temporaire et
de bosser dedans à sa guise que de travailler directement dans /tmp.
Il y a je crois une commande qui renvoie à tous les coups un nom libre dans tmp, mais je ne la connais pas. (Ça t'aide, hein !)
mktemp. Son option -d pour créer un répertoire temporaire est précieuse, c'est beaucoup moins prise de tete de se créer un répertoire temporaire et de bosser dedans à sa guise que de travailler directement dans /tmp.
Luc.Habert.00__arjf
Mais en l'occurence, ça ne nous aide pas du tout parce qu'il faut que toutes les instances du script utilisent le meme nom.
Mais en l'occurence, ça ne nous aide pas du tout parce qu'il faut que toutes
les instances du script utilisent le meme nom.
Mais en l'occurence, ça ne nous aide pas du tout parce qu'il faut que toutes les instances du script utilisent le meme nom.
Francois Lafont
Le 10/05/2012 11:47, Luc Habert a écrit :
Si deux occurences du script sont lancées en meme temps, elles peuvent toutes les deux tester l'existence de /tmp/pipeau avant que l'autre n'aie le temps de le créer. C'est un exemple de ce que l'on appelle "race condition", et qui est à la base d'un grand nombre de trous de sécurités, et, plus généralement, de bug. La solution est d'utiliser la possibilité qu'offre le noyau de jeter un programme qui lui demande de créer un fichier qui existe déjà:
if sh -c 'set -C; : > /tmp/pipeau' 2>/dev/null; then # c'est la première exécution else # c'est pas la première fi
Le set -C dit au shell de ne pas accepter les redirections vers un fichier existant.
Ok mais j'ai un peu de mal à comprendre pourquoi ça enlève le problème de la simultanéité. Avec ton test, si j'ai bien compris, il y a tentative d'écriture du fichier /tmp/pipeau (en y insérant une chaîne de caractère vide d'ailleurs si je ne m'abuse). L'idée c'est que lorsqu'il y a tentative d'écriture dans un fichier, il ne peut avoir simultanéité car le noyau ne le permet pas, c'est ça ?
Je passe par un nouveau shell, parce que, au moins le dash avec lequel je teste panique lors de l'echec d'un > au lieu de juste renvoyer un code d'erreur pour la commande.
Que veux-tu dire par « panique » ? Si on a un code d'erreur en retour, c'est suffisant pour le test, non ? Pourquoi vouloir faire en sorte qu'il y ait « panique » ?
1. Suis-je sûr que /tmp/pipeau sera effacé au prochain démarrage ?
2. Suis-je sûr qu'il ne peut pas être effacé à un moment donné alors qu'il n'y a pas eu encore redémarrage ?
3. Lorsque je crée /tmp/pipeau, peut-être que ce fichier existe déjà dans /tmp après tout (même si c'est hautement non probable) ?
Pour toutes ces raisons, il est plus raisonnable de travailler ailleurs que dans /tmp. Tu peux te créer un répertoire ad-hoc quelque part dans /var, avec un script de boot qui l'efface
J'aurais bien aimé faire en sorte que le script se suffise à lui-même et ne pas faire intervenir un autre script.
(ou qui y monte un tmpfs).
Ah, monter un tmpfs peut être une bonne chose car là je suis sûr qu'à chaque redémarrage, je repars sur un répertoire vide. Un truc comme ça par exemple, ça irait ?
------------------------------------------------------- rep="xxxx/tmp" # pour le choix du répertoire... à méditer.
if ! mountpoint "$rep"; then mount -t tmpfs -o size=1M tmpfs "$rep" fi
if sh -c "set -C; : > '$rep/pipeau'" 2>/dev/null; then # c'est la première exécution else # c'est pas la première fi -------------------------------------------------------
Là, j'ai quand même la garantie d'avoir un "$rep" vide rien que pour moi à chaque démarrage, non ?
-- François Lafont
Le 10/05/2012 11:47, Luc Habert a écrit :
Si deux occurences du script sont lancées en meme temps, elles peuvent
toutes les deux tester l'existence de /tmp/pipeau avant que l'autre n'aie le
temps de le créer. C'est un exemple de ce que l'on appelle "race condition",
et qui est à la base d'un grand nombre de trous de sécurités, et, plus
généralement, de bug. La solution est d'utiliser la possibilité qu'offre le
noyau de jeter un programme qui lui demande de créer un fichier qui existe
déjà:
if sh -c 'set -C; : > /tmp/pipeau' 2>/dev/null; then
# c'est la première exécution
else
# c'est pas la première
fi
Le set -C dit au shell de ne pas accepter les redirections vers un fichier
existant.
Ok mais j'ai un peu de mal à comprendre pourquoi ça enlève le problème
de la simultanéité. Avec ton test, si j'ai bien compris, il y a
tentative d'écriture du fichier /tmp/pipeau (en y insérant une chaîne de
caractère vide d'ailleurs si je ne m'abuse). L'idée c'est que lorsqu'il
y a tentative d'écriture dans un fichier, il ne peut avoir simultanéité
car le noyau ne le permet pas, c'est ça ?
Je passe par un nouveau shell, parce que, au moins le dash avec
lequel je teste panique lors de l'echec d'un > au lieu de juste renvoyer un
code d'erreur pour la commande.
Que veux-tu dire par « panique » ? Si on a un code d'erreur en retour,
c'est suffisant pour le test, non ? Pourquoi vouloir faire en sorte
qu'il y ait « panique » ?
1. Suis-je sûr que /tmp/pipeau sera effacé au prochain démarrage ?
2. Suis-je sûr qu'il ne peut pas être effacé à un moment donné alors
qu'il n'y a pas eu encore redémarrage ?
3. Lorsque je crée /tmp/pipeau, peut-être que ce fichier existe déjà
dans /tmp après tout (même si c'est hautement non probable) ?
Pour toutes ces raisons, il est plus raisonnable de travailler ailleurs que
dans /tmp. Tu peux te créer un répertoire ad-hoc quelque part dans /var,
avec un script de boot qui l'efface
J'aurais bien aimé faire en sorte que le script se suffise à lui-même et
ne pas faire intervenir un autre script.
(ou qui y monte un tmpfs).
Ah, monter un tmpfs peut être une bonne chose car là je suis sûr qu'à
chaque redémarrage, je repars sur un répertoire vide. Un truc comme ça
par exemple, ça irait ?
-------------------------------------------------------
rep="xxxx/tmp" # pour le choix du répertoire... à méditer.
if ! mountpoint "$rep"; then
mount -t tmpfs -o size=1M tmpfs "$rep"
fi
if sh -c "set -C; : > '$rep/pipeau'" 2>/dev/null; then
# c'est la première exécution
else
# c'est pas la première
fi
-------------------------------------------------------
Là, j'ai quand même la garantie d'avoir un "$rep" vide rien que pour moi
à chaque démarrage, non ?
Si deux occurences du script sont lancées en meme temps, elles peuvent toutes les deux tester l'existence de /tmp/pipeau avant que l'autre n'aie le temps de le créer. C'est un exemple de ce que l'on appelle "race condition", et qui est à la base d'un grand nombre de trous de sécurités, et, plus généralement, de bug. La solution est d'utiliser la possibilité qu'offre le noyau de jeter un programme qui lui demande de créer un fichier qui existe déjà:
if sh -c 'set -C; : > /tmp/pipeau' 2>/dev/null; then # c'est la première exécution else # c'est pas la première fi
Le set -C dit au shell de ne pas accepter les redirections vers un fichier existant.
Ok mais j'ai un peu de mal à comprendre pourquoi ça enlève le problème de la simultanéité. Avec ton test, si j'ai bien compris, il y a tentative d'écriture du fichier /tmp/pipeau (en y insérant une chaîne de caractère vide d'ailleurs si je ne m'abuse). L'idée c'est que lorsqu'il y a tentative d'écriture dans un fichier, il ne peut avoir simultanéité car le noyau ne le permet pas, c'est ça ?
Je passe par un nouveau shell, parce que, au moins le dash avec lequel je teste panique lors de l'echec d'un > au lieu de juste renvoyer un code d'erreur pour la commande.
Que veux-tu dire par « panique » ? Si on a un code d'erreur en retour, c'est suffisant pour le test, non ? Pourquoi vouloir faire en sorte qu'il y ait « panique » ?
1. Suis-je sûr que /tmp/pipeau sera effacé au prochain démarrage ?
2. Suis-je sûr qu'il ne peut pas être effacé à un moment donné alors qu'il n'y a pas eu encore redémarrage ?
3. Lorsque je crée /tmp/pipeau, peut-être que ce fichier existe déjà dans /tmp après tout (même si c'est hautement non probable) ?
Pour toutes ces raisons, il est plus raisonnable de travailler ailleurs que dans /tmp. Tu peux te créer un répertoire ad-hoc quelque part dans /var, avec un script de boot qui l'efface
J'aurais bien aimé faire en sorte que le script se suffise à lui-même et ne pas faire intervenir un autre script.
(ou qui y monte un tmpfs).
Ah, monter un tmpfs peut être une bonne chose car là je suis sûr qu'à chaque redémarrage, je repars sur un répertoire vide. Un truc comme ça par exemple, ça irait ?
------------------------------------------------------- rep="xxxx/tmp" # pour le choix du répertoire... à méditer.
if ! mountpoint "$rep"; then mount -t tmpfs -o size=1M tmpfs "$rep" fi
if sh -c "set -C; : > '$rep/pipeau'" 2>/dev/null; then # c'est la première exécution else # c'est pas la première fi -------------------------------------------------------
Là, j'ai quand même la garantie d'avoir un "$rep" vide rien que pour moi à chaque démarrage, non ?
-- François Lafont
Francois Lafont
Le 10/05/2012 12:19, Doug713705 a écrit :
1. Suis-je sûr que /tmp/pipeau sera effacé au prochain démarrage ?
Efface le toi même avec un script executé lors de l'extinction du système.
Comme j'expliquais dans un message précédent, j'aimerais bien rendre le script auto-suffisant et ne pas faire intervenir autre chose.
-- François Lafont
Le 10/05/2012 12:19, Doug713705 a écrit :
1. Suis-je sûr que /tmp/pipeau sera effacé au prochain démarrage ?
Efface le toi même avec un script executé lors de l'extinction du
système.
Comme j'expliquais dans un message précédent, j'aimerais bien rendre le
script auto-suffisant et ne pas faire intervenir autre chose.
1. Suis-je sûr que /tmp/pipeau sera effacé au prochain démarrage ?
Efface le toi même avec un script executé lors de l'extinction du système.
Comme j'expliquais dans un message précédent, j'aimerais bien rendre le script auto-suffisant et ne pas faire intervenir autre chose.
-- François Lafont
Francois Lafont
Le 10/05/2012 12:25, Lucas Levrel a écrit :
Le 10 mai 2012, Francois Lafont a écrit :
1. Suis-je sûr que /tmp/pipeau sera effacé au prochain démarrage ?
Clairement non. Mon /tmp est plein de fichiers temporaires « anciens » (antérieurs au dernier démarrage) ; leur effacement est configurable (opensuse 11.2) en fonction de l'âge.
Ah, et bien j'apprends quelque chose car je pensais que /tmp était toujours vidé à chaque redémarrage.
-- François Lafont
Le 10/05/2012 12:25, Lucas Levrel a écrit :
Le 10 mai 2012, Francois Lafont a écrit :
1. Suis-je sûr que /tmp/pipeau sera effacé au prochain démarrage ?
Clairement non. Mon /tmp est plein de fichiers temporaires « anciens »
(antérieurs au dernier démarrage) ; leur effacement est configurable
(opensuse 11.2) en fonction de l'âge.
Ah, et bien j'apprends quelque chose car je pensais que /tmp était
toujours vidé à chaque redémarrage.
1. Suis-je sûr que /tmp/pipeau sera effacé au prochain démarrage ?
Clairement non. Mon /tmp est plein de fichiers temporaires « anciens » (antérieurs au dernier démarrage) ; leur effacement est configurable (opensuse 11.2) en fonction de l'âge.
Ah, et bien j'apprends quelque chose car je pensais que /tmp était toujours vidé à chaque redémarrage.
-- François Lafont
Marc Boyer
Le 10-05-2012, Francois Lafont a écrit :
Bonjour à tous,
J'ai un script sur une Debian Squeeze qui s'exécute de temps en temps de manière automatique (en fait à chaque fois que la fenêtre de connexion apparaît, c'est-à-dire à chaque démarrage mais aussi après chaque fermeture de session). L'exécution se fait via le compte root.
Je voudrais affiner le script pour qu'il se comporte légèrement différemment suivant que l'exécution est la première depuis le dernier démarrage ou non. Comment faire cela de manière fiable ?
J'avais pensé écrire un fichier « pipeau » dans /tmp, profitant du fait que /tmp est vidé à chaque démarrage il me semble. Du coup, dans le script, ça donnerait un truc dans le genre ça :
if [ -e /tmp/pipeau ]; then # Alors ce n'est pas la première exécution # depuis le dernier démarrage de la machine. else # Alors c'est la première exécution # depuis le dernier démarrage de la machine. # Du coup on crée le fichier. touch /tmp/pipeau fi
Mais je ne sais pas si c'est une bonne façon de faire :
1. Suis-je sûr que /tmp/pipeau sera effacé au prochain démarrage ?
2. Suis-je sûr qu'il ne peut pas être effacé à un moment donné alors qu'il n'y a pas eu encore redémarrage ?
3. Lorsque je crée /tmp/pipeau, peut-être que ce fichier existe déjà dans /tmp après tout (même si c'est hautement non probable) ?
Du coup, je me dis qu'on peut peut-être s'y prendre mieux que ça. :-)
Mon point de vue serait un peu différent: soit tu désires faire un truc vraiment fiable, et il faut insérer ta commande dans la liste des scripts exécutés au démarrage et à l'extinction de ta machine, soit tu veux rester en dehors, et de manière moins précise, tu peux par exemple comparer la date de création de ton fichier avec l'uptime de la machine.
Et je mettrais plutôt tout ça dans /etc
Marc Boyer -- À mesure que les inégalités regressent, les attentes se renforcent. François Dubet
Le 10-05-2012, Francois Lafont <francois.lafont@nospam.invalid> a écrit :
Bonjour à tous,
J'ai un script sur une Debian Squeeze qui s'exécute de temps en temps de
manière automatique (en fait à chaque fois que la fenêtre de connexion
apparaît, c'est-à-dire à chaque démarrage mais aussi après chaque
fermeture de session). L'exécution se fait via le compte root.
Je voudrais affiner le script pour qu'il se comporte légèrement
différemment suivant que l'exécution est la première depuis le dernier
démarrage ou non. Comment faire cela de manière fiable ?
J'avais pensé écrire un fichier « pipeau » dans /tmp, profitant du fait
que /tmp est vidé à chaque démarrage il me semble. Du coup, dans le
script, ça donnerait un truc dans le genre ça :
if [ -e /tmp/pipeau ]; then
# Alors ce n'est pas la première exécution
# depuis le dernier démarrage de la machine.
else
# Alors c'est la première exécution
# depuis le dernier démarrage de la machine.
# Du coup on crée le fichier.
touch /tmp/pipeau
fi
Mais je ne sais pas si c'est une bonne façon de faire :
1. Suis-je sûr que /tmp/pipeau sera effacé au prochain démarrage ?
2. Suis-je sûr qu'il ne peut pas être effacé à un moment donné alors
qu'il n'y a pas eu encore redémarrage ?
3. Lorsque je crée /tmp/pipeau, peut-être que ce fichier existe déjà
dans /tmp après tout (même si c'est hautement non probable) ?
Du coup, je me dis qu'on peut peut-être s'y prendre mieux que ça. :-)
Mon point de vue serait un peu différent: soit tu désires faire
un truc vraiment fiable, et il faut insérer ta commande dans la
liste des scripts exécutés au démarrage et à l'extinction de
ta machine, soit tu veux rester en dehors, et de manière moins
précise, tu peux par exemple comparer la date de création de
ton fichier avec l'uptime de la machine.
Et je mettrais plutôt tout ça dans /etc
Marc Boyer
--
À mesure que les inégalités regressent, les attentes se renforcent.
François Dubet
J'ai un script sur une Debian Squeeze qui s'exécute de temps en temps de manière automatique (en fait à chaque fois que la fenêtre de connexion apparaît, c'est-à-dire à chaque démarrage mais aussi après chaque fermeture de session). L'exécution se fait via le compte root.
Je voudrais affiner le script pour qu'il se comporte légèrement différemment suivant que l'exécution est la première depuis le dernier démarrage ou non. Comment faire cela de manière fiable ?
J'avais pensé écrire un fichier « pipeau » dans /tmp, profitant du fait que /tmp est vidé à chaque démarrage il me semble. Du coup, dans le script, ça donnerait un truc dans le genre ça :
if [ -e /tmp/pipeau ]; then # Alors ce n'est pas la première exécution # depuis le dernier démarrage de la machine. else # Alors c'est la première exécution # depuis le dernier démarrage de la machine. # Du coup on crée le fichier. touch /tmp/pipeau fi
Mais je ne sais pas si c'est une bonne façon de faire :
1. Suis-je sûr que /tmp/pipeau sera effacé au prochain démarrage ?
2. Suis-je sûr qu'il ne peut pas être effacé à un moment donné alors qu'il n'y a pas eu encore redémarrage ?
3. Lorsque je crée /tmp/pipeau, peut-être que ce fichier existe déjà dans /tmp après tout (même si c'est hautement non probable) ?
Du coup, je me dis qu'on peut peut-être s'y prendre mieux que ça. :-)
Mon point de vue serait un peu différent: soit tu désires faire un truc vraiment fiable, et il faut insérer ta commande dans la liste des scripts exécutés au démarrage et à l'extinction de ta machine, soit tu veux rester en dehors, et de manière moins précise, tu peux par exemple comparer la date de création de ton fichier avec l'uptime de la machine.
Et je mettrais plutôt tout ça dans /etc
Marc Boyer -- À mesure que les inégalités regressent, les attentes se renforcent. François Dubet
